The redeploy idea is similar to the idea of making mbean invocations (such
as on an ejb container) wait during service lifecycle operations -- so if
you stop and restart an mbean, calls are blocked until the start is done.
We were thinking of doing this in (model) mbean interceptors. Would
something like this be relevant for the redeploy stuff you are talking
about?
thanks
david jencks
On 2002.04.14 20:57:57 -0400 Jules Gosnell wrote:
> 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
> >
>
>
>
>
> _______________________________________________
> 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
