You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Doug Davis <du...@us.ibm.com> on 2001/12/01 13:52:29 UTC

Re: Undeployment

I assume it was an oversight, but don't forget about
undeploying transports too.  And I'd go for undeploying
global config's - setting them to something empty isn't
as intuitive (although making it empty will have the same
result).
-Dug


"Glen Daniels" <gd...@macromedia.com> on 11/30/2001 04:51:40 PM

Please respond to axis-dev@xml.apache.org

To:   <ax...@xml.apache.org>
cc:
Subject:  Undeployment



I'm in the midst of implementing undeployment, and here's a quick summary
of
my current plans.

1) Make a separate <undeployment> element which can also be the top level
of
a WSDD document that gets deployed into an engine via the AdminClient.

2) <undeployment> allows children <handler>, <service>, <typeMapping>, and
<chain>.  (should we allow <globalConfiguration> to be undeployed, or just
state that you deploy an empty one if you want that?)

3) Any attributes other than "name" on those children (except for
<typeMapping>, which allows "qname" and "languageSpecificType") will be
ignored.

4) An undeployment will be processed in lexical order, which allows us to
think about reference counting later.  In other words, you shouldn't be
able
to undeploy a Handler until all references to that Handler (in chains,
services, etc) have themselves been undeployed.

Thoughts?  Potential issues?

--G