Questions regarding hot deployment and reloading of entity classes
Hello.
I'm in the process of writing the initial plans for a Open Source CMS system (LGPL licensed) based on Seam and other JBoss technologies. I am, however, having some issues on how to solve a few problems I'm having with getting Seam to meet the demands I have of the CMS' core functionality, or optionally figuring out how to adapt my requirements to more fit the “proper way” of doing things within Seam.
My biggest problem is that I'm intending for this CMS to be heavily plugin based, and I really want the users of the system to be able to install, uninstall, enable and disable plugins at runtime without forcing the user to restart the app server and such. I also want these plugins to be as “plain” as possible, containing mostly standard Seam components and JPA entity classes.
Herein lies a few issues; I've looked at ways to have the plugin classes reloaded upon request (my initial idea of a plugin is that one plugin equals one .jar file in the WEB-INF/lib/ directory). I've written a mock-up plugin manager class that re-reads the class path and looks for Seam annotated classes and injecting them into the context using the Component class, and while this feels a bit hack-ish, at least it works. Seams own hot deployment feature would be one solution, but as far as my reading and testing have gotten me, this only seems to apply to pure compiled Java classes deployed into WEB-INF/dev/, not changes in .jar-files elsewhere in the application – and these plugins will, most likely, have to be packaged in a jar format.
The other issue is getting Hibernate to pick up changes to the entity classes when the plugin manager gets asked to reload all plugins. I've considered several different approaches here, amongst others writing my own EntityManagerFactory (and potentially other, related classes) and having them support some kind of event that gets the factory to reconstruct the entity manager and specifically include the plugin-classes into the Persistence configuration.
All these ways of solving things though, seems both kind of dirty and not necessarily based on public APIs not subject to change either. It is my goal to keep this as version independent as possible (requiring a minimum version of some libraries will of course need to happen). Have I missed anything obvious here? Are there cleaner ways to approach this, or is it just not a way one is intended to write code based on these frameworks?
Neither of these are demands set in stone for the feature set of the CMS, but they are however sorely wanted features and I was planning to put in some extra work before I started the actual implementation to figure out if it was solvable in any way before I ditched the features all together.
Any input on these issues would be greatly appreciated.