[rules-dev] Accessing Drools compiled classes
Guillaume Sauthier
guillaume.sauthier at ow2.org
Thu Oct 28 05:21:07 EDT 2010
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 <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
> 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/cd19909f/attachment.html
More information about the rules-dev
mailing list