Hi Jeff,
It is never one prob!:-) I would agree with you that Axis2 should
handle that, not geronimo. However, G2977 is still valid and solves
the prob when wsdlLocation is used and the user isn't using service-ref.
We are going through what's missing in web services and open JIRAs for
them today. Will make sure this prob is captured.
Thanks, Lin
Jeff Genender wrote:
Hi Lin,
The service-ref override is in the web.xml from the client side. The
service-ref can have a <port> <uri> tag that is supposed to override
what comes from the wsdl.
I was able to do the same as you, but when you have a client override,
thats when there are problems.
Thanks,
Jeff
Lin Sun wrote:
I too messed around a bit and submitted patch in G2977. I didn't quite
get your note about serviceRef overrides tho (assuming your serviceRef
means WebserviceRef). My understanding is that WebserviceRef is for
clients, we are trying to address a server side issue where a .wsdl file
is provided but there is no reference to the .wsdl file in
webservices.xml. Instead, the location of the wsdl file is specified
in the WebService or WebServiceProvider annotation. I was able to test
this by adding the wsdlLocation below to GreeterImpl.java:
@WebService(serviceName = "SOAPService",
portName = "SoapPort",
wsdlLocation = "WEB-INF/wsdl/greeter_control.wsdl",
endpointInterface = "org.apache.greeter_control.Greeter",
targetNamespace = "http://apache.org/greeter_control";)
and making sure that wsdl-file is not set in webservices.xml in
jaxws-war project.
Lin
Jeff Genender wrote:
I did some messing around with this, and it will definitely be a much
bigger job. I allowed it to find the wsdl by setting the location.
This worked, but unfortunately it sent the WSDL verbatim without doing
the specific ServiceRef overrides. So this is deeper in the Axis2
container I believe.
Jeff
Lin Sun wrote:
Hi, thanks everyone for their input! I really like this list - it is
very friendly! :-)
Jeff, I'd be happy to do it... a bit booked today but I should be able
to come up with a patch soon to handle the 2nd case where wsdlLocation
is specified in webservice annotation.
As for the first case (when wsdl file doesn't exist), my understanding
is that Axis2 doesn't have such a tool with JAX-WS features. This is a
big feature, not just a bug.:-( The Java2WSDL tool is the only tool
that I am aware of in Axis2 and it doesn't do annotation. That's the
only reason why I propose to use the wsgen tool provided by sun.
Lin
Jeff Genender wrote:
Yup...filling in the PortInfo map with some of the WebService
annotation
info (minimally the wsdl location) should get us past this issue.
If Lin doesn't do it I may give it a SWAG this morning.
Jeff
Jarek Gawor wrote:
If Axis2 has a tool to generate WSDL from Java code (with annotations)
then we should definitely used that. Hopefully, it also has good
programmatic API so that we can call it at runtime (or at deployment
time) and generate the WSDL dynamically to a file or a byte array or
whatever. In G we would just check if the @WebService annotation has
wsdlLocation attribute set (there is a bit of logic to that) and call
that tool only if it is not. I don't think we should do anything more
then that in G. That is, I don't think we should write any code in G
to generate WSDL from Java code.
Jarek
On 3/15/07, Lasantha Ranaweera <[EMAIL PROTECTED]> wrote:
Hi Lin,
I checked your email in the Axis2 dev list and I am also not sure
whether this is a bug or a missing feature in the Axis2 (since I
didn't
go through the problem deep). If this is a bug we might able to help
Axis2 source code too (as I did couple of times with my patches)
;-) .
Make sure to cross link issues in JIRA in such situation.
Otherwise as
Jeff mentioned we might need to implement in the G side if the Axis2
doesn't have any plans of support the feature soon.
Regarding your last part of reading annotations have a look at
JAXWSUtils.java file comes in a org.apache.geronimo.jaxws package, I
think it has a way of reading such annotations (line 86).
Thanks,
Lasantha
Lin Sun wrote:
Hi Jeff,
Yes I totally agree that the tool needs to be for axis2 only and
handled during deployment time! Basically, during deployment of the
module, we'll invoke the tool on the fly and generate the .wsdl file
for the user, and set the PortInfo's wsdlLocation property. Then
the
code will be executed as if the .wsdl is provided by the user, which
we know works right now. I was just trying to run the tool
stand-alone first to make sure it is good for our need.:-) I'll
investigate if there is any license issue.
Also, this doesn't cover the second scenario, when .wsdl file is
provided but the location of the .wsdl file is specified in
annotation but not in webservices.xml. In this case, we 'll
need to
figure out the location of the .wsdl file from annotation (not sure
how to do that yet) and set the PortInfo's wsdlLocation property.
Thanks,
Lin
Jeff Genender wrote:
I think this is supposed to happen on deployment, not from a
tool. If
Axis is not going to handle this, then this code will need to be
written
in the Axis2 deployer for Geronimo. Currently CXF does handle
Webservice annotations, so this type of deployment code would be an
Axis2 only necessity. I think the PortInfo objects will need to be
filled out before handing off to Axis2.
Jeff
Lin Sun wrote:
Hi Jeff/Lasantha,
I just posted this prob on axis2-dev list [1]. Currently the
Java2WSDL
tool which is what is being used to generate the targetnamespace
doesn't
seem to handle any of the annotation stuff... not sure if it will
ever
handle.:-(
An alternative is to use the sun's wsgen tool provided by
jaxws-tools.jar to generate the wsdl file from Java in the
geronimo
integration code. I tried to use the tool and it did generate the
targetnamespace correctly.
[1]:
http://marc.theaimsgroup.com/?l=axis-dev&m=117397929613538&w=2
Lin
Jeff Genender wrote:
Lasantha Ranaweera wrote:
Not exactly sure whether I am getting your problem exactly or
not
:-( .
Line 99 decides whether application archive contains WSDL file
or not
(according to Axis2 builder). If it is there we are going to
fill
WSDL
information from G side. Otherwise it will be handed over to
Axis2
side
(services with annotations). So looking at your problem
regarding
annotations what I say is it should be handled by Axis2 (all the
validation & execution stuff). The annotation processing will be
handled
as a web service receives SOAP requests. Starting point for
JAXWS
based
SOAP messages is receive() method of JAXWSMessageReciever.
The problem is, Axis2 is generating a wsdl upon the client
request
for a
wsdl, and not looking at the WebService annotation to get the
wsdl's
location. The code step through below shows the problem clearly.
HTH.
Lasantha
Jeff Genender wrote:
o.a.g.Axis2WebserviceContainer, line 99. A not-filled in
PortInfo is
passed in since G is not processing a WebService annotation,
and
thus an
AxisService.create is called on line 104.
When Axis2WebserviceContainer.getWsdl() is ultimately called,
doService2() is called (line 212), then to processGetRequest
(line
398),
leading us to line 435 where the PortInfo is checked as to
whether a
wsdl file has been passed in or not. If it has, it spits
out the
wsdl.
If it has not, then the AxisService.printWsdl() is called and
that
call
spits out a generated wsdl.
The crux here is that the PortInfo object does not have all of
the info
filled in such as seiClass, wsdl file, etc. That stuff would
have been
gotten from examining the WebService annotation.
The question is, where does that examination or, should that
examination, take place? Geronimo or Axis2?
Jeff
Lasantha Ranaweera wrote:
Jeff,
Sorry for a late reply due to my time stamp difference and
don't
know
exactly you have solved this problem right now or not. Anyway
here
is my
comment.
Since you haven't given me exact source code I won't be
able to
point
you in to the exact source code in the Axis2. May be remote
debugging
... ;-) .
Thanks,
Lasantha
Jeff Genender wrote:
Ok...
I am pretty certain at this stage that the WebService
annotation
is not
getting processed. Can you point me to the code that handles
this in
Axis2?
Thanks,
Jeff
Jeff Genender wrote:
Thanks...this is very helpful.
Then by this, looking at the PortInfo, it appears as though
it is
not
stuffing in the WSDL file, which tells me it's a G thang ;-)
Jeff
Lasantha Ranaweera wrote:
Hi Jeff,
To my understanding if we have given a WSDL in an
archive it
should get
the priority than the information in the annotations.
In Axis2 integration there are two parts of implementation
with
one for
with WSDL which is mainly handling by G side while with
annotations
from
Axis2. For me it is something missing in G side.
Somebody in the list please correct me if I am wrong
here .
Thanks,
Lasantha
Jeff Genender wrote:
Hi,
I have noticed when I deploy a war file (with a WSDL), I
have a
certain
target name specified both in the WSDL and in the code
that
uses a
WebService annotation.
However, when I go retrieve the WSDL, I notice the target
name
seems to
be munged according to the package name (backwards) of the
code
that
contains the WebService annotation.
Example...
I have include a WSDL called Hello.wsdl that is in the war
file
in the
web-inf/wsdl directory and starts with:
<wsdl:definitions
targetNamespace="http://example.com/hello/xsd";>
...
I have a HelloWorld.java that has this:
package test.mypackage;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name="HelloWorld", targetNamespace =
"http://example.org/hello/xsd";)
public class HelloWorld {
@WebMethod
public String sayHello(String me){
return "Hello "+me;
}
}
However, when I request the wsdl...I get something like
this:
<wsdl:definitions
targetNamespace="http://mypackage.test/xsd";>
...
Notice the targetnamespace was munged and changed from
it's
originally
declared namespace of "http://example.com/hello/xsd";. I
want the
one
that is both declared in the included wsdl (or the one
declared
in the
annotation).
Is this a facet of Axis2 or is Geronimo not passing a
proper
PortInfo
object with the necessary stuff filled in?
Any light on this subject would be greatly appreciated ;-)
Thanks,
Jeff
