[rules-dev] Accessing Drools compiled classes
Guillaume Sauthier
guillaume.sauthier at ow2.org
Tue Nov 2 04:33:12 EDT 2010
Sure, I'll connect to the IRC
I hope that we have compatible time zone ;) (I'm in France)
--G
Le 28/10/2010 18:05, Edson Tirelli a écrit :
> 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
>>
>>
>>
>
>
>
-------------- 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/8b80163e/attachment.vcf
More information about the rules-dev
mailing list