I agree. redeploy is different, or could be different and in some cases (like
yours) should be different than undeploy/deploy.
--jason
Quoting Jules Gosnell <[EMAIL PROTECTED]>:
> Jason Dillon wrote:
> > 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
>
> Yes and No.
>
> Take Jetty for instance.
>
> If Jetty is not going to drop any requests during a redeployment, then
> Jetty needs to know that it is performing a redeployment, and not an
> undeployment.
>
> In the former case, resources such as web contexts (used for dispatching
> requests) should be maintained and locked, until the following
> deployment is complete. In the latter they must be released immediately.
>
> This is container specific behaviour that the deployer cannot predict.
>
> I am suggesting a layered interface, where, if you have no specific impl
> for redeploy(), your superclass provides redeploy(){undeploy();
> deploy()} but any container is free to override this with a more
> tailored approach.
>
> If you simply use redeploy as an alias for undeploy/deploy then I don't
> see much purpose in having it. The point is that it gives you more than
> just concatenating these two operations together.
>
> Jules
>
>
> >
> >
> > 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
> >
>
>
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
