[rules-dev] Package merging

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