[rules-dev] Accessing Drools compiled classes

[Leonardo Gomes]

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> 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 listrules-dev at lists.jboss.orghttps://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/474b1100/attachment-0001.html