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 [EMAIL PROTECTED] 2002-12-30 21:30 ------- I'm going to copy some text from your mail from last March (http://www.mail- [EMAIL PROTECTED]/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?
