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

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&lt;guillaume.sauthier(a)ow2.org&gt;: > > >> 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 >> >> >> >> > > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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&lt;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

For the maven-plugin thing, have a look here: http://drools-java-rules-engine.46999.n3.nabble.com/maven-drools-plugin-t... Leo. On Thu, Oct 28, 2010 at 9:39 AM, 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&lt;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 _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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./

On Thu, Oct 28, 2010 at 10:12 AM, Guillaume Sauthier <guillaume.sauthier(a)ow2.org <mailto:guillaume.sauthier@ow2.org>> 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-t... > > Leo. > > On Thu, Oct 28, 2010 at 9:39 AM, 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&lt;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 > > > > _______________________________________________ > 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 https://lists.jboss.org/mailman/listinfo/rules-dev

Guillaume, Do you think you can show up on IRC so that we can discuss this live? I am not opposed to exposing the package compilation data, but it is a very sensitive part of the code and we need to think carefully about the consequences of doing it and how to do it if that is the case... Edson 2010/10/28 Guillaume Sauthier&lt;guillaume.sauthier(a)ow2.org&gt;: > > 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 > <guillaume.sauthier(a)ow2.org&gt; 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-t... >> >> Leo. >> >> On Thu, Oct 28, 2010 at 9:39 AM, Guillaume Sauthier >> <guillaume.sauthier(a)ow2.org&gt; 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&lt;guillaume.sauthier(a)ow2.org&gt;: >>>>> >>>>> >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > >

That wouldn't cover things like "Just in time" code generation in things like MVEL though. On Thu, Oct 28, 2010 at 7:55 PM, Leonardo Gomes <leonardo.f.gomes(a)gmail.com <mailto:leonardo.f.gomes@gmail.com>> wrote: 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./ On Thu, Oct 28, 2010 at 10:12 AM, Guillaume Sauthier <guillaume.sauthier(a)ow2.org <mailto:guillaume.sauthier@ow2.org>> 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-t... > > Leo. > > On Thu, Oct 28, 2010 at 9:39 AM, 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&lt;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 > > > > _______________________________________________ > 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

I actually want to move away from compile time generated bytecode inside of the packages. Instead I want to move to just keeping validated Strings that can be executed via MVEL. Additional we would use ASM to bytecode compile often used strings at runtime.

So I think giving you direct access to generated bytecode would be a bad thing, it's internal and unstable and you can be sure we'll change it as we want.

What you want is to ensure that certain types are imported so Drools can see them, right?

So instead we should be looking at some sort of analysis tool to provide this, we sort of have this already, but it won't be complete for your purposes but can be extended. So it tells you want classes are used and were, and you can use the drl parser to extract imports etc.

The resouce type you suggest won't work. The generated class is just for the consequence or some aslects of the "when" it is not the entire rule, so in itself is not a complete resource.

Plus again I'd rather move complete away from this pre-compiled concept and more to validated strings with on the fly generation.

That said there is a need for environments like app-engine which don't allow runtime bytecode generation and people want the perf boost of bytecode to have fully pre-compiled rule sets.

I would consider something like this, where a .jar has all the pre-compiled rules. But we are a long way from this, first we need to get an ASM rule compiler working, that can compile a complete rule, then we can look into a full pre-compiled ruleset.

Mark On 26/10/2010 08:49, Guillaume Sauthier wrote: > 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&lt;guillaume.sauthier(a)ow2.org&gt;: >> >> >>> 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 >>> >>> >>> >>> >> >> > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

On 02/11/2010 11:02, Guillaume Sauthier wrote: > Hi Mark > It's nice to have your view on the this subject (even if it > disassemble my current plan ;) ) > > Le 28/10/2010 18:17, Mark Proctor a écrit : >> I actually want to move away from compile time generated bytecode >> inside >> of the packages. Instead I want to move to just keeping validated >> Strings that can be executed via MVEL. Additional we would use ASM to >> bytecode compile often used strings at runtime. > > Isn't it the role of the MVEL Optimizers (I've read they have > something based on ASM) ? > BTW, are theses classes generated when rule Package are compiled ? I'm actually implementing this as an MVEL optimisation. At the moment MVEL only ASM's setters and getters. I want full "flat" code generation so effectively the generated code is standalone, even if it was generated from mvel. There is no ETA for this.

> >> So I think giving you direct access to generated bytecode would be a >> bad >> thing, it's internal and unstable and you can be sure we'll change >> it as >> we want. > > In a way, I don't care of what is inside the bytecode. > I'm only giving it to a bytecode parsing tool (aQute's Bnd) that will > see what needs to be imported. So if there is some bytecode, I'm > happy. if you change what code is generated, that will not affect me > because Bnd will see that the imports have changed and will construct > the bundle's manifest appropriately. > > I only need the bytecode (and an API to get them cleanly ;) ). Get BND to accept a String of imports, and write an ant utility to extract them from Drools.

> >> What you want is to ensure that certain types are imported so Drools >> can >> see them, right? > Yes, I want to ensure that generated classes in the bundle have all > their imports/requirements fulfilled. >> So instead we should be looking at some sort of >> analysis tool to provide this, we sort of have this already, but it >> won't be complete for your purposes but can be extended. So it tells >> you >> want classes are used and were, and you can use the drl parser to >> extract imports etc. > > Can you give me some pointer(s) on what Drools currently have ? The Drools DRL parser produces a Descr model of classes that provides things like imports.

> >> The resouce type you suggest won't work. The generated class is just >> for >> the consequence or some aslects of the "when" it is not the entire >> rule, >> so in itself is not a complete resource. > > Sure, a Package stores more than just the bytecode of generated stuff. > But I was thinking that if theses pre-compiled classes where already > in the bundle, it was a waste of resources to also have them in the > serialized Package resource... > >> Plus again I'd rather move >> complete away from this pre-compiled concept and more to validated >> strings with on the fly generation. > > Usually, this is this (uncontrolled for OSGi) on-the-fly generation > that cause some harms. > >> That said there is a need for environments like app-engine which don't >> allow runtime bytecode generation and people want the perf boost of >> bytecode to have fully pre-compiled rule sets. > > Theses are good use cases too. Considering that OSGi "don't allow" > runtime bytecode generation :) > >> I would consider >> something like this, where a .jar has all the pre-compiled rules. >> But we >> are a long way from this, first we need to get an ASM rule compiler >> working, that can compile a complete rule, then we can look into a full >> pre-compiled ruleset. > > What do you call a full pre-compiled ruleset ? > With my limited understanding, I consider an ASM compiler just like > the old java compiler (it's just faster): it's another way to produce > the same thing: executable bytecode. > So I don't see how moving from eclipse compiler to ASM will make > things better for me. yes I more meant we'll be revisiting how we do compiled stuff in Drools when we redo the ASM based compiler as an extension to MVEL. At this point we'll also look at allowing the bytecode to just be stored externally, such as in a zip. That would provide what you need, but we just aren't there yet. So for now maybe stick with descr analysis, which will work regardless of java or mvel dialec etc.

> > > So if I want to sum up the discussion at this point we have: > * Only reflection trick to access generated bytecode > * Analysis tools may be appropriate to have some insights of what > will be generated > * Rule Pre-compilation is currently not available The current way bytecode is stored we aren't going to expose in a manner you want, it's just exposing way too many internals for things we want to change soon. And users tend to shoult at us if we change things they are using. you can always do a patch that does what you need and worked off that patched version of drools.

> > --G > >> Mark >> On 26/10/2010 08:49, Guillaume Sauthier wrote: >>> 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&lt;guillaume.sauthier(a)ow2.org&gt;: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev