hi, i got a question about osgi support. is beta 3 already useable in osgi environments? could see that activators are registering v5 api as services. is it possible to consume osgi services in the script tasks and rules by context? is this planned for version 6? would be a great feature. thanks a lot for answer florian _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

hi, i got a question about osgi support. is beta 3 already useable in osgi environments? could see that activators are registering v5 api as services. is it possible to consume osgi services in the script tasks and rules by context? is this planned for version 6? would be a great feature. thanks a lot for answer florian _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi, i also saw all the Class.forName. Class.forName additionally uses a very aggressive class caching policy. See here: http://blog.osgi.org/2011/05/what-you-should-know-about-class.html http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html I do not understand why API imports compiler.impl? Maybe to enable class#forname i guess. Is there an intention to use a more modularized way in v6 beta4 when OSGi support will be implemented? Thanks Florian Am 20.06.13 15:43, schrieb Cristiano Gavião: > Hi, > > Well, besides the fact that the services that we used on version 5.x is > still there, I'm not that optimist with Drools 6 running well in an OSGi > container... at least not currently... > > Last week I played a bit too with Jbosgi and Wildfly and got a lot of > classloading errors due some factory classes trying to load classes that > are in another bundles... > > what surprise me most was that kie-api has an import to > org.drools.compiler.kie.builder.impl ! :) > > regards, > > John > On 17/06/13 19:39, Florian.Pirchner wrote: >> hi, >> >> i got a question about osgi support. >> is beta 3 already useable in osgi environments? could see that activators are registering v5 api as services. >> >> is it possible to consume osgi services in the script tasks and rules by context? is this planned for version 6? would be a great feature. >> >> thanks a lot for answer >> florian >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi Mark, i did some research. Indeed a very complex issue. Tried to find out the difference about Class.forName(String) and Class.forName(String, boolean, ClassLoader). Both of them are delegating to native jvm methods and the difference seems to be in resolving the class and the way that caches work. In http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 they are pointing to use Class.forName(String, boolean, ClassLoader). Could find that method call in some drools and jbpm classes. For instance compiler... But there are also a lot of Class.forName(String) calls too. Specialy in parts of code where no array-types come into play. For instance JavaHandlerWorkItemHandler calls (Class<JavaHandler>) Class.forName(className). Maybe it would be a good idea to replace Class.forName() for issues that exclude array-types by classloader.loadClass(). WDYT? Best Florian Am 20.06.13 17:28, schrieb Mark Proctor: > There are bugs with loadClass and serialisation :( > http://lists.jboss.org/pipermail/rules-dev/2011-November/003681.html > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 > "Thus, we highly recommend replacement of this > code: > myClassLoader.loadClass(className); > > With this code: > > Class.forName(className,false,myClassLoader);" > > Mark > On 20 Jun 2013, at 15:01, Florian Pirchner <florian.pirchner(a)gmail.com&gt; wrote: > >> Hi, >> >> i also saw all the Class.forName. Class.forName additionally uses a very >> aggressive class caching policy. >> See here: >> http://blog.osgi.org/2011/05/what-you-should-know-about-class.html >> http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html >> >> I do not understand why API imports compiler.impl? Maybe to enable >> class#forname i guess. >> >> >> Is there an intention to use a more modularized way in v6 beta4 when >> OSGi support will be implemented? >> >> Thanks Florian >> >> >> Am 20.06.13 15:43, schrieb Cristiano Gavião: >>> Hi, >>> >>> Well, besides the fact that the services that we used on version 5.x is >>> still there, I'm not that optimist with Drools 6 running well in an OSGi >>> container... at least not currently... >>> >>> Last week I played a bit too with Jbosgi and Wildfly and got a lot of >>> classloading errors due some factory classes trying to load classes that >>> are in another bundles... >>> >>> what surprise me most was that kie-api has an import to >>> org.drools.compiler.kie.builder.impl ! :) >>> >>> regards, >>> >>> John >>> On 17/06/13 19:39, Florian.Pirchner wrote: >>>> hi, >>>> >>>> i got a question about osgi support. >>>> is beta 3 already useable in osgi environments? could see that activators are registering v5 api as services. >>>> >>>> is it possible to consume osgi services in the script tasks and rules by context? is this planned for version 6? would be a great feature. >>>> >>>> thanks a lot for answer >>>> florian >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users -- Mit besten Grüßen Florian Pirchner Fohlenweg 22 2301 Probstdorf Tel: +43 650 7772338 florian.pirchner(a)gmail.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Florian, Don't think that the problem that we are facing in Drools6 is because the Class.forName on its own. But the problem is from which bundle it is being called and where resides the class that it is trying to load... Definitively one bundle CAN'T load classes that resides in another bundle, unless you specify a import of the package... That is why currently kie-api has an import to org.drools.compiler.kie.builder.impl so the solution must be composed by two steps: Repackage some classes, so a class will be loaded by its own bundle and use services... On 21/06/13 03:30, Florian Pirchner wrote: > Hi Mark, > > i did some research. Indeed a very complex issue. > Tried to find out the difference about Class.forName(String) and Class.forName(String, boolean, ClassLoader). Both of them are delegating to native jvm methods and the difference seems to be in resolving the class and the way that caches work. > > In http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 they are pointing to use Class.forName(String, boolean, ClassLoader). Could find that method call in some drools and jbpm classes. For instance compiler... > > But there are also a lot of Class.forName(String) calls too. Specialy in parts of code where no array-types come into play. > For instance JavaHandlerWorkItemHandler calls (Class<JavaHandler>) Class.forName(className). > > Maybe it would be a good idea to replace Class.forName() for issues that exclude array-types by classloader.loadClass(). > > WDYT? > > Best Florian > > > > Am 20.06.13 17:28, schrieb Mark Proctor: >> There are bugs with loadClass and serialisation :( >> http://lists.jboss.org/pipermail/rules-dev/2011-November/003681.html >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 >> "Thus, we highly recommend replacement of this >> code: >> myClassLoader.loadClass(className); >> >> With this code: >> >> Class.forName(className,false,myClassLoader);" >> >> Mark >> On 20 Jun 2013, at 15:01, Florian Pirchner <florian.pirchner(a)gmail.com&gt; wrote: >> >>> Hi, >>> >>> i also saw all the Class.forName. Class.forName additionally uses a very >>> aggressive class caching policy. >>> See here: >>> http://blog.osgi.org/2011/05/what-you-should-know-about-class.html >>> http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html >>> >>> I do not understand why API imports compiler.impl? Maybe to enable >>> class#forname i guess. >>> >>> >>> Is there an intention to use a more modularized way in v6 beta4 when >>> OSGi support will be implemented? >>> >>> Thanks Florian >>> >>> >>> Am 20.06.13 15:43, schrieb Cristiano Gavião: >>>> Hi, >>>> >>>> Well, besides the fact that the services that we used on version 5.x is >>>> still there, I'm not that optimist with Drools 6 running well in an OSGi >>>> container... at least not currently... >>>> >>>> Last week I played a bit too with Jbosgi and Wildfly and got a lot of >>>> classloading errors due some factory classes trying to load classes that >>>> are in another bundles... >>>> >>>> what surprise me most was that kie-api has an import to >>>> org.drools.compiler.kie.builder.impl ! :) >>>> >>>> regards, >>>> >>>> John >>>> On 17/06/13 19:39, Florian.Pirchner wrote: >>>>> hi, >>>>> >>>>> i got a question about osgi support. >>>>> is beta 3 already useable in osgi environments? could see that activators are registering v5 api as services. >>>>> >>>>> is it possible to consume osgi services in the script tasks and rules by context? is this planned for version 6? would be a great feature. >>>>> >>>>> thanks a lot for answer >>>>> florian >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > -- > Mit besten Grüßen > Florian Pirchner > Fohlenweg 22 > 2301 Probstdorf > Tel: +43 650 7772338 > florian.pirchner(a)gmail.com > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

hi cristiano, yep. class#forname is just one issue. i agree that the modularity issue is an important one too. to provide a framework for non osgi and osgi environments is really a challenge. my prefered way would be the use of osgi services to avoid the classloading issues. so the problems with dependencies would not influence the system. only api is required as import package. the impl is invisible for the consumer. but for now i have no idea how a proper implementation could look like. peter kriens suggested the use of http://code.google.com/p/pojosr/ to build an osgi like system in non osgi environments. but never used it. and i also do not know whether it might help with osgi integration. does anybody have experience with pojosr? @mark: what are your current ideas about integrating osgi properly? best florian Am 21.06.2013 um 23:49 schrieb Cristiano Gavião <cvgaviao(a)gmail.com <mailto:cvgaviao@gmail.com>>: > Florian, > > Don't think that the problem that we are facing in Drools6 is because > the Class.forName on its own. > > But the problem is from which bundle it is being called and where > resides the class that it is trying to load... > > Definitively one bundle CAN'T load classes that resides in another > bundle, unless you specify a import of the package... That is why > currently kie-api has an import to org.drools.compiler.kie.builder.impl > > so the solution must be composed by two steps: Repackage some > classes, so a class will be loaded by its own bundle and use services... > > On 21/06/13 03:30, Florian Pirchner wrote: >> Hi Mark, >> >> i did some research. Indeed a very complex issue. >> Tried to find out the difference about Class.forName(String) and >> Class.forName(String, boolean, ClassLoader). Both of them are >> delegating to native jvm methods and the difference seems to be in >> resolving the class and the way that caches work. >> >> In http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 they >> are pointing to use Class.forName(String, boolean, ClassLoader). >> Could find that method call in some drools and jbpm classes. For >> instance compiler... >> >> But there are also a lot of Class.forName(String) calls too. >> Specialy in parts of code where no array-types come into play. >> For instance JavaHandlerWorkItemHandler calls (Class<JavaHandler>) >> Class.forName(className). >> >> Maybe it would be a good idea to replace Class.forName() for issues >> that exclude array-types by classloader.loadClass(). >> >> WDYT? >> >> Best Florian >> >> >> >> Am 20.06.13 17:28, schrieb Mark Proctor: >>> There are bugs with loadClass and serialisation :( >>> http://lists.jboss.org/pipermail/rules-dev/2011-November/003681.html >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 >>> "Thus, we highly recommend replacement of this code: >>> myClassLoader.loadClass(className); >>> >>> With this code: >>> >>> Class.forName(className,false,myClassLoader);" >>> >>> Mark >>> On 20 Jun 2013, at 15:01, Florian Pirchner >>> <florian.pirchner(a)gmail.com <mailto:florian.pirchner@gmail.com>> wrote: >>> >>>> Hi, >>>> >>>> i also saw all the Class.forName. Class.forName additionally uses >>>> a very >>>> aggressive class caching policy. >>>> See here: >>>> http://blog.osgi.org/2011/05/what-you-should-know-about-class.html >>>> http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html >>>> >>>> I do not understand why API imports compiler.impl? Maybe to enable >>>> class#forname i guess. >>>> >>>> >>>> Is there an intention to use a more modularized way in v6 beta4 when >>>> OSGi support will be implemented? >>>> >>>> Thanks Florian >>>> >>>> >>>> Am 20.06.13 15:43, schrieb Cristiano Gavião: >>>>> Hi, >>>>> >>>>> Well, besides the fact that the services that we used on version >>>>> 5.x is >>>>> still there, I'm not that optimist with Drools 6 running well in >>>>> an OSGi >>>>> container... at least not currently... >>>>> >>>>> Last week I played a bit too with Jbosgi and Wildfly and got a lot of >>>>> classloading errors due some factory classes trying to load >>>>> classes that >>>>> are in another bundles... >>>>> >>>>> what surprise me most was that kie-api has an import to >>>>> org.drools.compiler.kie.builder.impl ! :) >>>>> >>>>> regards, >>>>> >>>>> John >>>>> On 17/06/13 19:39, Florian.Pirchner wrote: >>>>>> hi, >>>>>> >>>>>> i got a question about osgi support. >>>>>> is beta 3 already useable in osgi environments? could see that >>>>>> activators are registering v5 api as services. >>>>>> >>>>>> is it possible to consume osgi services in the script tasks and >>>>>> rules by context? is this planned for version 6? would be a >>>>>> great feature. >>>>>> >>>>>> thanks a lot for answer >>>>>> florian >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> -- >> Mit besten Grüßen >> Florian Pirchner >> Fohlenweg 22 >> 2301 Probstdorf >> Tel: +43 650 7772338 >> florian.pirchner(a)gmail.com >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi, I moved from 5.5.0 to 6.0.0.Beta two weeks ago to test OSGi integration, since I came across in 5.5.0 some split-package issues. Like you say, in this last version classloading issues appear, although thankfully no more split-packages between bundles are present (afaik) To get rid of the classloading issues, I just had to add a "DynamicImport-Package:*" to "kie-api-internal" bundle (the confictive one) descriptor, to make it import dynamically all the packages that it needs, i.e. those not explicitlly imported I'm using a very small set of funcionallity of the Drools platform (just rules, templates and DSL), so maybe this approach does not apply to you This is a rough solution, but it worked at least for test/evaluation pourposes. Including specific import packages in bundle(s) descriptor(s) would be a nicest one. Regards, -- Álvaro -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-drools-6-and-osgi-tp4024337... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users