3:23 a.m.
Sure
But for the moment my use case only covers rules using Java Dialect.
I don't know MVEL stuff, does it works like the Java dialect ? (ie
parsing the rule, building some java code from it and then compile
everything ?)
--G
Le 29/10/2010 00:24, Michael Neale a écrit :
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<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