I think this email can be ignored, I'm attempting a different and
hopefully better approach.
Mark
Mark Proctor wrote:
Part of the development I'm dong for Drools 2.5 involves class
generation to disk and the building of Jars. Previously classes were
generated to byte[] and added to the ClassLoader all in memory, as
part of the Janino scripting API - this has several disadvantes from
insistance on runtime compilation (not fun on very large RuleBases)
and lack of debugging. Now though the conditions and consequences of
each RuleSet compile down to .java and .class files in the temp disk -
from which source and binary jars are created. We then create a
classloader and use reflection to wire-up the classes, in the binary
jar, to the methods that call the conditions and consequences in the
RuleSet; finally the RuleSet itself is serialised into the Jar.
Drools deploment is now simply a matter of adding one or more URLs to
the RuleBase that point to binary jars; where it creates a
URLClassloader per RuleSet binary jar, deserialises the RuleSet object
from the jar and adds it to the RuleBase (where is decomposed into a
Rete graph) - this all works.
One of the issues I'm looking into is the temp dir usage with clean up
and JEE integration issues. I'm currently left worrying that there
will be a proliferation of drools temp directories and jars over time,
secondly is acces to disk an issue for JEE systems?
I spent some time looking to see if its possible to have an in memory
byte[] URL - while there are techniques to hardcode the byte[] to the
provided URLStreamHandler of the URL these are ignored by URLClassPath
which creates a new URL from the provided spec.
The only solution for totally in memory operation is to have a new
memory:// MemoryURLStreamHandler, MemoryURLStreamHandlerFactory,
MemoryURLConnect implementations with resident hashmap backed service
providing the data - I believe JProxy has something like this. I
figured that was getting out of the scope of the Drools project and
figured I would turn to the experts for guidance on this :) Maybe this
isn't an issue at all and I'm ok letting the temp directory usage
grow, leaving it to the OS and the User to clean out from time to time.
Mark
