[rules-dev] Accessing Drools compiled classes

Guillaume Sauthier guillaume.sauthier at ow2.org
Thu Oct 28 04:11:09 EDT 2010 

No it's not fundamentally an issue with OSGi.
The proof is that we already have rule working in an OSGi environment.
But, it's working because of workarounds:
* Use DynamicImport-Package * that breaks OSGi modularity
* or Manage yourself your ClassLoader so that you can access both Drools 
runtime classes and your application classes

Both  of theses solutions are kind of trick.
I think it would be better (from a pure OSGi point of view) to have all 
theses classes generated in the bundle and not on the fly.

--Guillaume

Le 28/10/2010 09:45, Michael Neale a écrit :
> I am not sure if your assertion that runtime generated classes are 
> fundamentally a problem for OSGi - if that is indeed true - OSGi will 
> have deep problems in practical use. Lots of modern tools or 
> frameworks now generates bytecode at runtime - it is very very very 
> common, and it only getting more common. Java getting anonymous 
> classloaders and the JVM eliminating permspace as a separate memory 
> space point to even more usage of runtime code generation - it is here 
> to stay.
>
> On Thu, Oct 28, 2010 at 6:39 PM, 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
>
>
>
>
> -- 
> Michael D Neale
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
>
>
> _______________________________________________
> 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/343ee16f/attachment-0001.html

More information about the rules-dev mailing list