Thanks.
You are right. While the saving issue can be solved by my means, as you can get all classes by reflection, this would not solve reloading, where class list needs to be known.
The solution you propose could only work in all cases if the injected class loader is the boot one, which is dependent on how virtual machine was started, thus unreliable. Platforms tend to isolate modules by adding hierarchies of class loaders, which would make this injection effective only to a limited scope.
Nevertheless, if we could define persistence units programmatically, there might be a way.
Each module would call a static method of a class, which, in turn, would get the boot classloader to store class names in a list, along with persistence unit name.
addToPersistenceUnit( String unitName, String className)
addToPersistenceUnit( String unitName, List<String> classNames)
Parameters for persistence would also be given through a static method, with first parameter being the name of the persistence unit. The main program, or one of its module, would fill those remaining parts, which could be driven by preferences of application.
Then, getting the persistence unit would be almost the same as actually, from the name, but it would be read from global list and not from an xml.
Key of the mechanism is that storage should be done in lowest possible classloader and would have the advantage of running without specific vm parameters.
The only reason for this to fail would be that classes to handle global persistence units are not present (error in installation of the jar). Maybe also someone would be evil enough to completely forbid access to boot classloader and modules get isolated so much that even basic classes are under a specific loader.
I wonder the feasability of this...
[Message sent by forum member 'pepe' (pepe)]
http://forums.java.net/jive/thread.jspa?messageID=205195