I am not sure if your assertion that runtime generated classes are fundamentally a problem for OSGi - if that is indeed true - OSGi will have deep problems in practical use. Lots of modern tools or frameworks now generates bytecode at runtime - it is very very very common, and it only getting more common. Java getting anonymous classloaders and the JVM eliminating permspace as a separate memory space point to even more usage of runtime code generation - it is here to stay. <br>
<br><div class="gmail_quote">On Thu, Oct 28, 2010 at 6:39 PM, Guillaume Sauthier <span dir="ltr"><<a href="mailto:guillaume.sauthier@ow2.org">guillaume.sauthier@ow2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Edison<br>
<br>
To be more concrete, I would like to create first a maven plugin that<br>
precompiles the rule discovered in the module and simply place the<br>
compiled classes in a given directory.<br>
<br>
Currently, I may use the reflection trick to access what I want (the<br>
PackageStore), but if it could be part of an API, that would be better :)<br>
<br>
Does it seems weird ? Is a patch welcome for this problem ?<br>
<br>
--G<br>
<br>
Le 26/10/2010 09:49, Guillaume Sauthier a écrit :<br>
<div><div></div><div class="h5">> Thanks for your answer Edson.<br>
><br>
> The reason I have is that runtime generated stuff usually don't fit well<br>
> in an OSGi model.<br>
><br>
> When you take a bundle, it has a statically defined set of "imported<br>
> packages". that means that when the bundle has been compiled, a list of<br>
> packages to be wired in at deployment time has been computed. This list<br>
> of packages if inferred from what the .class files (in the bundle)<br>
> requires to be executed (think of them as external dependencies).<br>
><br>
> Now if we generate some classes at runtime in an OSGi environment, we<br>
> can see that generated classes can have different (or additional)<br>
> requirements in terms of java packages. So usually, with OSGi, that ends<br>
> up by adding a special header called DynamicImport-Package into the<br>
> MANIFEST, with the side effects of breaking modularity :-(<br>
><br>
> This is what I want to avoid by having access to the generated classes<br>
> at the compilation phase: I can then use this bytecode (IOW giving it to<br>
> Bnd [1]) to complete the Import-Package MANIFEST header with the right<br>
> set of imported java packages.<br>
><br>
> As a second issue, less important for the moment and more runtime<br>
> oriented this time, I would like to know if/how we can add a new kind of<br>
> Resource.<br>
> Once we have generated the bytecode in the compilation phase, we can<br>
> assume that all the stuff is already here in the bundle. Why can't we<br>
> use it ?<br>
> I've seen the PKG Resource type, but it's some kind of serialization of<br>
> a whole Package, couldn't it be possible to have a new Package type (or<br>
> way to create a Package) that can use the ClassLoader to get access to<br>
> the already present bundle's resources instead of using the byte[] from<br>
> the serialized Package ?<br>
><br>
> WDYT?<br>
><br>
> Thanks<br>
> --G<br>
><br>
> [1]. <a href="http://www.aqute.biz/Code/Bnd" target="_blank">http://www.aqute.biz/Code/Bnd</a><br>
><br>
> Le 25/10/2010 21:26, Edson Tirelli a écrit :<br>
><br>
>> Not exactly sure how helpful would it be to store the generated<br>
>> bytecodes in an osgi bundle. Anyway, there is no API right now to do<br>
>> that, but you can use reflection to achieve the same:<br>
>><br>
>> PackageCompilationData data = pkg.getPackageCompilationData();<br>
>> Field field = PackageCompilationData.class.getDeclaredField( "store" );<br>
>> field.setAccessible( true );<br>
>> Map<String, byte[]> store = (Map<String, byte[]>) field.get( data );<br>
>><br>
>> If you can justify the need for such an API, I guess we could be<br>
>> convinced to add one.<br>
>><br>
>> Edson<br>
>><br>
>><br>
>><br>
>><br>
>> 2010/10/25 Guillaume Sauthier<<a href="mailto:guillaume.sauthier@ow2.org">guillaume.sauthier@ow2.org</a>>:<br>
>><br>
>><br>
>>> Hi team<br>
>>><br>
>>> I've tried the IRC (without much success I admit), maybe here someone will<br>
>>> have some thoughts to share :)<br>
>>><br>
>>> I'm looking for a way to "intercept" the classes being generated by the<br>
>>> drools compiler.<br>
>>> I've seen that the classes bytecode is stored deep in<br>
>>> PackageStore/JavaDialectRuntimeData, so deep that I cannot easily access it<br>
>>> :)<br>
>>> The objective is to be able to give theses classes to Bnd (I want to store<br>
>>> all of that in an OSGi bundle) so that appropriate Import-Packages can be<br>
>>> computed. That will avoid to have DynamicImport-Packages all around my<br>
>>> bundles :)<br>
>>><br>
>>> Currently, what I get from the drools compiler is a<br>
>>> Collection<KnowledgePackage> but I have no API (or didn't find any) to<br>
>>> access (or know) the classes generated by the compiler.<br>
>>><br>
>>> Any ideas ?<br>
>>> Thanks<br>
>>> --Guillaume<br>
>>><br>
>>> _______________________________________________<br>
>>> rules-dev mailing list<br>
>>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
><br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Michael D Neale<br>home: <a href="http://www.michaelneale.net">www.michaelneale.net</a><br>blog: <a href="http://michaelneale.blogspot.com">michaelneale.blogspot.com</a><br>