[rules-dev] Accessing Drools compiled classes

Edson Tirelli tirelli at post.com
Thu Oct 28 12:05:30 EDT 2010 

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



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com

More information about the rules-dev mailing list