<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><blockquote type="cite"><div dir="ltr"> 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.</div></blockquote>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr">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.</div></blockquote>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr">So my question is, whether that approach is the suggested way to add Drools and JBPM to OSGi containers.</div></blockquote>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.</div><div><br></div><div>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.</div><div><a href="http://downloads.jboss.org/drools/release/snapshot/master/">http://downloads.jboss.org/drools/release/snapshot/master/</a></div><div><br></div><div>Mark</div><div><br></div><div><div><div><div>On 2 Apr 2014, at 20:51, Florian Pirchner <<a href="mailto:florian.pirchner@gmail.com">florian.pirchner@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Mark,<div><br></div><div>could not find anybody in cc :D</div><div><br></div><div>Good to hear, that there is progress in the OSGi stuff.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks a lot for your answers.</div><div><br></div><div>Best Florian</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-31 18:28 GMT+02:00 Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div>
<br></div><div>Mark<br><div><div><div class="h5"><div>On 31 Mar 2014, at 16:49, Florian Pirchner <<a href="mailto:florian.pirchner@gmail.com" target="_blank">florian.pirchner@gmail.com</a>> wrote:</div><br></div></div>
<blockquote type="cite"><div><div class="h5">
<div bgcolor="#FFFFFF" text="#000000">
<font size="-1">Hi,<br>
<br>
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.<br>
<br>
For instance:<br>
JPAKnowledgeService<br>
.newStatefulKnowledgeSession(kieBase, null, env);<br>
will never find
"org.drools.persistence.jpa.KnowledgeStoreServiceImpl" since it is
not in the scope of the current ClassLoader.<br>
<br>
Tried to tie things up, but then there would be a cyclic
dependency between kie-internal and jbpm-persistence-jpa.<br>
<br>
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.<br>
<br>
<br>
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 V</font><font size="-1"><font size="-1">ersion 6.x</font> into OSGi environments
properly?<br>
<br>
</font>
<pre cols="72">--
Thanks for your answer
Florian Pirchner
</pre>
</div></div></div>
_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a></blockquote>
</div><br></div></div><br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>
Mit besten Grüßen</div><div>Florian Pirchner</div>Lunifera GmbH<div>Marchfelder Straße 2</div><div>2301 Groß Enzersdorf</div><div>Austria</div></div>
</div>
_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/rules-users</blockquote></div><br></div></div></body></html>