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
Show replies by date