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.pirch...@gmail.com
<mailto:florian.pirch...@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 <mproc...@codehaus.org
<mailto:mproc...@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.pirch...@gmail.com <mailto:florian.pirch...@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@lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org <mailto: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
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
