the problem will most likely be in j2eeserver code

*** Issue 38831 has been marked as a duplicate of this issue. ***

This is a little problematic. In tomcat we identify the application
with context path and this is in fact the only way how to identify it
AFAIK. It is not possible to redeploy an application when the context
path changes, you would need to undeploy and deploy from scratch (see
that if you undeploy the application from Runtime tab and then deploy
it again it is deplyed to the new path).

The solution is probably to add a special condition for this into
TargetServer.processLastTargetModules. It currently compares what was
deployed to the server and what is there and does not compare the
actual URL of module. If the URL differs from the last deployment it
should do undeploy/deploy instead of redeploy or incremental
deployment. Does this work the same way for S1AS and for other types
of modules, Nam? Thanks.

Add Ludo for comments.
TMID.getWebURL() is for web modules only.  Conceivably we can check
for URL when the module involved is web module.  I just want to make
sure that for other platform where webmodule are not identified by
context root (say by relative location path), there are no other side
effects than just a one-time performance penalty of undeploy-fulldeploy.

How about checking TMID.getModuleID? That is the identity of module
that can be implemented more generally if, as you say, some server
uses different identification. Tomcat uses the URL for ID.

for j2ee 1.4 what we do is use the initial context root (and prepend
"_" to it to be the unique identifier for the web app.
After that, any redeployment, including of the same we bapp with a
different context root would work...
The main issue with that is that the user has little or no control
about this unique id and this might has nasty side effects.

All in all, this is a serious flaw is JSR88 that takes only archives
or stream and no identifier in order to deploy apps...
TMID.getModuleID should work I think...

We also need to check for the dependancy on JSP source level debugging
to access the repository area for compiled jsps...
Currently, the JSP finder method takes a context root. Could it take a
ModuleID instead?
FindJSPServlet:
public File getServletTempDirectory(String moduleContextPath);
if not, an internal live mapping od contextroot<->moduleID has to be
maintained.

There is also an easy solution: if the user changes the context path
property just inform them that they must unload and deploy again for
it to take effect.

Incremental deployment cannot be used in case that the plugin provides
its own location for files to be copied in since that location may
depend on the context path (and it does for tomcat).

I think that thing used for ID (whether MID or TMID) should stick with
the entity instance its used to identify.  So why Tomcat cannot assign
some lifetime MID, TMID as J2EE 1.4?

The problem with using TMID.getModuleID is that its does not uniquely
identify a module-deployed-on-target association.  If a deployment
manager has more than one TMID per MID than this scheme would not
work.  Say, if I can't find a TMID match the recorded one I go on to
check MID, and discover a TMID with same MID as the one in current
current recorded TMID of the module provider profile, should I
undeploy that TMID?  I guess I can if it have same target name as the
one recorded.  But I am at lost because why with same MID, same target
name could have different TMID?

Now I think the URL would not work either.  How can I get the web URL
from devmodule API/SPI?  
And this discussion brought up another issue that how we handle
automatic undeploy when we discover already deploy condition.  This
condition would happen on any platform when somehow users already have
 a module deployed (e.g. by some external tool) before any recorded
deployment by the IDE.  I would proposed a AlreadyDeployedException so
that tools can handle the situation gracefully.  This exception should
be thrown by  ID.incremental/initialDeploy or DM.distribute/redeploy
calls.

I think tmcat actually does the same thing as s1as. And I see that you
are right that it would be wrong to ask about identity again, I agree
it has to remain the same (i.e. the ID created when first deployed).

so does this leaves us only with the easy solution that I proposed?

as for the other issue you mentioned, Nam, I just got this bug report:
http://www.netbeans.org/issues/show_bug.cgi?id=39428

and I was going to just display the message about failer. How do you
propose to handle the situation better? I think the options are
limited in the running progress bar...

Pavel, yes the proposed easy solution could be temporary for now. 
Either you or I will do it in j2eeserver code.  Let me know if you
want me to take this action.

For issue 39428, I think tomcat plugin just need to generate
ProgressEvent FAILED  with proper message enough for user know what to
do, is good for now.

Complete solution for both is to make ID.incrementalDeploy to throws
AlreadyDeployException so j2eeserver would do stop/undeploy and
initialDeploy.  This one we should do after beta.

We discussed another solution - to base the indentity of deployed
modules on shomething else then context path. Nam is working
implementation (tx!)

Pavle or Nam, what is the progress on this issue?

This is one of the case covered by auto-undeploy implementation I just
checked in.  Change to new context root value should work now. 
However, switching modules to a shared context root is not supported
at this time.  To enable this Tomcat plugin implementation of
TMIDResolver need to return a TMID when query included module
directory.  Currently the preliminary implementaion I put in would
return emtpy TMID list.

verified