Re: [rules-dev] Accessing Drools compiled classes

Guillaume, Do you think you can show up on IRC so that we can discuss this live? I am not opposed to exposing the package compilation data, but it is a very sensitive part of the code and we need to think carefully about the consequences of doing it and how to do it if that is the case... Edson 2010/10/28 Guillaume Sauthier&lt;guillaume.sauthier(a)ow2.org&gt;: > > Le 28/10/2010 10:55, Leonardo Gomes a écrit : > > 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. >> > Sure, but then I would like to have an API to get access to the PackageStore > from KnowledgePackage. > Currently there is no such API (or I didn't find how to access theses > classes). > A solution where I could provides my own PackageStore (thus intercepting the > writeClass(String name, byte[] bytecode)) would be nice also :) > > Currently, I've only the reflection trick to access theses classes :'( > --G > > > 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 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 list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > >