<!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">
<br>
<br>
Le 02/11/2010 23:29, Mark Proctor a écrit :
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
On 02/11/2010 11:02, Guillaume Sauthier wrote:
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite">Hi Mark <br>
It's nice to have your view on the this subject (even if it disassemble
my current plan ;) ) <br>
<br>
Le 28/10/2010 18:17, Mark Proctor a écrit : <br>
<blockquote type="cite">I actually want to move away from compile
time generated bytecode inside <br>
of the packages. Instead I want to move to just keeping validated <br>
Strings that can be executed via MVEL. Additional we would use ASM to <br>
bytecode compile often used strings at runtime. <br>
</blockquote>
<br>
Isn't it the role of the MVEL Optimizers (I've read they have something
based on ASM) ? <br>
BTW, are theses classes generated when rule Package are compiled ? <br>
</blockquote>
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.<br>
</blockquote>
<br>
"flat" code generation ?<br>
<br>
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite"> <br>
<blockquote type="cite">So I think giving you direct access to
generated bytecode would be a bad <br>
thing, it's internal and unstable and you can be sure we'll change it
as <br>
we want. <br>
</blockquote>
<br>
In a way, I don't care of what is inside the bytecode. <br>
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. <br>
<br>
I only need the bytecode (and an API to get them cleanly ;) ). <br>
</blockquote>
Get BND to accept a String of imports, and write an ant utility to
extract them from Drools.<br>
</blockquote>
<br>
That's also doable<br>
<br>
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite"> <br>
<blockquote type="cite">What you want is to ensure that certain
types are imported so Drools can <br>
see them, right? <br>
</blockquote>
Yes, I want to ensure that generated classes in the bundle have all
their imports/requirements fulfilled. <br>
<blockquote type="cite">So instead we should be looking at some
sort of <br>
analysis tool to provide this, we sort of have this already, but it <br>
won't be complete for your purposes but can be extended. So it tells
you <br>
want classes are used and were, and you can use the drl parser to <br>
extract imports etc. <br>
</blockquote>
<br>
Can you give me some pointer(s) on what Drools currently have ? <br>
</blockquote>
The Drools DRL parser produces a Descr model of classes that provides
things like imports.<br>
</blockquote>
<br>
OK I see this structure.<br>
<br>
One question (again):<br>
Does thes imports are reflecting all the real imports of the generated
classes ?<br>
I mean, it's kind of obvious that they reflect the imports we place in
the drl files, but do they also have internal imports?<br>
<br>
For example, I've seen that there are some mvel templates that seems to
be used to be generate the code ("javaInvokers.mvel" for example).
Theses templates are using classes that are not directly part of the
rule description but are required to hook up the generated code within
drools:<br>
<br>
<tt>@declare{"getMethodBytecode"}<br>
public java.util.List getMethodBytecode() {<br>
org.drools.core.util.asm.MethodComparator.Tracer visit = new
org.drools.core.util.asm.MethodComparator.Tracer("@{methodName}");<br>
<br>
java.io.InputStream is =
getClass().getClassLoader().getResourceAsStream(
"@{package}.@{ruleClassName}".replace( '.', '/' ) + ".class" );<br>
<br>
java.io.ByteArrayOutputStream bos = new
java.io.ByteArrayOutputStream();<br>
byte[] data = new byte[1024];<br>
int byteCount;<br>
try {<br>
while ( (byteCount = is.read( data,<br>
0,<br>
1024 )) > -1 )<br>
{<br>
bos.write(data, 0, byteCount);<br>
}<br>
} catch ( java.io.IOException e ) {<br>
throw new org.drools.RuntimeDroolsException("Unable
getResourceAsStream for Class '@{ruleClassName}' ");<br>
}<br>
<br>
org.mvel2.asm.ClassReader classReader = new
org.mvel2.asm.ClassReader( bos.toByteArray() );<br>
classReader.accept( visit,
org.mvel2.asm.ClassReader.SKIP_DEBUG );<br>
org.mvel2.asm.util.TraceMethodVisitor trace = visit.getTrace();<br>
return trace.getText();<br>
}<br>
@end{}</tt><br>
<br>
This is primarily theses imports (<tt>org.drools.core.util.asm for
example</tt>) that I want to discover.<br>
<br>
<br>
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite"> <br>
<blockquote type="cite">The resouce type you suggest won't work.
The generated class is just for <br>
the consequence or some aslects of the "when" it is not the entire
rule, <br>
so in itself is not a complete resource. <br>
</blockquote>
<br>
Sure, a Package stores more than just the bytecode of generated stuff. <br>
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... <br>
<br>
<blockquote type="cite">Plus again I'd rather move <br>
complete away from this pre-compiled concept and more to validated <br>
strings with on the fly generation. <br>
</blockquote>
<br>
Usually, this is this (uncontrolled for OSGi) on-the-fly generation
that cause some harms. <br>
<br>
<blockquote type="cite">That said there is a need for environments
like app-engine which don't <br>
allow runtime bytecode generation and people want the perf boost of <br>
bytecode to have fully pre-compiled rule sets. <br>
</blockquote>
<br>
Theses are good use cases too. Considering that OSGi "don't allow"
runtime bytecode generation :) <br>
<br>
<blockquote type="cite"> I would consider <br>
something like this, where a .jar has all the pre-compiled rules. But
we <br>
are a long way from this, first we need to get an ASM rule compiler <br>
working, that can compile a complete rule, then we can look into a full
<br>
pre-compiled ruleset. <br>
</blockquote>
<br>
What do you call a full pre-compiled ruleset ? <br>
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. <br>
So I don't see how moving from eclipse compiler to ASM will make things
better for me. <br>
</blockquote>
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.<br>
</blockquote>
<br>
Something that could be independant of the dialect would be really
useful.<br>
<br>
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite"> <br>
<br>
So if I want to sum up the discussion at this point we have: <br>
* Only reflection trick to access generated bytecode <br>
* Analysis tools may be appropriate to have some insights of what will
be generated <br>
* Rule Pre-compilation is currently not available <br>
</blockquote>
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.<br>
</blockquote>
<br>
I understand that nobody wants someone to shout at him :)<br>
Anyway, what I basically would like is not a direct access to drools
internals, but to the final bytecode result (generated using a classic
java compiler, ASM or MVEL).<br>
I need only small changes to the Package API, that will expose (or give
access to) the generated bytecode like a blackbox, no drools internals
exposed, just a byte[].<br>
<br>
Thanks<br>
--G<br>
<br>
<blockquote cite="mid:4CD090B8.7060709@codehaus.org" type="cite">
<blockquote cite="mid:4CCFEFE0.4010700@ow2.org" type="cite"> <br>
--G <br>
<br>
<blockquote type="cite">Mark <br>
On 26/10/2010 08:49, Guillaume Sauthier wrote: <br>
<blockquote type="cite">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" class="moz-txt-link-freetext"
href="http://www.aqute.biz/Code/Bnd">http://www.aqute.biz/Code/Bnd</a>
<br>
<br>
Le 25/10/2010 21:26, Edson Tirelli a écrit : <br>
<blockquote type="cite"> 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"
class="moz-txt-link-rfc2396E" href="mailto:guillaume.sauthier@ow2.org"><guillaume.sauthier@ow2.org></a>:
<br>
<br>
<blockquote type="cite">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" class="moz-txt-link-abbreviated"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
_______________________________________________ <br>
rules-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
<br>
<br>
<br>
</blockquote>
<br>
_______________________________________________ <br>
rules-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
<br>
<br>
<br>
</blockquote>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<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>