Godmar Back wrote:

I agree that it may not belong into the .drl file, though loading
bytecode through the classloader via getResourceAsStream() also seems
a rather ad-hoc solution.

I've already told you, that you are mistaken here. You do not need to keep bytecode hanging around, and available via getResourceAsStream() for any compilation to work. I can generate a class at runtime, in memory, add it to a classloader and have the engine compile against it without getResourceAsStream() being able to search for and return the .class' bytecode.

Some module system that allows the bundling of class and rules into
modules, and the specification of dependencies between them, is
clearly needed.

Yes in the rule agent and the deployment configuration properties system.

 - Godmar

On 9/26/07, Mark Proctor <mproctor@codehaus.org> wrote:

 Godmar Back wrote:
 On 9/26/07, Mark Proctor <mproctor@codehaus.org> wrote:


 Simple add the class at runtime to a classloader and use that classloader
as
the root classloader of the packagebuilder.


 This would work if the class loader I provide implements
getResourceAsStream to match its behavior in loadClass (which most
class loaders do) - so you are correct here.

The problem, however, is that I don't know which .jar files to include
in that class loader's path, *unless* I keep track of these .jar files
elsewhere - say in a configuration file, as a command line switch, or
by hardwiring it in my code.

My proposal is to allow the user to specify the location of these jar
files in the .drl file, which a special classloader would then
automatically include as it encounters this declaration in the .drl
file.

 - Godmar


 I don't think DRL files should be hard coded to Jars, I would rather see
this configuration else where. What you are talking about is deployment
configuraiotn issus, which is a difference concern and belongs in something
more like the RuleAgent. I beleve there are already plans to allow the
RuleAgent to specify locations to lookup classes at runtime.

 Mark