Rules compilation error with OSGi integration (6.1.0.Beta3)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
Hello.

We have a very simple rules file that works as expected when running as a JUnit test in Eclipse with Maven dependencies, but fails when it is executing in ServiceMix with OSGi integration.

The code is just like :

raw>
Map<String, Object> dialog = new LinkedHashMap<>();
KieSession kieSession = kieContainer.newKieSession("MyKSession");
kieSession.setGlobal("dialog", dialog);
kieSession.insert(problem);
kieSession.fireAllRules();
kieSession.dispose();


The rules file :

package my.tests.drools.osgi.expert.rules

import java.util.Map

import my.tests.drools.osgi.expert.Problem
import my.tests.drools.osgi.expert.Solution

global java.util.Map<String, Object> dialog

rule "Main Rule"
	when
		Problem($what : what)
	then
		java.util.Map<String, String> m = new java.util.HashMap<>();
		m.put("s", "This is a good solution for '" + $what + "'");
		dialog.put("solution", new Solution(m.get("s")));
end

And the kmodule.xml :

<kmodule
	xmlns="http://jboss.org/kie/6.0.0/kmodule"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<kbase
		name="MyKBase"
		packages="my.tests.drools.osgi.expert.rules">
		<ksession
			name="MyKSession"
			default="true" />
	</kbase>

</kmodule>

The compilation error is about Java 7 syntax elements (as generics or thousand separators in number literals for example), and seems to indicate that in this case the compiler is not the same, and it expects another Java syntax. No error is reported when the KieContainer is created from the KModule.xml, but the following error occurs when using it for KSession creation.

java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=my/tests/drools/osgi/expert/rules/rules.drl, line=10, column=0
   text=Rule Compilation error Incorrect number of arguments for type HashMap<K,V>; it cannot be parameterized with arguments <?>
Syntax error on token "<", ? expected after this token]]
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:337)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:486)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:457)
	at my.tests.drools.osgi.expert.kie.KieExpert.analyse(KieExpert.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50)
	at org.apache.aries.proxy.impl.DefaultWrapper.invoke(DefaultWrapper.java:31)
	at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78)
	at com.sun.proxy.$Proxy64.analyse(Unknown Source)
	at my.tests.drools.osgi.camel.ExpertProcessor.process(ExpertProcessor.java:35)
	at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:335)
	at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
	at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.Pipeline.process(Pipeline.java:117)
	at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
	at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)
	at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)
	at org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
	at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
	at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
	at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
	at org.apache.camel.component.jetty.CamelContinuationServlet.service(CamelContinuationServlet.java:116)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1359)
	at org.eclipse.jetty.servlets.MultiPartFilter.doFilter(MultiPartFilter.java:97)
	at org.apache.camel.component.jetty.CamelFilterWrapper.doFilter(CamelFilterWrapper.java:44)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
	at org.eclipse.jetty.server.Server.handle(Server.java:349)
	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
	at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
	at java.lang.Thread.run(Thread.java:744)

This occurs both with the prepackaged feature (http://repo1.maven.org/maven2/org/drools/drools-karaf-features/6.1.0.Beta3/drools-karaf-features-6.1.0.Beta3-features.xml), or with an adapted one. For example, the Maven dependancies classpath in eclipse mentions newer versions of the Eclipse's ECJ. But changing the version of bundles has no effect...

What is missing in the feature to activate the correct rules compiler ?

Thanks for your help ?

Regards.
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
Can you provide us the compilation error reported (gist link) and a test case to allow us to reproduce your issue ?


On Mon, May 19, 2014 at 4:00 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

We have a very simple rules file that works as expected when running as a
JUnit test in Eclipse with Maven dependencies, but fails when it is
executing in ServiceMix with OSGi integration.

The code is just like :

raw>
Map<String, Object> dialog = new LinkedHashMap<>();
KieSession kieSession = kieContainer.newKieSession("MyKSession");
kieSession.setGlobal("dialog", dialog);
kieSession.insert(problem);
kieSession.fireAllRules();
kieSession.dispose();


The rules file :



And the kmodule.xml :



The compilation error is about Java 7 syntax elements (as generics or
thousand separators in number literals for example), and seems to indicate
that in this case the compiler is not the same, and it expects another Java
syntax. No error is reported when the KieContainer is created from the
KModule.xml, but the following error occurs when using it for KSession
creation.



This occurs both with the prepackaged feature
(http://repo1.maven.org/maven2/org/drools/drools-karaf-features/6.1.0.Beta3/drools-karaf-features-6.1.0.Beta3-features.xml),
or with an adapted one. For example, the Maven dependancies classpath in
eclipse mentions newer versions of the Eclipse's ECJ. But changing the
version of bundles has no effect...

What is missing in the feature to activate the correct rules compiler ?

Thanks for your help ?

Regards.




--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                | 239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) : Incorrect number of arguments for type HashMap<K,V>; it cannot be parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) : Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict "1.5" syntax in the RHS ! In this current case, do not use <> to infere the generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what is different from the Junit tests, I think that the problem comes from the classloader that is associated with the Kie container. Before compilation the language source and target level is  set with version 1.7 as expected, but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj compiler), the droolsClassloader is of type "org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name seems to incidate, I'm afraid that the Karaf/Felix loader is originally built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any better solution ? I don't know, for example, if it's possible to influence Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029622.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:
A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029622.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
Is it a list that you would like to use as global param ? If this is the case, maybe change your rule & code like that 

        //GET A KSESSION
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        //now create some test data
        ksession.insert( new Cheese( "stilton",
                               42 ) );
        ksession.insert( new Person( "michael",
                               "stilton",
                               42 ) );
        final List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list",
                      list );

        ksession.fireAllRules();

        System.out.println(list);

        ksession.dispose();

Rule 

template header
age
type
log

package org.drools.examples.templates;

global java.util.List list;

template "cheesefans"

rule "Cheese fans_@{row.rowNumber}"
    when
        Person(age == @{age})
        Cheese(type == "@{type}")
    then
        list.add("@{log}");
end
end template



On Tue, May 20, 2014 at 4:40 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:

A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029622.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
In this case it's not a global, but a temporary variable in the rule consequence. Indeed, the problem is not only about generics, but impacts all the syntax elements that may have changed since Java 1.5, and make the rules Java compiler fails when running in ServiceMix.

As I said before, the workaround is quite easy, changing all the Java code to be compliant with the compilation level. The question is just about a confirmation of the Felix's class loader (org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5) in the compiler's behavior, and a better solution to be able to write RHS with a 'modern' syntax.

Thanks.


2014-05-20 16:56 GMT+02:00 Charles Moulliard [via Drools] <[hidden email]>:
Is it a list that you would like to use as global param ? If this is the case, maybe change your rule & code like that 

        //GET A KSESSION
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        //now create some test data
        ksession.insert( new Cheese( "stilton",
                               42 ) );
        ksession.insert( new Person( "michael",
                               "stilton",
                               42 ) );
        final List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list",
                      list );

        ksession.fireAllRules();

        System.out.println(list);

        ksession.dispose();

Rule 

template header
age
type
log

package org.drools.examples.templates;

global java.util.List list;

template "cheesefans"

rule "Cheese fans_@{row.rowNumber}"
    when
        Person(age == @{age})
        Cheese(type == "@{type}")
    then
        list.add("@{log}");
end
end template



On Tue, May 20, 2014 at 4:40 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:

A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029622.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


If you reply to this email, your message will be added to the discussion below:
http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029628.html
To unsubscribe from Rules compilation error with OSGi integration (6.1.0.Beta3), click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
Have you tried this option for your bundle ?

Bundle-RequiredExecutionEnvironment: J2SE-1.7


On Tue, May 20, 2014 at 5:10 PM, Ephemeris Lappis <[hidden email]> wrote:
In this case it's not a global, but a temporary variable in the rule consequence. Indeed, the problem is not only about generics, but impacts all the syntax elements that may have changed since Java 1.5, and make the rules Java compiler fails when running in ServiceMix.

As I said before, the workaround is quite easy, changing all the Java code to be compliant with the compilation level. The question is just about a confirmation of the Felix's class loader (org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5) in the compiler's behavior, and a better solution to be able to write RHS with a 'modern' syntax.

Thanks.


2014-05-20 16:56 GMT+02:00 Charles Moulliard [via Drools] <[hidden email]>:
Is it a list that you would like to use as global param ? If this is the case, maybe change your rule & code like that 

        //GET A KSESSION
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        //now create some test data
        ksession.insert( new Cheese( "stilton",
                               42 ) );
        ksession.insert( new Person( "michael",
                               "stilton",
                               42 ) );
        final List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list",
                      list );

        ksession.fireAllRules();

        System.out.println(list);

        ksession.dispose();

Rule 

template header
age
type
log

package org.drools.examples.templates;

global java.util.List list;

template "cheesefans"

rule "Cheese fans_@{row.rowNumber}"
    when
        Person(age == @{age})
        Cheese(type == "@{type}")
    then
        list.add("@{log}");
end
end template



On Tue, May 20, 2014 at 4:40 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:

A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.


Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


If you reply to this email, your message will be added to the discussion below:
http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029628.html
To unsubscribe from Rules compilation error with OSGi integration (6.1.0.Beta3), click here.
NAML



View this message in context: Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Sent from the Drools: User forum mailing list archive at Nabble.com.

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
In reply to this post by Ephemeris Lappis
Which version of karaf / felix do you use ?

I'm using this version of Felix/karaf

  Karaf version               2.3.0.redhat-610379
  OSGi Framework              org.apache.felix.framework - 4.0.3.redhat-610379
  Java Virtual Machine        Java HotSpot(TM) 64-Bit Server VM version 24.51-b03
  Version                     1.7.0_51

I have made a test with this rule packaged with this maven module (https://github.com/cmoulliard/droolsjbpm-osgi-examples#simple-rule-example) and that works in both cases

package org.drools.example.drink;

import org.drools.example.model.Person
import java.util.List
import java.util.ArrayList;

rule "CanDrink"
when
    p : Person( age >= 21 )
then
p.setCanDrink(true);
List<String> l = new ArrayList<>();
end

OR

package org.drools.example.drink;

import org.drools.example.model.Person
import java.util.List
import java.util.ArrayList;

rule "CanDrink"
when
    p : Person( age >= 21 )
then
p.setCanDrink(true);
List<String> l = new ArrayList<String>();
end



On Tue, May 20, 2014 at 5:10 PM, Ephemeris Lappis <[hidden email]> wrote:
In this case it's not a global, but a temporary variable in the rule consequence. Indeed, the problem is not only about generics, but impacts all the syntax elements that may have changed since Java 1.5, and make the rules Java compiler fails when running in ServiceMix.

As I said before, the workaround is quite easy, changing all the Java code to be compliant with the compilation level. The question is just about a confirmation of the Felix's class loader (org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5) in the compiler's behavior, and a better solution to be able to write RHS with a 'modern' syntax.

Thanks.


2014-05-20 16:56 GMT+02:00 Charles Moulliard [via Drools] <[hidden email]>:
Is it a list that you would like to use as global param ? If this is the case, maybe change your rule & code like that 

        //GET A KSESSION
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        //now create some test data
        ksession.insert( new Cheese( "stilton",
                               42 ) );
        ksession.insert( new Person( "michael",
                               "stilton",
                               42 ) );
        final List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list",
                      list );

        ksession.fireAllRules();

        System.out.println(list);

        ksession.dispose();

Rule 

template header
age
type
log

package org.drools.examples.templates;

global java.util.List list;

template "cheesefans"

rule "Cheese fans_@{row.rowNumber}"
    when
        Person(age == @{age})
        Cheese(type == "@{type}")
    then
        list.add("@{log}");
end
end template



On Tue, May 20, 2014 at 4:40 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:

A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.


Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


If you reply to this email, your message will be added to the discussion below:
http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029628.html
To unsubscribe from Rules compilation error with OSGi integration (6.1.0.Beta3), click here.
NAML



View this message in context: Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Sent from the Drools: User forum mailing list archive at Nabble.com.

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
Hello.

Here the shell:info of my ServiceMix :

Karaf
  Karaf version               2.2.11
  OSGi Framework              org.apache.felix.framework - 3.2.2

JVM
  Java Virtual Machine        Java HotSpot(TM) 64-Bit Server VM version 24.51-b03
  Version                     1.7.0_51
  Vendor                      Oracle Corporation

I attach also a test project with the different modules that "mimic" the real project's structure.

I have 2 drl files. The "rules.drl" is compiled and executed. The "rules-bad.drl" uses 2 Java 1.7 syntax elements (generic type inference and thousand separator), and fails on ServiceMix.

I hope this can help you.

Another problem we've had with these tests is about the OSGi classloader. I had a look at your example on github, and saw that the bundle project manifest contains many Import-Package to let Drools use the module classloader that is passed to create the KieContainer. But the imports depends on the rules generated code. For example, in our code an accumulate function is translated in a class that seems to require more import. I've tried to add some packages, but the compilation has always failed on indirect dependencies that are hard to discover. I've tried with a dynamic import (that is a bad thing I think) and it works.

Many things are still "vague" in the question of the class loaders. I understand that the classloader that is passed on the KieContainer is used by Drools to resolve the rules module et files. In my case this classloader is the Felix's one that seems to restrict Java level to 1.5 in the problem discussed above... But I don't understand why the Drools OSGi integration that seems to act in the "machinery" doesn't supplement this classloader with all the needed Drools/Kie libraries and transitive dependencies. Ultimately, the application bundle that provides the rules and and set up their container must obviously have a reference on the API, but can't be aware of all the implementation packages.

At this time, we're going further with the dynamic import, but I suppose we'll try to find a better solution.

Any idea ?

Thanks again.
Regards.


2014-05-20 17:49 GMT+02:00 Charles Moulliard <[hidden email]>:
Which version of karaf / felix do you use ?

I'm using this version of Felix/karaf

  Karaf version               2.3.0.redhat-610379
  OSGi Framework              org.apache.felix.framework - 4.0.3.redhat-610379
  Java Virtual Machine        Java HotSpot(TM) 64-Bit Server VM version 24.51-b03
  Version                     1.7.0_51

I have made a test with this rule packaged with this maven module (https://github.com/cmoulliard/droolsjbpm-osgi-examples#simple-rule-example) and that works in both cases

package org.drools.example.drink;

import org.drools.example.model.Person
import java.util.List
import java.util.ArrayList;

rule "CanDrink"
when
    p : Person( age >= 21 )
then
p.setCanDrink(true);
List<String> l = new ArrayList<>();
end

OR

package org.drools.example.drink;

import org.drools.example.model.Person
import java.util.List
import java.util.ArrayList;

rule "CanDrink"
when
    p : Person( age >= 21 )
then
p.setCanDrink(true);
List<String> l = new ArrayList<String>();
end



On Tue, May 20, 2014 at 5:10 PM, Ephemeris Lappis <[hidden email]> wrote:
In this case it's not a global, but a temporary variable in the rule consequence. Indeed, the problem is not only about generics, but impacts all the syntax elements that may have changed since Java 1.5, and make the rules Java compiler fails when running in ServiceMix.

As I said before, the workaround is quite easy, changing all the Java code to be compliant with the compilation level. The question is just about a confirmation of the Felix's class loader (org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5) in the compiler's behavior, and a better solution to be able to write RHS with a 'modern' syntax.

Thanks.


2014-05-20 16:56 GMT+02:00 Charles Moulliard [via Drools] <[hidden email]>:
Is it a list that you would like to use as global param ? If this is the case, maybe change your rule & code like that 

        //GET A KSESSION
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        //now create some test data
        ksession.insert( new Cheese( "stilton",
                               42 ) );
        ksession.insert( new Person( "michael",
                               "stilton",
                               42 ) );
        final List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list",
                      list );

        ksession.fireAllRules();

        System.out.println(list);

        ksession.dispose();

Rule 

template header
age
type
log

package org.drools.examples.templates;

global java.util.List list;

template "cheesefans"

rule "Cheese fans_@{row.rowNumber}"
    when
        Person(age == @{age})
        Cheese(type == "@{type}")
    then
        list.add("@{log}");
end
end template



On Tue, May 20, 2014 at 4:40 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I have no such kind test with Pax Exam. Should you send me a simple maven project example using a Karaf container ?

Back to the problem, a very simple rule with something like that in the RHS always fails when deployed in a bundle whose class loader is the felix one :

List<String> l = new ArrayList<>();
that must be fixed with :
List<String> l = new ArrayList<String>();

or

int n = 1_000;
that fails instead of :
int n = 1000;

FYI, I use ServiceMix 4.5.3.

Thanks again.
Regards.



2014-05-20 15:41 GMT+02:00 Charles Moulliard <[hidden email]>:

A test case will be required to reproduce your problem. Do you have a pax-exam test ?


On Tue, May 20, 2014 at 1:03 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Here is the first lines of the error message :


14:58:57,457 | ERROR | tp1946301910-151 | AbstractKieModule                |
239 - org.drools.compiler - 6.1.0.20140429-1643 | Unable to build
KieBaseModel:MyKBase
Rule Compilation error : [Rule name='Main Rule']
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:649) :
Incorrect number of arguments for type HashMap<K,V>; it cannot be
parameterized with arguments <?>
        my/tests/drools/osgi/expert/rules/Rule_Main_Rule1409557233.java (8:666) :
Syntax error on token "<", ? expected after this token


I have found the explanation and a workaround : put it all with a strict
"1.5" syntax in the RHS ! In this current case, do not use <> to infere the
generic type, but use the expected declared types instead.

After a rather touchy remote debug of the ServiceMix runtime to inspect what
is different from the Junit tests, I think that the problem comes from the
classloader that is associated with the Kie container. Before compilation
the language source and target level is  set with version 1.7 as expected,
but in the nameEnvironment that is passed to the JavaCompiler (indeed, ecj
compiler), the droolsClassloader is of type
"org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5". As its name
seems to incidate, I'm afraid that the Karaf/Felix loader is originally
built in 1.5.

I've read some posts about the eclipse compiler that perhaps takes into
account the caller compliance to adapt its compilation language level.

Class loaders seem to be a serious problem when using Drools in complex
environment such as a OSGi one...

Please, could you confirm my analysis, and, if you have one, propose any
better solution ? I don't know, for example, if it's possible to influence
Karaf to use different levels of bundle class loaders...

Thanks a lot.

Regards.


Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


If you reply to this email, your message will be added to the discussion below:
http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029628.html
To unsubscribe from Rules compilation error with OSGi integration (6.1.0.Beta3), click here.
NAML



View this message in context: Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Sent from the Drools: User forum mailing list archive at Nabble.com.

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

test-drools-osgi.zip (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
In reply to this post by Charles Moulliard
Hello.

Although without much conviction, I've tried the "Bundle-RequiredExecutionEnvironment: J2SE-1.7", but it doesn't change the compilation level of the rules...

As I said in a previous answer, I don't know exactly how to do it, but I think the solution may be in the way that Drools takes the classloader passed by the application to have access to specific classes like the usually imported beans used in the rules. Indeed, perhaps that instead of using directly this classloader, for its tasks, among of them the rules compilation, it should be possible to use some kind of enriched classloader that carries all the Drools needed packages, and delegates application classes resolution to the application's one.

What do you think of that ?

Regards.
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
If you look to my example posted previously there are no issues. Can you make a test using just Apache Karaf 2.3.x with Drools 6.1.0.Beta3 and tell me what happen. Which JDK do you sue ?


On Wed, May 21, 2014 at 9:03 AM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Although without much conviction, I've tried the
"Bundle-RequiredExecutionEnvironment: J2SE-1.7", but it doesn't change the
compilation level of the rules...

As I said in a previous answer, I don't know exactly how to do it, but I
think the solution may be in the way that Drools takes the classloader
passed by the application to have access to specific classes like the
usually imported beans used in the rules. Indeed, perhaps that instead of
using directly this classloader, for its tasks, among of them the rules
compilation, it should be possible to use some kind of enriched classloader
that carries all the Drools needed packages, and delegates application
classes resolution to the application's one.

What do you think of that ?

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029635.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Ephemeris Lappis
Hello.

I could try to test on ServiceMix 5 that embeds Karaf  2.3.4, but for my concrete project, the customer current platform uses a ServiceMix 4.5.3 which is not really possible to change today while many other modules are already deployed.

Did you try in your environment the test project that I attached yesterday ? There is a rule in the project with an "accumulate" that generates java code that is not compiled because of missing indirect dependancy despite of the Import-Package that I've copied from your examples. Hence my idea of a "proxy" classloader between Drools and its compiler and the classloader provided by the application bundle, and avoid the dynamic import that breaks the good practices...


2014-05-21 11:48 GMT+02:00 Charles Moulliard <[hidden email]>:
If you look to my example posted previously there are no issues. Can you make a test using just Apache Karaf 2.3.x with Drools 6.1.0.Beta3 and tell me what happen. Which JDK do you sue ?


On Wed, May 21, 2014 at 9:03 AM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Although without much conviction, I've tried the
"Bundle-RequiredExecutionEnvironment: J2SE-1.7", but it doesn't change the
compilation level of the rules...

As I said in a previous answer, I don't know exactly how to do it, but I
think the solution may be in the way that Drools takes the classloader
passed by the application to have access to specific classes like the
usually imported beans used in the rules. Indeed, perhaps that instead of
using directly this classloader, for its tasks, among of them the rules
compilation, it should be possible to use some kind of enriched classloader
that carries all the Drools needed packages, and delegates application
classes resolution to the application's one.

What do you think of that ?

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029635.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] Rules compilation error with OSGi integration (6.1.0.Beta3)

Charles Moulliard
I can reproduce your error when I deploy the project (compiled with 1.7) and running with JDK 1.7 on Karaf 2.2.1/Felix 3.2.2 (= SMX 4.5.3)

2014-05-21 13:30:25,020 | INFO  | l Console Thread | ClasspathKieProject              | 211 - org.drools.compiler - 6.0.3.redhat-1 | Found kmodule: bundle://214.4:1/META-INF/kmodule.xml
2014-05-21 13:30:25,024 | DEBUG | l Console Thread | ClasspathKieProject              | 211 - org.drools.compiler - 6.0.3.redhat-1 | Discovered classpath module org.drools.example:simple:1.0.0-SNAPSHOT
2014-05-21 13:30:25,024 | INFO  | l Console Thread | KieRepositoryImpl                | 211 - org.drools.compiler - 6.0.3.redhat-1 | KieModule was added:org.drools.osgi.compiler.OsgiKieModule@501d0b5a
2014-05-21 13:30:25,044 | ERROR | l Console Thread | AbstractKieModule                | 211 - org.drools.compiler - 6.0.3.redhat-1 | Unable to build KieBaseModel:sampleKBase
Rule Compilation error : [Rule name='CanDrink']
org/drools/example/drink/Rule_CanDrink1955060708.java (8:541) : ArrayList cannot be resolved to a type
org/drools/example/drink/Rule_CanDrink1955060708.java (8:550) : Syntax error on token "<", ? expected after this token

BTW you have a workaround which is to define your code like this 

List<String> l = new ArrayList<String>();

Is it because the server runs with JDK 5 in production that you cannot change the code of the rules ?
As ServiceMix is just a packaging of Karaf + Camel + Cxf + ActiveMQ, why don't you use directly Karaf and a more recent version of Felix (4.x) ?





On Wed, May 21, 2014 at 12:55 PM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

I could try to test on ServiceMix 5 that embeds Karaf  2.3.4, but for my concrete project, the customer current platform uses a ServiceMix 4.5.3 which is not really possible to change today while many other modules are already deployed.

Did you try in your environment the test project that I attached yesterday ? There is a rule in the project with an "accumulate" that generates java code that is not compiled because of missing indirect dependancy despite of the Import-Package that I've copied from your examples. Hence my idea of a "proxy" classloader between Drools and its compiler and the classloader provided by the application bundle, and avoid the dynamic import that breaks the good practices...


2014-05-21 11:48 GMT+02:00 Charles Moulliard <[hidden email]>:

If you look to my example posted previously there are no issues. Can you make a test using just Apache Karaf 2.3.x with Drools 6.1.0.Beta3 and tell me what happen. Which JDK do you sue ?


On Wed, May 21, 2014 at 9:03 AM, Ephemeris Lappis <[hidden email]> wrote:
Hello.

Although without much conviction, I've tried the
"Bundle-RequiredExecutionEnvironment: J2SE-1.7", but it doesn't change the
compilation level of the rules...

As I said in a previous answer, I don't know exactly how to do it, but I
think the solution may be in the way that Drools takes the classloader
passed by the application to have access to specific classes like the
usually imported beans used in the rules. Indeed, perhaps that instead of
using directly this classloader, for its tasks, among of them the rules
compilation, it should be possible to use some kind of enriched classloader
that carries all the Drools needed packages, and delegates application
classes resolution to the application's one.

What do you think of that ?

Regards.



--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integration-6-1-0-Beta3-tp4029601p4029635.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users