Drools-Rule for firing events between two connectors

[Andreas Grünwald]

Hello,

I already created a topic in the CDLFlex Industrial Development mailing list: https://groups.google.com/forum/?fromgroups=#!topic/cdlflex-ind-dev/jEr8E4u5UqY

The developers recommended this list to me, because they are not sure how to solve the problem.

I want to fire an event between two different connectors. E.g., one is called "project" and the other one "collaborator". Or another case: One is the connector for storing issues in the EDB, and the other one is the concrete Jira Issue connector.

To test the behavior of events, I created the following rule:

when

  e : org.cdlflex.domain.collaborator.events.DeleteCoEvent()

then

  String collaboratorId = e.getCollaboratorId();

  Project project = new Project();

  CollaboratorDomain origin = (CollaboratorDomain) OsgiHelper.getResponseProxy(e, CollaboratorDomain.class);

  ProjectDomain destination = (ProjectDomain) OsgiHelper.getResponseProxy(e, ProjectDomain.class);

  //until here it works
  
  Project p = null;

  try {

   p = destination.getProject("drools-test");

   System.out.println("CALLED SECOND TOOL DOMAIN");

  } catch (ProjectException exi) {

   System.out.println("EXCEPTION");

  }

The integration test stops with "object is not an instance of declaring class". However, "ProjectDomain" is definitely an instance of its declaring class, and "Project" as well, I check this several times. The called method is defined as follows:
public Project getProject(String arg0) throws ProjectException;

As MiPe stated in the CDLFlex Industrial Mailing list, he is not sure if that is possible, and that it might not work, because the context of the rule is collaborator, and not project. However, please refer to the topic in the mailing list for more details.

Thank you,

Andreas

[Andreas Pieber]

Hey Andreas,

This smells like a problem with the classloaders. Especially because those are proxies. Do you have the full stack trace at hand? This might help diagnosing the problem.

Kind regards,
Andreas

--
You received this message because you are subscribed to the Google Groups "OpenEngSB user group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openengsb-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andreas Grünwald]

Hello Andreas,

attached you find the latest log file and the related rule, including some System.outs.

Best, 

Andreas

[Andreas Grünwald]

BTW: It might be (as MiPe already stated) that the context of the rule is wrong for the second connector, because both times the same event is used to get the service. If this is the case, how can I retrieve the second connector then?

Best, Andreas

[Andreas Pieber]

I'll give this second theory a more detailed look. But before this another thing. Have you already tried letting the rule run without exam? Deploy and activate and test it manually? I'm really curious if this would deliver the same results?

Kind regards,

Andreas

[Andreas Grünwald]

Hello Andreas,

no I didn't try this yet. I haven't created a Web interface yet hence this will take some time. Maybe you can look at the problem in parallel?

Best, Andreas

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEngSB user group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openengsb-user/COiHeHBXn-Y/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to openengsb-use...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Andreas Grünwald

Tel.: +43 650 77 82340

[Andreas Pieber]

There's already a pretty general web interface in the openengsb command interface you might use for your tests. Its just that running in itests add additional classlaoder complexity which might could be the reason for your failures. I'll do what I can though. Independently it will definitely help to know if it works running "regularly" or fails with the same error.

Kind regards,

Andreas

[Andreas Grünwald]

Hello,

firing the rule from the Web-Interface results in exactly the same exception (see attached).

Best, Andreas

[Andreas Pieber]

Thank you very much for your test. It sounds somehow like a drools error. Can you also reproduce this exception with public accessible domains/components? Would make the debugging easier

Kind regards,

Andreas

[Andreas Grünwald]

Hello again,

the whole project is located at: https://bitbucket.org/agruenwald/custom-itpm (please note that the code is only to test the different components of the Eng the configuration, hence still a little bit messy). 

In addition you may need the following dependencies installed:

• https://bitbucket.org/agruenwald/cdlflex-mdd/ (however, for the test this project is irrelevant, you can also remove all the related components, such as components/dashboard from the maven build).
   
• https://bitbucket.org/mipe/cdlflex-framework (if you want to use the itests; MiPe added a class which loads the dependencies correctly; before we had to add Thread.sleep.
  
  
• The test component is "components/connectortest" and you can test the Drool rule from the UI if you click on the button in "Collaborator Management".

Hope that we find a solution soon for that, because that problem bothers me since 2 weeks.

Thx, and best, Andreas

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEngSB user group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openengsb-user/COiHeHBXn-Y/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to openengsb-use...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Michael Petritsch]

Hi,

Andreas Gr. two more things you could try to narrow the point of failure down:

1. execute the same code (creating a DeleteCoEvent and then fetching
proxies for your Domain and Collaborator proxies) directly in Java. If
you get the same error as from the drools rule it should not be drools
related.

2. do the opposite as in your first post: create and call a rule that
responds to an event of your ProjectDomain (instead of
CollaboratorDomain) and try to get both proxies as usual. In case you
get the IllegalArgumentException when invoking a method of your
Collaborator Domain, but the ProjectDomain works as intended (so the
opposite of the observed errors in your first post) it would favor the
'wrong context hypothesis'.
However, if you observe exactly the same errors as in you first post,
then something is wrong with your ProjectDomain configuration.

br

[Andreas Grünwald]

Hello Michael,

thx for the input.

I already tested excessively on wednesday and thursday, and tried to narrow the error together with APi.

For instance, I executed the rule from the UI and not from the iTests, etc.

According to the feedback of APi it looks like a Drools-problem. Andreas (APi) will have a closer look at it.

Until then I think it makes no sense to invest further time into this issue.

Best, Andreas

[Andreas Grünwald]

Hello,

what is the current state here?

Thanks,

Andreas

[Andreas Pieber]

Hey Andreas,

We'vent spent any thoughts on this by now. I think there are various options where this could be added:

* directly as a proxy before the service

* as a component somewhere in drools

Maybe there are even more possible places if I think longer about it.

So, in a nutshell, there havent been any thoughts about this by now, nor any architectural decisions. Feel free to propose your own :-)

Kind regards,

Andreas

[Andreas Pieber]

UPS... wrong thread :-) No update by now. I was pretty busy fixing the travis build and the tests & components in general so that I wont block any other guys working on the bus. Only things remaining here are the structure for a proper 3.x release, so I'm pretty close to giving this a shot. Maybe I can make some free hours tomorrow to dive into this. But my guts are telling me that this wont be pretty...

Kind regards,

Andreas