SourceForge Submitter: mazzgolf .
Somewhat related to 1041495 - see that issue for the
hello.war attachment - the same war used to replicate
the problem in that issue is the same war that can be
used to replicate the problem for this issue. Same
platforms as well were used to replicate.

JBoss performs the cool feature of auto-modifying a web
service's WSDLs (including its imported/included WSDLs
and schemas).

However, in one instance that modification produces a
URL that does not point to the resource - I get a HTTP
500 instead.

Deploy the hello.war (rather than duplicate
attachments, see issue 1041495 for the attachment
there). This assumes issue 1041495 has been corrected
or worked around (I worked around it by fixing issue
1041495 inside a JPDA session and continuing).

Once the web service is deployed, look at the hello
service's WSDL. You will see an import of another WSDL
(this is correct):

<wsdl:import location="/hello/hello/?
wsdl&resource=../spec/wsrf/WS-ResourceProperties-
1_1.wsdl" ...

If you point your browser to that location, you can see
that WS-ResourceProperties-1_1.wsdl file. Looking at
that WSDL, you will notice that it, itself, imports
another file - this time a .xsd schema inside its
wsdl:types/wsd:schema element:

<wsdl:import namespace="..."
schemaLocation="/hello/hello?
wsdl&resource=../../wsa/WS-Addressing-2003_03.xsd">

That schemaLocation is incorrect - if you point your
browser to that URL, you will get a HTTP 500 and the
JBoss logs tells me "cannot obtain wsdl resource from:
WEB-INF/wsdl/wsa/WS-Addressing-2003_03.xsd".

Notice the ".." appears twice - I think that is
incorrect. I think it only needs to go up to the
immediate parent directory only - it should not have
gone up twice to its grandparent directory. This wsa
directory is located as a peer directory to wsmf (under
the spec parent - just like the WS-ResouceProperties-
1_1.wsdl is under wsrf which is under spec).

I think it should be:

schemaLocation="/hello/hello?wsdl&resource=../wsa/WS-
Addressing-2003_03.xsd"

However, when I put that URL in my browser, I still did
not get the .xsd served up - I again got a 500. Funny
thing is that the JBoss error log says it was still looking
for "WEB-INF/wsdl/wsa/WS-Addressing-2003_03.xsd" -
the same relative path it told me when I used the ../..
form. Using just ../ to go up one level instead of two
didn't change the relative path JBoss was looking for.

I did not have a chance to debug this to find out how to
fix this - I just noticed that I was unable to get to
that .xsd file from my browser (so, therefore, I assume
any client of this web service will not be able to
successfully parse its WSDL due to the inability to have
the server serve up this schema).