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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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<[email protected]
<mailto:[email protected]>>:
>>
>>
>>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>
>>
>>
> _______________________________________________
> rules-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
