> I'm not entirely sure what you mean by the subdeployer's lifecycle. If
you
> mbean the sequence of init, create, start calls, note that these are not
> done all at once per package, but each step is run through every
subpackage
> before the next is started. Keeping the functionality in MainDeployer
> prevents a rogue SubDeployer from failing to deploy subpackages. Perhaps,
> however, allowing this would be a good idea.
Basically, I propose that the sub-deployers should be able to process their
own nested deployments, and manage their lifecycles. In my previous
message, I implied that we replace the init/create/start with a single
deploy (and also the stop/destroy with undeploy). Sorry, I was simplifying
things for discussion - I don't really know if that is feasable or not. My
point was that the MainDeployer should not have to know about its
SubDeployer's nested deployments. Nor should the EARDeployer be concerned
if a nested war happens to have a jar file in its WEB-INF/lib directory.
This lifecycle flexibility allows, for example, the EARDeployer to do the
init / create / start methods on all ejb archives, before processing any of
the war files (just a hypothetical, I have not actually thought about this).
Of course, the SubDeployerSupport would provide a default implementation.
> So is your idea that the only thing the MainDeployer is really does is
find
> the deployer for each package and subpackage, and once found the deployers
> themselves do all the work including calling subpackage deployers? It
> would work, I don't have an opinion yet on if it is a good idea.
Yes, that is what I am proposing. I envision most of the standard
MainDeployer code being moved into SubDeployerSupport. If you take a look,
this is what my nested-archive patch has already done with some of the
logic. Basically, I have found it constraining to go through MainDeployer
for my previous development. These changes would give each SubDeployer all
the power currently held by MainDeployer, with very little extra work on the
developer.
-Larry
>
> Thanks
> david jencks
>
> On 2002.04.14 17:16:03 -0400 Larry Sanderson wrote:
> > I have been working with the deployers for the last week or so, and I
> > have been thinking about some design changes that would help clean it
up.
> >
> > I see two major problems with the current usage: 1) MainDeployer is a
> > bootstrapped class, with no way to provide an alternate implementation,
> > 2) All SubDeployers rely on a concrete implementation of deployer:
> > MainDeployer,
> >
> > The first problem is easy to fix: provide a System-Property style
> > configuration for an alternate bootstrapped deployer.
> >
> > The second problem is not so easy. I propose that we give more control
> > to the SubDeployers, and simplify the bootstrap deployer. I propose
that
> > we move all life-cycle management of SubDeployers to the particular
> > implementations of SubDeployer. This eliminates the need for the
> > bootstrapped deployer to manage each SubDeployer's life cycle. Further,
> > the bootstrapped deployer no longer has to manage DeploymentInfo objects
> > - this job has been passed down to the SubDeployer as well. This allows
> > each SubDeployer to create their own implementations of DeploymentInfo.
> > Finally, DeploymentInfo needs to be cleaned up - it has become a
> > repository for disparate, and often unnecessary information. Since
> > SubDeployers are now allowed to create their own implementations, all
but
> > the most common attributes can be removed.
> >
> > Here are my thoughts for the public class structure:
> >
> > [code]
> > public interface SubDeployer
> > {
> > boolean accepts(URL url);
> > boolean deploy(URL url);
> > boolean unDeploy(URL url);
> > boolean isDeployed(URL url);
> > DeploymentInfo getDeploymentInfo(URL url);
> > }
> >
> > public interface Deployer extends SubDeployer
> > {
> > SubDeployer getSubDeployer(URL url);
> > void addDeployer(SubDeployer deployer);
> > void removeDeployer(SubDeployer deployer);
> > }
> >
> > public class DeploymentInfo
> > {
> > // General cleanup
> >
> > // make members private with accessors / mutators
> >
> > // remove "SubDeployment" specific attributes
> > // (webContext,manifest,document metaData,etc...)
> > // These can be provided with subDeployment specific
> > // subclasses.
> > }
> > [/code]
> >
> >
> > Let me know if you have any comments. I would like to get started on
> > this soon.
> >
> > Thanks
> >
> > -Larry
> >
> > _________________________________________________________
> > View thread online:
http://main.jboss.org/thread.jsp?forum=66&thread=12917
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
