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
- [drools-dev] Temp disk usage for generated Jars Mark Proctor
-
