[rules-dev] Package merging

[Mark Proctor]

I've recently beeing reviewing the package merging code, as part of the 
smooks and jaxb dataloaders I've been workign on which require dynamic 
types to be generated at runtime - I noticed that the merging code isn't 
100% correct - although you don't notice the issues until you start to 
work with the dynamic type model in drools 5.0.

However fixing the merging to be correct, leaves a real issue with 
classloaders that there is no easy way to solve. The main issue we are 
getting is classloader proliferation. For a simple example the rule will 
have a compiled consequence that consequence references the classloader 
it was created in - when compiled in the packagebuilder. As part of the 
merging process we add the consequence byte[] to the rulebase 
classloader, so it can be used for rewiring. Lets say you add 100 
different packages in sequence, you'll end up with 100 classloaders, as 
each consequence references the classloader it was created in - atleast 
until a rewire is invoked and everything is redfined and rewired.

It gets more complicated with our dynamic type declarations, as the 
accessors and objecttypes are generated against those and we never put 
in mechanisms to rewire those - which means when you add the dynamic 
type to the rulebase and a user instantiates from that, it'l end up with 
a difference class to the one the objectype and literal constraint readers.

So I've been trying to come up with a more robust way, but it's not easy 
and will have a small impact on build performance :( My current proposal 
is this:
-Compile evals, consequences put them in the dialect stores, but do not 
define and resolve them and do not actual wire them up - this will be 
done lazily when added to the rulebase.
-The ClassObjectType implementation should have a dummy String for the 
classname, which is resolved when added to the rulebase (so it resolves 
against the correct dynamic type declaration). If we eventually allow 
dynamic type declarations to be updateable (which we need to do so) we 
will need to detect which ClassObjectType reference classes in our own 
internal classloders, so they can be re-wired.
-Read acessors will need to be done lazily, when added to the rule base. 
Like the ClassObjectTypenode we will need to detect if it uses classes 
in our internal classloaders, so that it obeys rewiring.

Mark