[rules-dev] Accessing Drools compiled classes

[Michael Neale]

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> 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>:
> >>
> >>
> >>> 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
> >>> 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
> >
> >
> >
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101028/96356009/attachment.html