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
