3:11 a.m.
No it's not fundamentally an issue with OSGi.
The proof is that we already have rule working in an OSGi environment.
But, it's working because of workarounds:
* Use DynamicImport-Package * that breaks OSGi modularity
* or Manage yourself your ClassLoader so that you can access both Drools
runtime classes and your application classes
Both of theses solutions are kind of trick.
I think it would be better (from a pure OSGi point of view) to have all
theses classes generated in the bundle and not on the fly.
--Guillaume
Le 28/10/2010 09:45, Michael Neale a écrit :
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.
On Thu, Oct 28, 2010 at 6:39 PM, Guillaume Sauthier
<guillaume.sauthier(a)ow2.org <mailto:guillaume.sauthier@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(a)ow2.org
<mailto: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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev