Re: [rules-dev] Accessing Drools compiled classes

It could be a starting point for this part: *maven plugin that precompiles the rule discovered in the module and > simply place the* > * compiled classes in a given directory.* > On Thu, Oct 28, 2010 at 10:12 AM, Guillaume Sauthier < guillaume.sauthier(a)ow2.org&gt; wrote: > Thanks for the link Leonardo > I did take a look at it, but it doesn't do what I want (extract the > generated classes from the Package) :'( > --G > > Le 28/10/2010 09:49, Leonardo Gomes a écrit : > > For the maven-plugin thing, have a look here: > http://drools-java-rules-engine.46999.n3.nabble.com/maven-drools-plugin-t... > > Leo. > > On Thu, Oct 28, 2010 at 9:39 AM, Guillaume Sauthier < > guillaume.sauthier(a)ow2.org&gt; wrote: > >> Hi Edison >> >> To be more concrete, I would like to create first a maven plugin that >> precompiles the rule discovered in the module and simply place the >> compiled classes in a given directory. >> >> Currently, I may use the reflection trick to access what I want (the >> PackageStore), but if it could be part of an API, that would be better :) >> >> Does it seems weird ? Is a patch welcome for this problem ? >> >> --G >> >> Le 26/10/2010 09:49, Guillaume Sauthier a écrit : >> > Thanks for your answer Edson. >> > >> > The reason I have is that runtime generated stuff usually don't fit >> well >> > in an OSGi model. >> > >> > When you take a bundle, it has a statically defined set of "imported >> > packages". that means that when the bundle has been compiled, a list of >> > packages to be wired in at deployment time has been computed. This list >> > of packages if inferred from what the .class files (in the bundle) >> > requires to be executed (think of them as external dependencies). >> > >> > Now if we generate some classes at runtime in an OSGi environment, we >> > can see that generated classes can have different (or additional) >> > requirements in terms of java packages. So usually, with OSGi, that >> ends >> > up by adding a special header called DynamicImport-Package into the >> > MANIFEST, with the side effects of breaking modularity :-( >> > >> > This is what I want to avoid by having access to the generated classes >> > at the compilation phase: I can then use this bytecode (IOW giving it >> to >> > Bnd [1]) to complete the Import-Package MANIFEST header with the right >> > set of imported java packages. >> > >> > As a second issue, less important for the moment and more runtime >> > oriented this time, I would like to know if/how we can add a new kind >> of >> > Resource. >> > Once we have generated the bytecode in the compilation phase, we can >> > assume that all the stuff is already here in the bundle. Why can't we >> > use it ? >> > I've seen the PKG Resource type, but it's some kind of serialization of >> > a whole Package, couldn't it be possible to have a new Package type (or >> > way to create a Package) that can use the ClassLoader to get access to >> > the already present bundle's resources instead of using the byte[] from >> > the serialized Package ? >> > >> > WDYT? >> > >> > Thanks >> > --G >> > >> > [1]. http://www.aqute.biz/Code/Bnd >> > >> > Le 25/10/2010 21:26, Edson Tirelli a écrit : >> > >> >> Not exactly sure how helpful would it be to store the generated >> >> bytecodes in an osgi bundle. Anyway, there is no API right now to do >> >> that, but you can use reflection to achieve the same: >> >> >> >> PackageCompilationData data = >> pkg.getPackageCompilationData(); >> >> Field field = PackageCompilationData.class.getDeclaredField( >> "store" ); >> >> field.setAccessible( true ); >> >> Map<String, byte[]> store = (Map<String, byte[]>) >> field.get( data ); >> >> >> >> If you can justify the need for such an API, I guess we could be >> >> convinced to add one. >> >> >> >> Edson >> >> >> >> >> >> >> >> >> >> 2010/10/25 Guillaume Sauthier&lt;guillaume.sauthier(a)ow2.org&gt;: >> >> >> >> >> >>> Hi team >> >>> >> >>> I've tried the IRC (without much success I admit), maybe here someone >> will >> >>> have some thoughts to share :) >> >>> >> >>> I'm looking for a way to "intercept" the classes being generated by >> the >> >>> drools compiler. >> >>> I've seen that the classes bytecode is stored deep in >> >>> PackageStore/JavaDialectRuntimeData, so deep that I cannot easily >> access it >> >>> :) >> >>> The objective is to be able to give theses classes to Bnd (I want to >> store >> >>> all of that in an OSGi bundle) so that appropriate Import-Packages >> can be >> >>> computed. That will avoid to have DynamicImport-Packages all around >> my >> >>> bundles :) >> >>> >> >>> Currently, what I get from the drools compiler is a >> >>> Collection<KnowledgePackage> but I have no API (or didn't find any) >> to >> >>> access (or know) the classes generated by the compiler. >> >>> >> >>> Any ideas ? >> >>> Thanks >> >>> --Guillaume >> >>> >> >>> _______________________________________________ >> >>> rules-dev mailing list >> >>> rules-dev(a)lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> > _______________________________________________ >> > rules-dev mailing list >> > rules-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-dev >> > >> > >> > >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev