[rules-dev] Accessing Drools compiled classes
Guillaume Sauthier
guillaume.sauthier at ow2.org
Tue Nov 2 04:23:24 EDT 2010
Sure
But for the moment my use case only covers rules using Java Dialect.
I don't know MVEL stuff, does it works like the Java dialect ? (ie
parsing the rule, building some java code from it and then compile
everything ?)
--G
Le 29/10/2010 00:24, Michael Neale a écrit :
> That wouldn't cover things like "Just in time" code generation in
> things like MVEL though.
>
> On Thu, Oct 28, 2010 at 7:55 PM, Leonardo Gomes
> <leonardo.f.gomes at gmail.com <mailto:leonardo.f.gomes at gmail.com>> wrote:
>
> 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./
>
>
> On Thu, Oct 28, 2010 at 10:12 AM, Guillaume Sauthier
> <guillaume.sauthier at ow2.org <mailto: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
>> <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 <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/20101102/7039c39e/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume_sauthier.vcf
Type: text/x-vcard
Size: 459 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-dev/attachments/20101102/7039c39e/attachment-0001.vcf
More information about the rules-dev
mailing list