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
Some module system that allows the bundling of class and rules into
modules, and the specification of dependencies between them, is
Yes in the rule agent and the deployment configuration properties system.
On 9/26/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> Godmar Back wrote:
> On 9/26/07, Mark Proctor <mproctor(a)codehaus.org> wrote:
> Simple add the class at runtime to a classloader and use that classloader
> 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
> - 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.