<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sure<br>
But for the moment my use case only covers rules using Java Dialect.<br>
<br>
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 ?)<br>
<br>
--G<br>
<br>
Le 29/10/2010 00:24, Michael Neale a écrit :
<blockquote
cite="mid:AANLkTin65SpNo+O0cjO=LBkDra_S3K0cq95AD-AS4ujb@mail.gmail.com"
type="cite">That wouldn't cover things like "Just in time" code
generation in things like MVEL though. <br>
<br>
<div class="gmail_quote">On Thu, Oct 28, 2010 at 7:55 PM, Leonardo
Gomes <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:leonardo.f.gomes@gmail.com">leonardo.f.gomes@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It
could be a starting point for this part:
<div class="im"><br>
<br>
<blockquote
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"
class="gmail_quote"><i>maven plugin that precompiles the rule
discovered in the module and simply place the</i><br>
<i>
compiled classes in a given directory.</i><br>
</blockquote>
<br>
</div>
<div>
<div class="h5">
<div class="gmail_quote">On Thu, Oct 28, 2010 at 10:12 AM,
Guillaume Sauthier <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:guillaume.sauthier@ow2.org" target="_blank">guillaume.sauthier@ow2.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Thanks for the link Leonardo<br>
I did take a look at it, but it doesn't do what I want (extract the
generated classes from the Package) :'(<br>
--G<br>
<br>
Le 28/10/2010 09:49, Leonardo Gomes a écrit :
<div>
<div>
<blockquote type="cite">For the maven-plugin thing, have a look
here: <a moz-do-not-send="true"
href="http://drools-java-rules-engine.46999.n3.nabble.com/maven-drools-plugin-to-compile-DRL-s-at-build-time-td725751.html"
target="_blank">http://drools-java-rules-engine.46999.n3.nabble.com/maven-drools-plugin-to-compile-DRL-s-at-build-time-td725751.html</a><br>
<br>
Leo.<br>
<br>
<div class="gmail_quote">On Thu, Oct 28, 2010 at 9:39 AM,
Guillaume
Sauthier <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:guillaume.sauthier@ow2.org" target="_blank">guillaume.sauthier@ow2.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
Edison<br>
<br>
To be more concrete, I would like to create first a maven plugin that<br>
precompiles the rule discovered in the module and simply place the<br>
compiled classes in a given directory.<br>
<br>
Currently, I may use the reflection trick to access what I want (the<br>
PackageStore), but if it could be part of an API, that would be better
:)<br>
<br>
Does it seems weird ? Is a patch welcome for this problem ?<br>
<br>
--G<br>
<br>
Le 26/10/2010 09:49, Guillaume Sauthier a écrit :<br>
<div>
<div>> Thanks for your answer Edson.<br>
><br>
> The reason I have is that runtime generated stuff usually don't
fit well<br>
> in an OSGi model.<br>
><br>
> When you take a bundle, it has a statically defined set of
"imported<br>
> packages". that means that when the bundle has been compiled, a
list of<br>
> packages to be wired in at deployment time has been computed. This
list<br>
> of packages if inferred from what the .class files (in the bundle)<br>
> requires to be executed (think of them as external dependencies).<br>
><br>
> Now if we generate some classes at runtime in an OSGi environment,
we<br>
> can see that generated classes can have different (or additional)<br>
> requirements in terms of java packages. So usually, with OSGi,
that ends<br>
> up by adding a special header called DynamicImport-Package into the<br>
> MANIFEST, with the side effects of breaking modularity :-(<br>
><br>
> This is what I want to avoid by having access to the generated
classes<br>
> at the compilation phase: I can then use this bytecode (IOW giving
it to<br>
> Bnd [1]) to complete the Import-Package MANIFEST header with the
right<br>
> set of imported java packages.<br>
><br>
> As a second issue, less important for the moment and more runtime<br>
> oriented this time, I would like to know if/how we can add a new
kind of<br>
> Resource.<br>
> Once we have generated the bytecode in the compilation phase, we
can<br>
> assume that all the stuff is already here in the bundle. Why can't
we<br>
> use it ?<br>
> I've seen the PKG Resource type, but it's some kind of
serialization of<br>
> a whole Package, couldn't it be possible to have a new Package
type (or<br>
> way to create a Package) that can use the ClassLoader to get
access to<br>
> the already present bundle's resources instead of using the byte[]
from<br>
> the serialized Package ?<br>
><br>
> WDYT?<br>
><br>
> Thanks<br>
> --G<br>
><br>
> [1]. <a moz-do-not-send="true"
href="http://www.aqute.biz/Code/Bnd" target="_blank">http://www.aqute.biz/Code/Bnd</a><br>
><br>
> Le 25/10/2010 21:26, Edson Tirelli a écrit :<br>
><br>
>> Not exactly sure how helpful would it be to store the
generated<br>
>> bytecodes in an osgi bundle. Anyway, there is no API right now
to do<br>
>> that, but you can use reflection to achieve the same:<br>
>><br>
>> PackageCompilationData data =
pkg.getPackageCompilationData();<br>
>> Field field =
PackageCompilationData.class.getDeclaredField( "store" );<br>
>> field.setAccessible( true );<br>
>> Map<String, byte[]> store = (Map<String,
byte[]>) field.get( data );<br>
>><br>
>> If you can justify the need for such an API, I guess we
could be<br>
>> convinced to add one.<br>
>><br>
>> Edson<br>
>><br>
>><br>
>><br>
>><br>
>> 2010/10/25 Guillaume Sauthier<<a moz-do-not-send="true"
href="mailto:guillaume.sauthier@ow2.org" target="_blank">guillaume.sauthier@ow2.org</a>>:<br>
>><br>
>><br>
>>> Hi team<br>
>>><br>
>>> I've tried the IRC (without much success I admit), maybe
here someone will<br>
>>> have some thoughts to share :)<br>
>>><br>
>>> I'm looking for a way to "intercept" the classes being
generated by the<br>
>>> drools compiler.<br>
>>> I've seen that the classes bytecode is stored deep in<br>
>>> PackageStore/JavaDialectRuntimeData, so deep that I cannot
easily access it<br>
>>> :)<br>
>>> The objective is to be able to give theses classes to Bnd
(I want to store<br>
>>> all of that in an OSGi bundle) so that appropriate
Import-Packages can be<br>
>>> computed. That will avoid to have DynamicImport-Packages
all around my<br>
>>> bundles :)<br>
>>><br>
>>> Currently, what I get from the drools compiler is a<br>
>>> Collection<KnowledgePackage> but I have no API (or
didn't find any) to<br>
>>> access (or know) the classes generated by the compiler.<br>
>>><br>
>>> Any ideas ?<br>
>>> Thanks<br>
>>> --Guillaume<br>
>>><br>
>>> _______________________________________________<br>
>>> rules-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
><br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Michael D Neale<br>
home: <a moz-do-not-send="true" href="http://www.michaelneale.net">www.michaelneale.net</a><br>
blog: <a moz-do-not-send="true" href="http://michaelneale.blogspot.com">michaelneale.blogspot.com</a><br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
</body>
</html>