[rules-users] Drools 6 and OSGi
Florian Pirchner
florian.pirchner at gmail.com
Thu Apr 3 03:43:06 EDT 2014
Thanks,
will try the latest build.
Best, Florian
Am 03.04.14 00:12, schrieb Mark Proctor:
>
>> I did not get the idea behind it. Why don't you use "new" to create
>> new instances. Then the bundles have to define their dependencies
>> very carefully to become compiled.
> At the point where you see Class.forName it means the implementation
> is not on the class path of that module, but the interface is. So the
> provider pattern mechanism uses reflection to load the instance to
> return to you under the targeted interface. This is how all our
> factories work, we have all the api in -api but none of the
> implementation. It binds the implementation at runtime, via
> reflection. However, in the case of our -api factories, we already
> address this in OSGi by using Activator injection.
>
>> My question is about the architecture changes to meet OSGi
>> requirements. There are a lot of Class#forName calls to create new
>> instances. In OSGi it is not that easy then in java SE. Each bundle
>> has its own class loader. And classes are only visible to bundles, if
>> their package was imported.
> We have not done a full audit of Class.forName. I should add that
> loadClass itself has problems too, related to serialisation - which is
> why we use forName. If you want to do an audit and submit via a pull
> request alternatives, then please do. Although remember not all those
> forNames (in the case of our factories) will b used by OSGi, so make
> sure you find ones that you believe are actually a problem.
>
> We also did work around making sure all our jars have unique package
> names, to avoid split packages. And there was a lot of work around
> repacking our dependencies.
>
>> So my question is, whether that approach is the suggested way to add
>> Drools and JBPM to OSGi containers.
> Sorry I don't understand the question fully. The classloader argument,
> is if you need to specify parent classloader. There are a variety of
> use cases for this, such as if people are doing runtime code
> generation on custom classloaders that they want to make visible to
> Drools.
>
> My understanding is that drools now works on karaf. Maybe try one of
> our latest builds if there any issues, then come back and let us know.
> http://downloads.jboss.org/drools/release/snapshot/master/
>
> Mark
>
> On 2 Apr 2014, at 20:51, Florian Pirchner <florian.pirchner at gmail.com
> <mailto:florian.pirchner at gmail.com>> wrote:
>
>> Hi Mark,
>>
>> could not find anybody in cc :D
>>
>> Good to hear, that there is progress in the OSGi stuff.
>>
>> My question is about the architecture changes to meet OSGi
>> requirements. There are a lot of Class#forName calls to create new
>> instances. In OSGi it is not that easy then in java SE. Each bundle
>> has its own class loader. And classes are only visible to bundles, if
>> their package was imported.
>>
>> I could see, that there is a ProjectClassLoader. And that there is a
>> way to provide a common parent classloader. That might be the bundle
>> classloader. So most of the classes can be found by Class#forName.
>> But it requires a bundle, that imports all the dependencies from
>> drools, kie and jbpm. Only in that case, the bundles are visible to
>> the bundles class loader. So my question is, whether that approach is
>> the suggested way to add Drools and JBPM to OSGi containers.
>>
>> But a drawback is, that there is no real support about required
>> dependencies during development. Except the drools bundles will
>> define their imported packages very carefully. Why do you use
>> Class#forName to load classes? I did not get the idea behind it. Why
>> don't you use "new" to create new instances. Then the bundles have to
>> define their dependencies very carefully to become compiled.
>>
>> Thanks a lot for your answers.
>>
>> Best Florian
>>
>>
>>
>>
>>
>> 2014-03-31 18:28 GMT+02:00 Mark Proctor <mproctor at codehaus.org
>> <mailto:mproctor at codehaus.org>>:
>>
>> There was a lot of OSGi fixes in 6.0.1, aimed at the karat
>> container. However not all modules are migrated, as it's a work
>> in progress. I don't know which currently are or are not, I'm
>> cc'ing in the developer behind this to answer.
>>
>> Mark
>> On 31 Mar 2014, at 16:49, Florian Pirchner
>> <florian.pirchner at gmail.com <mailto:florian.pirchner at gmail.com>>
>> wrote:
>>
>>> Hi,
>>>
>>> today i started to setup Drools 6 in my OSGi container. But it
>>> seems there are some issues that do not allow to run drools 6
>>> (and jbpm) under OSGi properly.
>>>
>>> For instance:
>>> JPAKnowledgeService
>>> .newStatefulKnowledgeSession(kieBase, null, env);
>>> will never find
>>> "org.drools.persistence.jpa.KnowledgeStoreServiceImpl" since it
>>> is not in the scope of the current ClassLoader.
>>>
>>> Tried to tie things up, but then there would be a cyclic
>>> dependency between kie-internal and jbpm-persistence-jpa.
>>>
>>> I also could see, that a ProjectClassLoader was added. I found a
>>> way to put my current BundleClassLoader as its parent into play.
>>> This solves a lot of class loading issues.
>>>
>>>
>>> For me it seems, that Drools 6 was not designed to run in an
>>> OSGi container. Is there ongoing work to integrate Drools and
>>> JBPM Version 6.x into OSGi environments properly?
>>>
>>> --
>>> Thanks for your answer
>>> Florian Pirchner
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140403/b443f06e/attachment-0001.html
More information about the rules-users
mailing list