DeploymentScanner implements a JMX managed operation in order to add a URL to its scanner. So, I've got the feeling that one can distribute where we want.1) We will save all distributed files to one directory, and we will set that to be the same as the "deploy" directory by default (keeping all deployments in the same location, whether by user-copied files or by JSR-88).
2) For each application module in the deploy directory, we will save the
Geronimo-specific DD outside the module, with a name based on the module
name ("foo.war" gets the DD "geronimo-deployment-foo.war.xml" or something
along those lines).
I agree on the general idea. However, what do you think of the following?
It seems to me that we will need rather quickly a mean to persist J2EEManagedObject. Based on previous mails, Dain has this task on its to-do and will support.
Indeed, if I understand correctly the problem, one only needs to persist the state of various components between server start-ups.
For instance, the DeploymentManager distributes an application component to a specific server and puts it in a "distribution" directory. When one requests the start of this specific component, one could simply add to the DeploymentScanner a new URL referencing this "distribution" directory. The DeploymentScanner will then do its job as expected.
Now the problem is, what happen when the server is shut-down? Does it mean that I will have to reconfigure the DeploymentScanner?
I think that a possible answer is to persist the set of URL scanned by the DeploymentManager and re-use this persisted state to re-configure the DeploymentScanner on server start-up.
This problem is the same one for all the application components and can be answered by persisting the J2EEManagedObject abstracting them.
For instance, when a RAR is started, one can call a "Persistence Service" on the MBean mirroring this RAR and this service will persist somewhere and somehow that the new state of this ManagedObject.
I really like the idea of putting this state in an easy to read XML file (why not an enhanced DD). However, one could also persist via standard serialization the state but it means that we will need to support a tool to edit easily such serialized instances.
However, what do you think about defining a single XML repository? I see some advantages:
For instance, to implement the DeploymentManager.getAvailableModules is trivial: one reads the repository and that is it. If one have multiple repository (multiple XML files), a possible implementation is to query directly the MBeanServer and even if it is easy to implement, an end-user will not be able to search via a standard text editor what is by now deployed.
In other words, I agree on the fact that one will need to persist the state of server components between start-up. However, I think that this is the responsibility of a "Persistence Service" to tackle this problem.
Gianny
_________________________________________________________________
MSN Messenger 6 http://g.msn.fr/FR1001/866 : ajoutez une image � votre pseudo pour dialoguer avec vos amis
