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 < ephemeris.lap...@gmail.com> 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 <ch0...@gmail.com>: > > 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 < >> ephemeris.lap...@gmail.com> 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 >>> rules-users@lists.jboss.org >>> 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 >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > 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 rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users