Sure, I'll connect to the IRC I hope that we have compatible time zone ;) (I'm in France)
--G Le 28/10/2010 18:05, Edson Tirelli a écrit :
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<[email protected]>: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]> 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]> 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]>: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] 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_______________________________________________ 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_______________________________________________ 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
<<attachment: guillaume_sauthier.vcf>>
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
