[rules-dev] Accessing Drools compiled classes

Guillaume Sauthier guillaume.sauthier at ow2.org
Thu Oct 28 04:12:56 EDT 2010


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-to-compile-DRL-s-at-build-time-td725751.html
>
> Leo.
>
> On Thu, Oct 28, 2010 at 9:39 AM, Guillaume Sauthier 
> <guillaume.sauthier at ow2.org <mailto:guillaume.sauthier at ow2.org>> 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<guillaume.sauthier at ow2.org
>     <mailto:guillaume.sauthier at ow2.org>>:
>     >>
>     >>
>     >>> 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/rules-dev
>     >>>
>     >>>
>     >>>
>     >>>
>     >>
>     >>
>     >>
>     > _______________________________________________
>     > rules-dev mailing list
>     > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/rules-dev
>     >
>     >
>     >
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101028/5028b377/attachment.html 


More information about the rules-dev mailing list