> 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@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@lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> rules-dev mailing list
>
rules-dev@lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev