<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Godmar Back wrote:
<blockquote
cite="mid:719dced30709262142g1c9a4d29p7c06b2146968980e@mail.gmail.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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.<br>
<blockquote
cite="mid:719dced30709262142g1c9a4d29p7c06b2146968980e@mail.gmail.com"
type="cite">
<pre wrap="">Some module system that allows the bundling of class and rules into
modules, and the specification of dependencies between them, is
clearly needed.
</pre>
</blockquote>
Yes in the rule agent and the deployment configuration properties
system.<br>
<blockquote
cite="mid:719dced30709262142g1c9a4d29p7c06b2146968980e@mail.gmail.com"
type="cite">
<pre wrap=""> - Godmar
On 9/26/07, Mark Proctor <a class="moz-txt-link-rfc2396E" href="mailto:mproctor@codehaus.org"><mproctor@codehaus.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Godmar Back wrote:
On 9/26/07, Mark Proctor <a class="moz-txt-link-rfc2396E" href="mailto:mproctor@codehaus.org"><mproctor@codehaus.org></a> 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
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>