https://issues.apache.org/bugzilla/show_bug.cgi?id=47467
--- Comment #3 from Uwe Günther <u...@cscc.de> 2009-09-25 16:25:48 PDT ---
Thats what I thought as well when I started with this bug. This jar:file:
syntax is based on an URLConnection and there isn't one used in the whole
MangerServlet or HTMLManagerServlet code. That shows to me jar:file: syntax is
only in the docs to document a function we simply do not have in the code at
all.
I checked the svn history 2 years back and there was no jar:file:... URL syntax
at all. Means I could not found any URLConnections in the code and its history.
Maybe the original author could give us some historical inside knowledge, but I
think this is late back to tomcat 4.x.x.
At the moment I can't even dream up a scenario where you could use a jar:file:
URLConnection like syntax or where it would make sence, but thats me. :-)
Lets go back to what does till now: There are basically two deployment
strategies in the HTMLManagerServlet:
1.) local deployment (webapp *.war or webapp dir must be locally accessable
from tomcat to get copied via GET command to the webapps dir)
2.) remote deployment (only a webapp *.war can be remotely copied to the
webapps dir via POST resp. PUT)
Either you deploy a local dir or war as webapp or you deploy a remote war as
webapp. In both cases the ManagerServlet does only simple copy operations to
copy the local war / dir or the remotely uploaded war to the webapps dir.
Anyway, in both cases tomcat gets told via JMX in the ManagerServlet to use the
new copied webapp dir resp. explode the new copied *.war file and use it.
I have taken the whole ManagerServlet#deploy(PrintWriter writer, String config,
String path, String war, boolean update) method in to pieces to fully analyze
and understand it, so I can say what is going on and what gets wrong here.
There are even some other strange bugs in this method: Lets say you have 3
params, each of them can have a value or can be null, so this leads us to 2^3=8
diffrent combinations where 5 of them are complete valid ones and 3 are invalid
ones. The existing code only works for 2 of 5 valid cases and does some odd
thing in the other 3 cases. For more details see my attachment which is listing
the cases.
I reworked only this single ManagerServlet#deploy(...) mehtod but created 4 new
classes to handle complexisty / special cases, because the method had been
grown in to a hard to handle beast. :-)
Since today afternoon I have a working version running on my dev box together
with the trunk code. I am currently setting up a local testing scenarios to
seriously test that new code. Not only, but because it gets used via HTTP from
the Ant DeployTask, the ManagerServlet and the HTMLManagerServlet webapp
frontend. But it looks ok until now.
--
Kind Regards
Uwe Günther
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
