Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "gianny DAMOUR" <gianny_damour@hotmail.com>
To: geronimo-dev@incubator.apache.org
Bcc: 
Subject: Re: [Deployment] IM Summary for Directory Issue
Date: Sat, 04 Oct 2003 01:27:28 +0200
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Message-ID: <Sea1-F101d26OUDxTcg00009484@hotmail.com>

On Fri, 3 Oct 2003 17:32:28 -0400 (EDT), Aaron Mulder wrote:
>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).
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.

>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