Yes perhaps... would not hurt to add the method to the interface... though in
most cases undeploy/deploy works fine. It is possible that we might want to
have redploy specific behavior... but we need to make sure that
undeploy/deploy also works in the same fashion. I think that if the
underlying impl uses undeploy and deploy then this will work fine & not add
any additional maintenece headache.
--jason
Quoting Jules Gosnell <[EMAIL PROTECTED]>:
> My penniesworth:
>
> I think it important that at some stage we introduce a concept of
> 'redeploy()'.
>
> From a quick glance at JSR 88, this looks to be an optional extension,
> but from an enterprise point of view I think that this is important.
>
> The default implementation could just 'undeploy(); deploy()' but a
> cleverer implementation will take exclusive locks on all input streams
> into JBoss (probably via interceptors) at the container level, so that
> redeployments can occur without requests being lost. They will simply be
> queued, delayed somewhat, and then eventually serviced.
>
> Any thoughts ?
>
>
> Jules
>
>
>
> 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
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
