I would have thought this was related.
I think I remember remarking that JSR 88 had deploy/start/stop/undeploy
and redeploy, but no restart...
I think for completeness we should probably support restart as well.
No-one should be forced to implement these extensions. They should
simply be available if a container wished to provide a more intelligent
level of service.
Jules
David Jencks wrote:
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
