David Jencks wrote:
I don't understand a couple of things about your idea yet.
1. Why isn't the set of urls another g-bean, namely a ClassSpace mbean? I'd think this mbean could drive the acquisition of the jars from the repository.
It's a chicken/egg thing. The config state cannot be instanciated until the classloader is set up (as you can't load the classes for the GBeans until you know the classpath) so you need a two phase start up:
phase1: create the classloaders
phase2: load the configured instances
Yes, this will be a ClassSpace GBean when it is running, and it could be be persistent form of the ClassSpace is just the list of URLs, but the key thing is that the classpath starts before the others are loaded.
2. Why would you have the deploying servers sort the plans rather than have the deployer framework sort them? What would result in different orders on different machines?
The whole concept of plans etc goes away. Each server gets a config (classpath + state) and starts it - that may work differently on different systems (e.g. start may fail on one node but work on the rest). The dependency manager sorts that out.
One thing I didn't mention is that redeployment gets hazy. It really becomes build a new version of the config and this can actually happen in the deployment VM rather than the online server. This means that nothing happens to the online system during the entire time the config is being generated, so validation/config errors will not impact the server. The only time the server is affected is when the current config is stopped and the new one started (and if the new one fails to start it should be fairly simple in most cases just to revert to the old one).
3. Is it necessary to specify the serialization mechanism for g-bean config? I'd like to avoid over-reliance on xml and keep it easy to deploy everything in code with no xml or dds in sight.
It is not necessary - something takes the in memory state and is responsible for save/restore but the format does not matter. I actually intend to start with object serialization (KISS) with the option for XML later (as I think admins will want to be able to see it in vi even though we probably don't want them editing it directly in the config store).
If it doesn't break anything important I think it's worth considering just checking it in.
It doesn't as I tried to add things in parallel. However, there are some things I was trying to get sorted out in my head and didn't want to commit half-baked ideas. However, with Aaron/Jacek talking validation, my problem with EJB startup and Brendan looking to get involved I wanted to say something about my thinking. I'll try and get it in this weekend (a new module, deployment), unless I decide it was all turkey induced craziness :-)
-- Jeremy
