Re: [rules-dev] Accessing Drools compiled classes
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>