[jboss-jira] [JBoss JIRA] (DROOLS-342) API additions required for SwitchYard

David Ward (JIRA) jira-events at lists.jboss.org
Fri Nov 15 17:04:06 EST 2013


     [ https://issues.jboss.org/browse/DROOLS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Ward updated DROOLS-342:
------------------------------

    Description: 
Addition 1 - Critical:

org.kie.api.KieServices has a getKieClassPathContainer() method, whose implementation is in org.drools.compiler.kie.builder.impl.KieServicesImpl.  The implementation method caches the classpathKContainer the first time it is created, and since the KieServicesImpl is cached by the KieServices.Factory, that means it is effectively a singleton, and there will only ever be one classpathKContainer.

This is very problematic for SwitchYard for when a SwitchYard deployment artifact also represents the module containing the rules resources and classes - not on the first deployment - but on subsequent ones.  What happens is that user-defined application classes (and those their classloader) get cached.  But on redeployment, there is a new classloader for the updated user-defined application classes, but the classpathKContainer, within, is referencing the old one.  THUS, the effect is that the LHS of rules will NOT match, since objects are only equal if their classes' classloaders are also equal.

What I request is that an additional method be added to KieServices, called newKieClasspathContainer().  This will bypass the cached classpathKContainer that getKieClasspathContainer() uses, and thus a new KieContainerImpl(new ClasspathKieProject(), null) will be created.

You can actually see in KieServicesImpl that there is a test helper method called nullKieClasspathContainer() that clears out the cached version.  Well, we kinda need to be able to create new ones too, but not just for tests. :)

Addition 2 - Desirable:

org.kie.api.runtime.KieContainer has method newKieSession(sessionName, environment, sessionConfiguration) - and various other overloaded permutations.  One hole, though, is that there is no newKieSession(environment, sessionConfiguration) - a permutation that takes those params but where it will fall back to the default configured session (as no sessionName is defined).  What I request is addition of that method.

Now, one can call kieContainer.getKieBase().newKieSession(sessionConfiguration, environment) without the sessionName, but this is not desirable.  I'd rather see an evened-out overloaded method right on KieContainer.

In short, "Addition 1" is critical for SwitchYard, otherwise we have to use non-public api's to get it to work.  (ie: call  new KieContainerImpl(new ClasspathKieProject(), null) ourselves).  But "Addition 2" is lower priority.

Thanks!

  was:
Addition 1 - Critical:

org.kie.api.KieServices has a getKieClassPathContainer() method, whose implementation is in org.drools.compiler.kie.builder.impl.KieServicesImpl.  The implementation method caches the classpathKContainer the first time it is created, and since the KieServicesImpl is cached by the KieServices.Factory, that means it is effectively a singleton, and there will only ever be one classpathKContainer.

This is very problematic for SwitchYard for when a SwitchYard deployment artifact also represents the module containing the rules resources and classes - not on the first deployment - but on subsequent ones.  What happens is that user-defined application classes (and those their classloader) get cached.  But on redeployment, there is a new classloader for the updated user-defined application classes, but the classpathKContainer, within, is referencing the old one.  THUS, the effect is that the LHS of rules will NOT match, since objects are only equal if their classes' classloaders are also equal.

What I request is that an additional method be added to KieServices, called newKieClasspathContainer().  This will bypass the cached classpathKContainer that getKieClasspathContainer() uses, and thus a new KieContainerImpl(new ClasspathKieProject(), null) will be created.

You can actually see in KieServicesImpl that there is a test helper method called nullKieClasspathContainer() that clears out the cached version.  Well, we kinda need to be able to create new ones too, but not just for tests. :)

Addition 2 - Desirable:

org.kie.api.runtime.KieContainer has method newKieSession(sessionName, environment, sessionConfiguration) - and various other overloaded permutations.  One hole, though, is that there is no newKieSession(environment, sessionConfiguration) - a permutation that takes those params but where it will fall back to the default configured session (as no sessionName is defined).  What I request is addition of that method.

Now, one can call kieContainer.getKieBase().newKieSession(sessionConfiguration, environment) without the sessionName, but this is not desirable.  I'd rather see an evened-out overloaded method right on KieContainer.

In short, "Addition 1" is critical for SwitchYard, otherwise we have to use non-public api's to get it to work.  (ie: call  new KieContainerImpl(new ClasspathKieProject(), null) ourselves).

Thanks!


    
> API additions required for SwitchYard
> -------------------------------------
>
>                 Key: DROOLS-342
>                 URL: https://issues.jboss.org/browse/DROOLS-342
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: David Ward
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 6.0.0.Final
>
>
> Addition 1 - Critical:
> org.kie.api.KieServices has a getKieClassPathContainer() method, whose implementation is in org.drools.compiler.kie.builder.impl.KieServicesImpl.  The implementation method caches the classpathKContainer the first time it is created, and since the KieServicesImpl is cached by the KieServices.Factory, that means it is effectively a singleton, and there will only ever be one classpathKContainer.
> This is very problematic for SwitchYard for when a SwitchYard deployment artifact also represents the module containing the rules resources and classes - not on the first deployment - but on subsequent ones.  What happens is that user-defined application classes (and those their classloader) get cached.  But on redeployment, there is a new classloader for the updated user-defined application classes, but the classpathKContainer, within, is referencing the old one.  THUS, the effect is that the LHS of rules will NOT match, since objects are only equal if their classes' classloaders are also equal.
> What I request is that an additional method be added to KieServices, called newKieClasspathContainer().  This will bypass the cached classpathKContainer that getKieClasspathContainer() uses, and thus a new KieContainerImpl(new ClasspathKieProject(), null) will be created.
> You can actually see in KieServicesImpl that there is a test helper method called nullKieClasspathContainer() that clears out the cached version.  Well, we kinda need to be able to create new ones too, but not just for tests. :)
> Addition 2 - Desirable:
> org.kie.api.runtime.KieContainer has method newKieSession(sessionName, environment, sessionConfiguration) - and various other overloaded permutations.  One hole, though, is that there is no newKieSession(environment, sessionConfiguration) - a permutation that takes those params but where it will fall back to the default configured session (as no sessionName is defined).  What I request is addition of that method.
> Now, one can call kieContainer.getKieBase().newKieSession(sessionConfiguration, environment) without the sessionName, but this is not desirable.  I'd rather see an evened-out overloaded method right on KieContainer.
> In short, "Addition 1" is critical for SwitchYard, otherwise we have to use non-public api's to get it to work.  (ie: call  new KieContainerImpl(new ClasspathKieProject(), null) ourselves).  But "Addition 2" is lower priority.
> Thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jboss-jira mailing list