axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 12769] - JWS deployment with packages broken
Date Mon, 30 Dec 2002 21:30:44 GMT
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?

Mime
View raw message