DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12769>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12769
JWS deployment with packages broken
------- Additional Comments From gdaniels@macromedia.com 2002-12-30 21:30 -------
I'm going to copy some text from your mail from last March (http://www.mail-
archive.com/axis-dev@xml.apache.org/msg01598.html), Mark:
> Case 1: No package statement in .jws file, copy it to webapps/axis
> - This URL works. http://localhost:8080/axis/BasicMath.jws?wsdl.
Right, easy.
> Case 2: No package statement in .jws file, copy it to webapps/axis/mypkg.
> - This URL works. http://localhost:8080/axis/mypkg/BasicMath.jws?wsdl.
This is a case we explicitly support, though I'm not sure exactly why. You
can put a jws file anywhere in your webapp hierarchy, and we'll happily
compile it to a matching location underneath your JWS class dir (usually
jwsClasses). So you'd get axis/WEB-INF/jwsClasses/mypkg/BasicMath.class in
this case), with a custom classloader which knows where that file is.
> Case 3: "package mypkg;" in .jws file, copy it to webapps/axis
> - This URL doesn't work.
> http://localhost:8080/axis/mypkg/BasicMath.jws?wsdl.
This is because the class name we end up looking for is precisely the file
name of the JWS file. So even if you used the somewhat better
URL "...axis/BasicMath.jws?wsdl" to point to the real JWS file, we would try
to load the "BasicMath" class instead of the "mypkg.BasicMath" class, which
would fail. In this case, the compiler would put the class file in WEB-
INF/jwsClasses/mypkg/BasicMath.class, because it's output dir is jwsClasses
and the class has a package "mypkg".
For us to correctly find the class file and load the class in this case, we
would need to know that the class had a package. We could do this in one of
two ways - 1) grovel through the JWS file to find the package declaration
manually, or 2) assume that all JWS files are rooted in the server's root (the
webapp root), and any JWS files below the top level are expected to have a
package which matches their location in the hierarchy.
So "axis/mypkg/Foo.jws" would end up being "mypkg.Foo", etc.
> Case 4: "package mypkg;" in .jws file, copy it to webapps/axis/mypkg
> - I believe this is what you suggested I try in your last email.
> - This URL doesn't work.
> http://localhost:8080/axis/mypkg/BasicMath.jws?wsdl.
> - In fact, this creates BasicMath.class in webapps/axis/mypkg/mypkg.
This is because we're both creating the "matching" hierarchy as described in
case 2 above AND the class has a package so the compiler creates the
extra "mypkg" dir under the output dir.
As I see it, we have these options:
a) status quo, no package statements in JWS source, put them wherever.
b) go read through the source file before compiling to make sure we get the
right package, always compile to the base output dir, and remember the package
in a hashtable in JWSHandler. This is probably the most "accurate" solution,
but will require scanning through the source file up to the class declaration
each time we compile.
c) assume all JWS files have a package statement matching their position in
the directory hierarchy relative to the server root. So if someone asks
for "foo/bar/Thing.jws", we should try loading "foo.bar.Thing". This will
break some existing applications (like our JWS tests, which put jws files in
a "jws/" directory with no package statements).
Opinions?
|