java2wsdl and optional (nillable) method arguments
Using Axis 1.4 here... I'd like my WSDL (generated with Java2WSDL) to represent some of the arguments to some of my methods as optional (nillable). Is this possible, or is this only something one can do by going the other direction--WSDL-to-Java? -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best way to log service method accesses?
I'm setting up a table in my database to log accesses to my service. I'm grabbing the username, client host and script name from the SOAP header, but I'd also like to log the name of the method called. What's the best way to do this? Can the SOAPAction HTTP header be reliably counted on for this task, or must I pick apart the SOAP body? Or better yet, is there a pre-fabricated solution I could drop into my service to take care of this for me? Surely this has been done before. :-) -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best way to log service method accesses?
On 12/5/06, David Illsley [EMAIL PROTECTED] wrote: If this is in Axis2 I'd suggest a handler inserted after the dispatch phase in which case you can get the operation name from the AxisOperation which in turn you can obtain from the MessageContext. In general the SOAPAction can't and shouldn't be relied upon. Sorry, should have mentioned in my original e-mail that this is under Axis 1.4. Is there a sexy way to do what I need in that version of Axis? -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best way to log service method accesses?
Ne'er mind...I got this figured out based upon a response to another question. The solution is to create a handler that inherits from BasicHandler. :-) -dan On 12/5/06, D. Kreft [EMAIL PROTECTED] wrote: On 12/5/06, David Illsley [EMAIL PROTECTED] wrote: If this is in Axis2 I'd suggest a handler inserted after the dispatch phase in which case you can get the operation name from the AxisOperation which in turn you can obtain from the MessageContext. In general the SOAPAction can't and shouldn't be relied upon. Sorry, should have mentioned in my original e-mail that this is under Axis 1.4. Is there a sexy way to do what I need in that version of Axis? -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Header info in Axis 1.x
Is it possible to retrieve header SOAP header information under Axis1? There's only one e-mail in the archives that seems appropriate, but it was never answered (http://marc.theaimsgroup.com/?l=axis-userm=116072386027359w=2). I know this can be done under Axis2, but I'm not in a position at present to make that switch. Pointers to example source code or existing documentation would be much appreciated. Another question I should probably ask, just as a sanity-checking measure, is whether it's appropriate to do what I'm thinking about doing. My primary web service needs to talk to one or more helper web services, and from time to time it might be useful or even necessary to force my primary service to consult a non-default helper service when debugging problems or testing new features. My thought was to pass along an override URL for the helper service in the SOAP header. Does this make sense? It sure seems better than adding additional override arguments to all of my service methods! -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoking java classes with a Perl client
On 10/24/06, Anne Thomas Manes [EMAIL PROTECTED] wrote: We need the WSDL to help you. Thanks, Anne. Please find he WSDL attached. -dan ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://pkgbuild.company.com/PBQS; xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:apachesoap=http://xml.apache.org/xml-soap; xmlns:impl=http://pkgbuild.company.com/PBQS; xmlns:intf=http://pkgbuild.company.com/PBQS; xmlns:tns2=http://request.packagebuilder.company.com; xmlns:tns3=http://event.packagebuilder.company.com; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; !--WSDL created by Apache Axis version: 1.3 Built on Oct 05, 2005 (05:23:37 EDT)-- wsdl:types schema elementFormDefault=qualified targetNamespace=http://pkgbuild.company.com/PBQS; xmlns=http://www.w3.org/2001/XMLSchema; import namespace=http://event.packagebuilder.company.com/ import namespace=http://request.packagebuilder.company.com/ import namespace=http://xml.apache.org/xml-soap/ element name=testTakeHash complexType sequence element name=map type=apachesoap:Map/ /sequence /complexType /element element name=testTakeHashResponse complexType sequence element name=testTakeHashReturn type=xsd:string/ /sequence /complexType /element element name=testTakeRequest complexType sequence element name=request type=tns2:RequestImpl/ /sequence /complexType /element complexType name=ArrayOf_tns3_RequestEvent sequence element maxOccurs=unbounded minOccurs=0 name=item type=tns3:RequestEvent/ /sequence /complexType element name=testTakeRequestResponse complexType sequence element name=testTakeRequestReturn type=xsd:string/ /sequence /complexType /element element name=addEventToRequest complexType sequence element name=requestID type=xsd:long/ element name=username type=xsd:string/ element name=message type=xsd:string/ /sequence /complexType /element element name=addEventToRequestResponse complexType sequence element name=addEventToRequestReturn type=xsd:long/ /sequence /complexType /element element name=createNewRequest complexType sequence element name=versionSetName type=xsd:string/ element name=priority type=xsd:int/ element name=createdBy type=xsd:string/ /sequence /complexType /element element name=createNewRequestResponse complexType sequence element name=createNewRequestReturn type=xsd:long/ /sequence /complexType /element element name=createNewRequest2 complexType sequence element name=requestArgs type=apachesoap:Map/ /sequence /complexType /element element name=createNewRequest2Response complexType sequence element name=createNewRequest2Return type=xsd:long/ /sequence /complexType /element element name=createNewRequestWithLegacyID complexType sequence element name=legacyRequestID type=xsd:string/ element name=versionSetName type=xsd:string/ element name=priority type=xsd:int/ element name=createdBy type=xsd:string/ /sequence /complexType /element element name=createNewRequestWithLegacyIDResponse complexType sequence element name=createNewRequestWithLegacyIDReturn type=xsd:long/ /sequence /complexType /element element name=getAllRequests complexType/ /element element
Invoking java classes with a Perl client
I'm stuck and endless googling is leading me to no success.
I'm trying to use Perl's SOAP::Lite to talk to an Axis web service.
I've got a new method that I want to add to my service implementation
that accepts an object as its sole argument, and what I need to do is
instantiate that object on the client, but I can't figure out how to
make it all happen.
Here's the relevant service method:
public void testTakeRequest(Request request) {
System.out.println(Request: + request);
}
And the snippet from the deploy.wsdd:
beanMapping qname=pbqs:Request
xmlns:pbqs=urn:Request
languageSpecificType=java:com.company.packagebuilder.request.Request
/
Here's the entirety of the Perl client:
use strict;
use warnings;
use Data::Dumper qw(Dumper);
use SOAP::Lite (dispatch_from = 'Request',
uri = 'urn:Request',
proxy = $ENV{'PBQS_PROXY_URL'},
trace = 'debug');
my $r = Request-new();
$r-isApproved(1);
print Dumper($r);
But the problem is that I'm getting No such operation 'new' errors.
I can't figure out if I've got problems
with my namespace or what.
Here's how my request gets serialized:
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 436
Content-Type: text/xml; charset=utf-8
SOAPAction: http://packagebuild.company.com/Request#new;
?xml version=1.0 encoding=UTF-8?soap:Envelope
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodynew
xmlns=http://packagebuild.company.com/Request; xsi:nil=true
//soap:Body/soap:Envelope
I'm not sure if including the full body of my Axis-generated WSDL is
going to help, so I'll refrain from
posting that here until/unless someone asks for it.
BTW, if you're wondering why I don't e-mail the SOAP::Lite developer's
list, it's because that list appears to be pretty
much dead for all intents and purposes, so I'm hoping that one of you
might have a clue what I'm doing wrong
(other than using Perl--can't do anything about that given the huge
mass of legacy code with which I'm trying
to integrate).
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation for Java2WSDLTask
It's kinda hard to read--your Content-type header is coming across as text/plain even though it's an .html document. -dan On 10/12/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: There is a ongoing doc effort for these things... Just see whether it matches your expectations... Feedback is welcome :) http://svn.apache.org/repos/asf/webservices/axis2/branches/java/1_1/xdocs/1_1/reference.html Thnaks, ~Thilina On 10/13/06, Davanum Srinivas [EMAIL PROTECTED] wrote: classpathURI - That's the one that needs fixin'. there's a pending patch as well that changes several of the options. So hang in there. -- dims On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: On 10/12/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Troublemakers! :) Started a JIRA bug. The options for the ant task is almost one to one with the command line. Ooookay... So, I tried using the Ant task based upon an example that someone had pasted in response to a similar question to this list, but the part that is baffling me is that it can't find my class (I knowNewbie classpath issues! Throw him to the sharks!). Unfortunately, Java2WSDLTask does not support a nested classpath element like many other Ant tasks seem to do (hint hint), instead there seems to be this 'classpathURI' attribute. What is *that*? Is it a classpath or a URI? -dan http://issues.apache.org/jira/browse/AXIS2-1360 -- dims On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: I should clarify thisI'm trying to use the Ant task, not the command line. -dan On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: Is there any documentation yet on how to use Java2WSDLTask? There are a bunch of new attributes to this task that I'm not familiar with. The javadocs for the class of the same name are, of course, no help--they assume I know what I'm doing. :-) -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Documentation for Java2WSDLTask
Is there any documentation yet on how to use Java2WSDLTask? There are a bunch of new attributes to this task that I'm not familiar with. The javadocs for the class of the same name are, of course, no help--they assume I know what I'm doing. :-) -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation for Java2WSDLTask
I should clarify thisI'm trying to use the Ant task, not the command line. -dan On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: Is there any documentation yet on how to use Java2WSDLTask? There are a bunch of new attributes to this task that I'm not familiar with. The javadocs for the class of the same name are, of course, no help--they assume I know what I'm doing. :-) -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation for Java2WSDLTask
On 10/12/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Troublemakers! :) Started a JIRA bug. The options for the ant task is almost one to one with the command line. Ooookay... So, I tried using the Ant task based upon an example that someone had pasted in response to a similar question to this list, but the part that is baffling me is that it can't find my class (I knowNewbie classpath issues! Throw him to the sharks!). Unfortunately, Java2WSDLTask does not support a nested classpath element like many other Ant tasks seem to do (hint hint), instead there seems to be this 'classpathURI' attribute. What is *that*? Is it a classpath or a URI? -dan http://issues.apache.org/jira/browse/AXIS2-1360 -- dims On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: I should clarify thisI'm trying to use the Ant task, not the command line. -dan On 10/12/06, D. Kreft [EMAIL PROTECTED] wrote: Is there any documentation yet on how to use Java2WSDLTask? There are a bunch of new attributes to this task that I'm not familiar with. The javadocs for the class of the same name are, of course, no help--they assume I know what I'm doing. :-) -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for polymorphism in a service
I'm writing a service that I'm trying to integrate into a legacy
system bit by bit. In the old system, a request ID is a String of
the format rqMMDDHHMMSSXXX, but in the new system, a request ID
is simply a row identifier (a Long).
What I'd like to do is use the power of polymorphism to keep my
service API clean and sane:
public Request getRequestByID(String legacyRequestID) {
// ...
}
public Request getRequestByID(Long requestID) {
// ...
}
But when I try this, java2wsdl (Axis1) pukes with the following fault:
Attempted to write duplicate schema element :
{http://pkgbuild.amazon.com/PBQS}getRequestByID
...which makes me sad. :-( -- See?
Is this a WSDL 1.0 restriction or a deficiency in java2wsdl? Will such
use of polymorphism be possible under Axis2?
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for polymorphism in a service
But wasn't the notion of portType supposed to be nixed in WSDL 1.1?
-dan
On 10/11/06, Davanum Srinivas [EMAIL PROTECTED] wrote:
Please see:
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Distinctive_Operations
thanks,
-- dims
On 10/11/06, D. Kreft [EMAIL PROTECTED] wrote:
I'm writing a service that I'm trying to integrate into a legacy
system bit by bit. In the old system, a request ID is a String of
the format rqMMDDHHMMSSXXX, but in the new system, a request ID
is simply a row identifier (a Long).
What I'd like to do is use the power of polymorphism to keep my
service API clean and sane:
public Request getRequestByID(String legacyRequestID) {
// ...
}
public Request getRequestByID(Long requestID) {
// ...
}
But when I try this, java2wsdl (Axis1) pukes with the following fault:
Attempted to write duplicate schema element :
{http://pkgbuild.amazon.com/PBQS}getRequestByID
...which makes me sad. :-( -- See?
Is this a WSDL 1.0 restriction or a deficiency in java2wsdl? Will such
use of polymorphism be possible under Axis2?
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for polymorphism in a service
On 10/11/06, Spies, Brennan [EMAIL PROTECTED] wrote:
No, that's WSDL 2.0, where it is replaced by Interface...
www.w3.org/2002/ws/desc/wsdl20-primer
Sorry, yes...that's what Sanjiva was talking about. :-)
I'm hoping that a O(1) question will save me an O(n) scouring of that
document...does WSDL 2.0 support operator overloading?
-dan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D.Kreft
Sent: Wednesday, October 11, 2006 1:40 PM
To: axis-user@ws.apache.org; [EMAIL PROTECTED]
Subject: Re: Support for polymorphism in a service
But wasn't the notion of portType supposed to be nixed in WSDL 1.1?
-dan
On 10/11/06, Davanum Srinivas [EMAIL PROTECTED] wrote:
Please see:
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Distinctive_Ope
rations
thanks,
-- dims
On 10/11/06, D. Kreft [EMAIL PROTECTED] wrote:
I'm writing a service that I'm trying to integrate into a legacy
system bit by bit. In the old system, a request ID is a String of
the format rqMMDDHHMMSSXXX, but in the new system, a request ID
is simply a row identifier (a Long).
What I'd like to do is use the power of polymorphism to keep my
service API clean and sane:
public Request getRequestByID(String legacyRequestID) {
// ...
}
public Request getRequestByID(Long requestID) {
// ...
}
But when I try this, java2wsdl (Axis1) pukes with the following fault:
Attempted to write duplicate schema element :
{http://pkgbuild.amazon.com/PBQS}getRequestByID
...which makes me sad. :-( -- See?
Is this a WSDL 1.0 restriction or a deficiency in java2wsdl? Will such
use of polymorphism be possible under Axis2?
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Axis2: simple service fails to work
I'm trying to whip-up a bare-bones service that will demonstrate
Axis2's inability to cope with complex data types returned by service
methods using RPCMessageReceiver and now I can't even get *that* to
work (what a way to start off the week). Here's the service
implementation:
public class TestService {
public String[] getArrayOfStrings() {
return new String[] {Hello, World};
}
public int getInt() {
return 1;
}
public Object getObject() {
return new Object();
}
public String getString() {
return Hello World;
}
}
And here's the services.xml:
?xml version=1.0 encoding=ISO-8859-1?
service name=test
parameter name=ServiceClass locked=false
TestService
/parameter
operation name=getArrayOfStrings
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getInt
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getObject
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getString
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
/service
And the listing of my .aar file:
% jar -tf test.aar
META-INF/
META-INF/MANIFEST.MF
META-INF/services.xml
src/
src/TestService.java
TestService.class
I started Tomcat (and thus Axis2) from scratch, with only the default
'version' service and then used the web admin CGI to upload the
service. Immediately, I saw the following in the catalina.out:
- Error in schema generating null
java.lang.NullPointerException
at
org.apache.ws.java2wsdl.Java2WSDLUtils.namespaceFromClassName(Java2WSDLUtils.java:51)
at
org.apache.ws.java2wsdl.Java2WSDLUtils.schemaNamespaceFromClassName(Java2WSDLUtils.java:77)
at
org.apache.ws.java2wsdl.SchemaGenerator.init(SchemaGenerator.java:77)
at org.apache.axis2.deployment.util.Utils.fillAxisService(Utils.java:209)
at
org.apache.axis2.deployment.ServiceBuilder.populateService(ServiceBuilder.java:149)
at
org.apache.axis2.deployment.repository.util.ArchiveReader.buildServiceGroup(ArchiveReader.java:76)
at
org.apache.axis2.deployment.repository.util.ArchiveReader.processServiceGroup(ArchiveReader.java:118)
at
org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.java:620)
at
org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList.java:195)
at
org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener.java:207)
at
org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryListener.java:155)
at
org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryListener.java:199)
at
org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepositary(SchedulerTask.java:61)
at
org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.java:68)
at
org.apache.axis2.deployment.scheduler.Scheduler$SchedulerTimerTask.run(Scheduler.java:76)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
But yet Axis2 is still able to generate a WSDL (which I won't bother to paste).
Calling http://localhost:7070/axis2/services/test/getInt results in a
resource not found error, with no accompanying stack trace or error
messaging in my catalina.out.
When I try to call getInt() (or any other method, for that matter) via
a Perl SOAP client, I get the exception pasted below. Can anyone see
what it is that I'm doing wrong?
-dan
org.apache.axis2.AxisFault: null; nested exception is:
java.lang.NullPointerException
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:136)
at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:37)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
Re: Axis2: simple service fails to work
On 9/25/06, robert lazarski [EMAIL PROTECTED] wrote: What does http://localhost:7070/axis2/ show ? The standard Axis2 Welcome page. Did you mean what does /axis2/services/listServices show? I've pasted the contents of that page below. Interesting thing to note...the url is busted when I click on the name of the service. Instead of /axis2/services/serviceName?wsdl, the links point to /axis2/null/serviceName?wsdlthis happens for all services listed. -dan BEGIN /axis2/services/listServices OUTPUT Available services test Service EPR : http://dkreft-2.desktop.company.com:7070/axis2/null/test Service REST epr : http://dkreft-2.desktop.company.com:7070/axis2/rest/test Service Description : test Service Status : Active Available operations * getObject * getString * getArrayOfStrings * getInt version Service EPR : http://dkreft-2.desktop.company.com:7070/axis2/null/version Service REST epr : http://dkreft-2.desktop.company.com:7070/axis2/rest/version Service Description : This service is to get the running Axis version Service Status : Active Available operations * getVersion END /axis2/services/listServices OUTPUT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2: simple service fails to work
I changed the package to 'test', and still I get no respect.
-dan
On 9/25/06, Bhatra, Junaid [EMAIL PROTECTED] wrote:
It looks like your TestService class is in the default package. Try
putting it in some package and see what happens? Don't forget to change
the ServiceClass parameter to reflect the package name as well.
- Junaid
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D.Kreft
Sent: Monday, September 25, 2006 2:18 PM
To: Axis Users
Subject: Axis2: simple service fails to work
I'm trying to whip-up a bare-bones service that will demonstrate
Axis2's inability to cope with complex data types returned by service
methods using RPCMessageReceiver and now I can't even get *that* to
work (what a way to start off the week). Here's the service
implementation:
public class TestService {
public String[] getArrayOfStrings() {
return new String[] {Hello, World};
}
public int getInt() {
return 1;
}
public Object getObject() {
return new Object();
}
public String getString() {
return Hello World;
}
}
And here's the services.xml:
?xml version=1.0 encoding=ISO-8859-1?
service name=test
parameter name=ServiceClass locked=false
TestService
/parameter
operation name=getArrayOfStrings
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getInt
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getObject
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getString
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
/service
And the listing of my .aar file:
% jar -tf test.aar
META-INF/
META-INF/MANIFEST.MF
META-INF/services.xml
src/
src/TestService.java
TestService.class
I started Tomcat (and thus Axis2) from scratch, with only the default
'version' service and then used the web admin CGI to upload the
service. Immediately, I saw the following in the catalina.out:
- Error in schema generating null
java.lang.NullPointerException
at
org.apache.ws.java2wsdl.Java2WSDLUtils.namespaceFromClassName(Java2WSDLU
tils.java:51)
at
org.apache.ws.java2wsdl.Java2WSDLUtils.schemaNamespaceFromClassName(Java
2WSDLUtils.java:77)
at
org.apache.ws.java2wsdl.SchemaGenerator.init(SchemaGenerator.java:77)
at
org.apache.axis2.deployment.util.Utils.fillAxisService(Utils.java:209)
at
org.apache.axis2.deployment.ServiceBuilder.populateService(ServiceBuilde
r.java:149)
at
org.apache.axis2.deployment.repository.util.ArchiveReader.buildServiceGr
oup(ArchiveReader.java:76)
at
org.apache.axis2.deployment.repository.util.ArchiveReader.processService
Group(ArchiveReader.java:118)
at
org.apache.axis2.deployment.DeploymentEngine.doDeploy(DeploymentEngine.j
ava:620)
at
org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoList
.java:195)
at
org.apache.axis2.deployment.RepositoryListener.update(RepositoryListener
.java:207)
at
org.apache.axis2.deployment.RepositoryListener.checkServices(RepositoryL
istener.java:155)
at
org.apache.axis2.deployment.RepositoryListener.startListener(RepositoryL
istener.java:199)
at
org.apache.axis2.deployment.scheduler.SchedulerTask.checkRepositary(Sche
dulerTask.java:61)
at
org.apache.axis2.deployment.scheduler.SchedulerTask.run(SchedulerTask.ja
va:68)
at
org.apache.axis2.deployment.scheduler.Scheduler$SchedulerTimerTask.run(S
cheduler.java:76)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
But yet Axis2 is still able to generate a WSDL (which I won't bother to
paste).
Calling http://localhost:7070/axis2/services/test/getInt results in a
resource not found error, with no accompanying stack trace or error
messaging in my catalina.out.
When I try to call getInt() (or any other method, for that matter) via
a Perl SOAP client, I get the exception pasted below. Can anyone see
what it is that I'm doing wrong?
-dan
org.apache.axis2.AxisFault: null; nested exception is:
java.lang.NullPointerException
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RP
CMessageReceiver.java:136)
at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(Abst
ractInOutSyncMessageReceiver.java:37)
at
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReques
t(HTTPTransportUtils.java:284)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at
Re: Axis2: simple service fails to work
On 9/25/06, Davanum Srinivas [EMAIL PROTECTED] wrote: JIRA Please. Can i assume you are trying the nightly? No, I'm not using the nightly. I'm using the last good release--1.0 because I'm trying to develop a *production* application for my employer, and the thought of having core business functionality running on a nightly release of third-party software quite frankly is not a sane development practice--there is too much money on the line here. I think at this point, I'm going to have to complete give up on using Axis2. I and another developer I work with have had a number of difficulties with Axis 1.4, none of which I'll bother to go into here, but suffice to say that when we saw that Axis2 had finally reached version 1.0 (out of Beta we thought), we were optimistic that the revised Axis would obviate the need for some of the hacks we have in place to overcome some of Axis's quirks. So I got my manager's blessing to see what it takes to take the humble beginnings of my new service (already mostly functional in Axis 1.4) and make it work in Axis2. I was hoping it'd be a fairly straightforward deal, but after working on it for five solid days, I have nothing more to show for my hard work than a handful e-mails to this list, three subsequent requests for me to file JIRAs, and a crippled service. Did I misinterpret the major-number version bump? Is Axis2 really not out of Beta yet? Because if it *is* supposed to be out of Beta at this stage, then I cannot help but be profoundly disappointedthe documentation is very sparse, often times irrelevant, sometimes contradictory, counter-intuitive, and not terribly clear when it can be found (I actually found more information in artciles *about* Axis2 than I did from the actual Axis2 website). If it's still considered Beta then that needs to be *clearly* and prominently documented on the Axis2 website. But documentation woes aside, what really disappoints me is that it doesn't look as if anyone tested the seemingly simple case where the developer writes a service implementation class, let Axis2 divine its own WSDL from it, and have at least one of the methods return a simple object. Axis2 seems to have no problems returning simple data types (ints, Strings, primitive arrays of strings, etc.), but as soon as an object is returned, all Hades breaks loose. And now, writing a brain-dead simple service fails and I have to file a bug report for that! So now I've lost a full week of productivity (and a few handfuls of hair)...all because I naively thought that version 1.0 meant Okay, we're ready for the real world. It obviously isn't, and I can't help but think that someone got a little trigger-happy in promoting Axis2 to version 1.0. In my humble estimation, it could have used a bit more time baking in Beta (i.e. with a 0.x version number). If I had any idea that Axis was still so raw, I wouldn't have wasted a 40-hour work week on trying to get it to work...or the couple of hours I've spent this morning trying to come up with a simple example of Axis2 puking when an object is returned from a service method. I don't doubt that the Axis2 developers are working very hard to get all these issues resolved, but for goodness sake...you can't release a product as version 1.0--which implies a non-Beta, stable release--when the new product lacks much of the basic functionality that people are going to need and that they are used to having provided for them by the previous release (Axis 1.x). -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2: simple service fails to work
On 9/25/06, Spies, Brennan [EMAIL PROTECTED] wrote: What Dims and Robert forgot to mention is that Axis 2.0 is really a major rewrite of the SOAP stack (hence the split of URLs, one for Axis 1 and one for Axis 2). So the same growing pains apply here as with any new project. Not that I don't feel your pain--I have been there many times before, trust me--but I can also remember a time when free software was not in such abundance. Given the excellent price of the software, it may be worthwhile to stick it out with the nightlies until version 1.1 is released (which I believe is at the end of this month, more or less). The benefits you mention are not lost on me--the price is definitely right when taken at its face. However, the poor messaging regarding the stability/completeness of Axis2 1.0 has resulted in a net *loss* for my employer as I went down a week-long rabbit trail. I can handle incomplete/instable software--when I'm warned ahead of time that is what I'm using. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D.Kreft Sent: Monday, September 25, 2006 1:37 PM To: axis-user@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Axis2: simple service fails to work On 9/25/06, Davanum Srinivas [EMAIL PROTECTED] wrote: JIRA Please. Can i assume you are trying the nightly? No, I'm not using the nightly. I'm using the last good release--1.0 because I'm trying to develop a *production* application for my employer, and the thought of having core business functionality running on a nightly release of third-party software quite frankly is not a sane development practice--there is too much money on the line here. I think at this point, I'm going to have to complete give up on using Axis2. I and another developer I work with have had a number of difficulties with Axis 1.4, none of which I'll bother to go into here, but suffice to say that when we saw that Axis2 had finally reached version 1.0 (out of Beta we thought), we were optimistic that the revised Axis would obviate the need for some of the hacks we have in place to overcome some of Axis's quirks. So I got my manager's blessing to see what it takes to take the humble beginnings of my new service (already mostly functional in Axis 1.4) and make it work in Axis2. I was hoping it'd be a fairly straightforward deal, but after working on it for five solid days, I have nothing more to show for my hard work than a handful e-mails to this list, three subsequent requests for me to file JIRAs, and a crippled service. Did I misinterpret the major-number version bump? Is Axis2 really not out of Beta yet? Because if it *is* supposed to be out of Beta at this stage, then I cannot help but be profoundly disappointedthe documentation is very sparse, often times irrelevant, sometimes contradictory, counter-intuitive, and not terribly clear when it can be found (I actually found more information in artciles *about* Axis2 than I did from the actual Axis2 website). If it's still considered Beta then that needs to be *clearly* and prominently documented on the Axis2 website. But documentation woes aside, what really disappoints me is that it doesn't look as if anyone tested the seemingly simple case where the developer writes a service implementation class, let Axis2 divine its own WSDL from it, and have at least one of the methods return a simple object. Axis2 seems to have no problems returning simple data types (ints, Strings, primitive arrays of strings, etc.), but as soon as an object is returned, all Hades breaks loose. And now, writing a brain-dead simple service fails and I have to file a bug report for that! So now I've lost a full week of productivity (and a few handfuls of hair)...all because I naively thought that version 1.0 meant Okay, we're ready for the real world. It obviously isn't, and I can't help but think that someone got a little trigger-happy in promoting Axis2 to version 1.0. In my humble estimation, it could have used a bit more time baking in Beta (i.e. with a 0.x version number). If I had any idea that Axis was still so raw, I wouldn't have wasted a 40-hour work week on trying to get it to work...or the couple of hours I've spent this morning trying to come up with a simple example of Axis2 puking when an object is returned from a service method. I don't doubt that the Axis2 developers are working very hard to get all these issues resolved, but for goodness sake...you can't release a product as version 1.0--which implies a non-Beta, stable release--when the new product lacks much of the basic functionality that people are going to need and that they are used to having provided for them by the previous release (Axis 1.x). -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail:
Re: Axis2: simple service fails to work
On 9/25/06, Davanum Srinivas [EMAIL PROTECTED] wrote: FWIW, your test case works fine with latest nightly when accessing via http://localhost:7070/axis2/rest/test/getInt and using /services should give you a warning to enable REST. http://localhost:7070/axis2/services/test/getInt What I would really like to understand is, what is so out of the ordinary about my test case that it would have been missed during the course of unit/functional tests? I can see if I were trying to do something really complicated, but this is about as simple as it gets, no? Such oversights in a major release make me a bit nervous, if you know what I mean. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 creating empty wsdl:message element
Ne'er mind on this one. I believe this is a bug in the SOAP::Lite
module (document/literal support is experimental at this point)--I've
got a patch for that module that seems like it'll fix the problem.
-dan
On 9/22/06, D. Kreft [EMAIL PROTECTED] wrote:
I've got what looks like an aberration in my Axis2-generated WSDL
(from yesterday's nightly, though. I'm not exactly a WSDL guru or
anything, but the following line is causing my Perl client (a
hand-made SOAP::Lite client that works just peachy with the same
service running under Axis1.4) to barf:
wsdl:message name=getAllRequestsMessage/
wsdl:message name=getAllRequestsResponse
wsdl:part name=part1 element=ns1:getAllRequestsResponse/
/wsdl:message
Note how there's no wsdl:part for getAllRequestsMessage, unlike a
similar method in the same document:
!-- Generated by Axis2 1.0 --
wsdl:message name=getRequestsByPriorityMessage
wsdl:part name=part1 element=ns1:getRequestsByPriority/
/wsdl:message
wsdl:message name=getRequestsByPriorityResponse
wsdl:part name=part1 element=ns1:getRequestsByPriorityResponse/
/wsdl:message
I'm guessing that it's empty because this method takes no arguments
(see method definition below), and this
*might* be a deficiency with SOAP::Lite, however, the method
(getAllRequests()) is WSDLed by Axis1.4 like so:
!-- Generated by Axis 1.4 --
wsdl:message name=getAllRequestsRequest
wsdl:part element=impl:getAllRequests name=parameters/
/wsdl:message
wsdl:message name=getAllRequestsResponse
wsdl:part element=impl:getAllRequestsResponse name=parameters/
/wsdl:message
Here are the relevant lines from my services.xml:
operation name=getAllRequests
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
operation name=getRequestsByPriority
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
And the method definitions in my service implementation class. This
same class is used by
both Axis and Axis2
@SuppressWarnings(unchecked)
public T extends Request Request[] getAllRequests()
throws Exception
{
ListT allRequests = (ListT)_requestMethods.getAllRequests();
Request[] array = new Request[allRequests.size()];
allRequests.toArray(array);
return array;
}
@SuppressWarnings(unchecked)
public T extends Request Request[] getRequestsByPriority(int priority)
throws Exception
{
ListT allRequests =
(ListT)_requestMethods.getRequestsByPriority(priority);
Request[] array = new Request[allRequests.size()];
allRequests.toArray(array);
return array;
}
If you'd like to see the entire wsdl, let me know and I'll send it as
an attachment--I'm not sure
how much info would be needed to debug this and I didn't want to
overwhelm with a bunch
of noise.
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AxisFault: Reader cannot be null
I've Googled for this fault meessage as well as searched the
axis-user@ mailing list and couldn't find anything helpful.
I've got a test script that I wrote that can call methods on both my
Axis and Axis2 services (on the same host, FWIW). The Axis 1.x calls
always return results, but the Axis2 call barfs on me with the
exception cited at the bottom of this e-mail. Anyone have any ideas
what's going on here?
Here's the output from Axis 1.4:
$ ./scripts/service --method getRequestByID --id=2
Consulting Axis (1.x) Service...
$VAR1 = bless( {
'versionSetName' = 'PBTest/test-1',
'priority' = '2',
'isScrubbed' = 0,
'isApproved' = 1,
'addedOn' = '2006-09-05T22:50:05.000Z',
'timeConflict' = undef,
'isOptimized' = 0,
'createdBy' = 'dkreft',
'requestEvents' = {
'requestEvents' = bless( {
'requestEventID' = '1',
'addedOn' = '2006-09-22T21:57:12.000Z',
'username' = 'dkreft',
'message' = 'foobar'
}, 'RequestEvent' )
},
'cleanupOnFailure' = 0,
'lastModified' = '2006-09-05T22:50:06.000Z',
'rebuildDependingTargets' = 0,
'rebuildVersionSet' = 0,
'requestID' = '2'
}, 'Request' );
[I'm still trying to figure out why 'requestEvents' is coming out as
the wrong structure, but that's
a different issue.]
And here's what Axis2 does to me:
$ ./scripts/service --axis2 --method getRequestByID --id=2
Consulting Axis2 Service...
Reader cannot be null
$VAR1 = {
'Exception' = 'org.apache.axis2.AxisFault: Reader cannot be
null; nested exception is:
java.lang.UnsupportedOperationException: Reader cannot be null
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:136)
at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:37)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.UnsupportedOperationException: Reader cannot be null
at org.apache.axis2.util.StreamWrapper.init(StreamWrapper.java:39)
at
org.apache.axis2.rpc.receivers.RPCUtil.processResponse(RPCUtil.java:66)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:130)
... 21 more
'
};
Here's the relevant entry from my services.xml:
operation name=getRequestByID
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver /
/operation
Any help/clues would be sorely appreciated.
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxisFault: Reader cannot be null
Additional info... This only happens when calling methods that return complex data types (objects, arrays of objects). It works fine if the return type is something simple (integer, primitive array of strings): % ./scripts/service --method ping Consulting Axis (1.x) Service... $VAR1 = '1'; % ./scripts/service --method ping --axis2 Consulting Axis2 Service... $VAR1 = '1'; % ./scripts/service --method arrayPing Consulting Axis (1.x) Service... $VAR1 = 'Hello'; $VAR2 = 'World'; % ./scripts/service --method arrayPing --axis2 Consulting Axis2 Service... $VAR1 = 'Hello'; $VAR2 = 'World'; I'm getting the feeling I'm missing just some tiny bit of metadata foo... -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis2 is ignoring my WSDL
I'm a bit stumped here. I've been scouring documentation, articles, commentaries and the like for two days, so now I'm going to pester you fine folks. :-) I am generating a wsdl at build time and inserting into the WEB-INF directory in my .aar file like so: $ jar -tf services/pbqs.aar | grep wsdl META-INF/PBQS.wsdl (On a side-note, isn't there an 'axis2-java2wsdl' Ant target? I couldn't find one.) But when I issue the ?wsdl command against my service (running under Tomcat, in case it matters), the WSDL I get back is most definitely *not* the one I had generated. Any ideas on why this might be? This worked fine under Axis1.x, but I cannot for the life of me get it to work under Axis2. In case you're inclined to respond with Just use the automagically-generated WSDL, well, I'd rather not at this point. For reasons I'd rather not go into, having a WSDL that describes the service *as it was built* would be beneficial to me (and the developers at my company who may need to deploy an older version of the service for some reason). I'd also much prefer to *not* go from WSDL-Java--starting with Java and generating a WSDL is far less tedious. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: With a nightly or recent build try: parameter name=useOriginalwsdltrue/parameter Is this to go into the axis2.xml or the services.xml? I'm guessing the latter, but hoping to save myself some time (and more beating my head against the wall). Thanks. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
Wait a second... It seems *really* counter-intutive to have to supply a configuration setting to use a file that one intentionally puts in his .aar so that Axis can use it. It was my understanding after reading the documentation that a WSDL file in the META-INF directory was supposed to inhibit the dynamic generation of a WSDL. Would it not be more reasonable to use this as the default behavior and then provide an option to *ignore* the supplied WSDL for those special cases when one would want to do that? -dan On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: services.xml Robert On 9/21/06, D. Kreft [EMAIL PROTECTED] wrote: On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: With a nightly or recent build try: parameter name=useOriginalwsdltrue/parameter Is this to go into the axis2.xml or the services.xml? I'm guessing the latter, but hoping to save myself some time (and more beating my head against the wall). Thanks. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: With a nightly or recent build try: parameter name=useOriginalwsdltrue/parameter Okay, I tried this and I get no love from Axis2. I've got the WSDL in place: $ jar -tf services/pbqs.aar | grep wsdl META-INF/pbqs.wsdl And the parameter set: parameter name=useOriginalwsdltrue/parameter But I'm being told: Unable to generate WSDL for this service Either user has not dropped the wsdl into META-INF or operations use message receivers other than RPC. There is absolutely nothing printed to my catalina.out to indicate what the problem might be. FWIW, all of my messageReceivers are set to be org.apache.axis2.rpc.receivers.RPCMessageReceiver. Any guesses as to what's going on? In case it helps... $ md5sum axis2.war 32f4327ec0dbc733a007327deca40d64 axis2.war -dan Or wait for the upcomming release in about a week or so. HTH, Robert On 9/21/06, D. Kreft [EMAIL PROTECTED] wrote: I'm a bit stumped here. I've been scouring documentation, articles, commentaries and the like for two days, so now I'm going to pester you fine folks. :-) I am generating a wsdl at build time and inserting into the WEB-INF directory in my .aar file like so: $ jar -tf services/pbqs.aar | grep wsdl META-INF/PBQS.wsdl (On a side-note, isn't there an 'axis2-java2wsdl' Ant target? I couldn't find one.) But when I issue the ?wsdl command against my service (running under Tomcat, in case it matters), the WSDL I get back is most definitely *not* the one I had generated. Any ideas on why this might be? This worked fine under Axis1.x, but I cannot for the life of me get it to work under Axis2. In case you're inclined to respond with Just use the automagically-generated WSDL, well, I'd rather not at this point. For reasons I'd rather not go into, having a WSDL that describes the service *as it was built* would be beneficial to me (and the developers at my company who may need to deploy an older version of the service for some reason). I'd also much prefer to *not* go from WSDL-Java--starting with Java and generating a WSDL is far less tedious. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: If you are using RPCMessageReceiver it doesn't make sense to use your own WSDL . This is a FAQ: http://www.wso2.net/kb/104 Yeah, I saw that a couple of days ago. I think I actually read it more than once. The explanation of why I would *really* like to have a WSDL generated at build time is not something I really wanted to get into, so I'll try to keep this short and sweet. The presence of a WSDL at build time makes it much easier for builds of other packages (the smallest unit of software development at my company) to depend upon my service (at build time)--and it also makes it possible to determine if a particular build of my service has the contract that another developer is interested in. It is unacceptable in our environment to have to query a WSDL from a running service at build time--developers might not have network access, they might be trying to code to a built-but-not-yet-deployed WSDL, or any one of a number of different reasons. But philosophical arguments aside, I still don't understand why my wsdl would not be used if it is where the Axis2 docs say it should be. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: You can use your own wsdl provided you use any other message receiver except for RPC*. If you have a wsdl that you made yourself or got from somewhere, why not just use databinding via xmlbeans or adb ? I'm not familiar with either xmlbeans or ADB, but after a cursory examination it would appear that they do not offer Java-to-xsd,wsdl,whatever functionality--they seem to work the other way around. I'm a lot better at writing Java than I am at writing metadata object descriptors...so I'd like to save myself to tedium of having to write my own service descriptions at build time. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
The nightly build has a Java2WSDL.sh, which will get me there, I'm sure...but is there documentation on how to use it (i.e. the arguments it takes)? There's no javadoc in the nightly docs snapshot for org.apache.ws.java2wsdl.Java2WSDL. Or am I relegated to source diving? -dan On 9/21/06, D. Kreft [EMAIL PROTECTED] wrote: On 9/21/06, robert lazarski [EMAIL PROTECTED] wrote: You can use your own wsdl provided you use any other message receiver except for RPC*. If you have a wsdl that you made yourself or got from somewhere, why not just use databinding via xmlbeans or adb ? I'm not familiar with either xmlbeans or ADB, but after a cursory examination it would appear that they do not offer Java-to-xsd,wsdl,whatever functionality--they seem to work the other way around. I'm a lot better at writing Java than I am at writing metadata object descriptors...so I'd like to save myself to tedium of having to write my own service descriptions at build time. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, Martin Gainty [EMAIL PROTECTED] wrote: What I found is.. if you use any style other than RPC the wsdl's wont be created under AXIS2 ...which I maintain is an unnecessary feature. One should be able to specify his own WSDL regardless of what the messageReceiver is set to be for that service *and* be able to drop it in the appropriate place. Altering the behavior of the WSDL generation based upon the seemingly decision that RPC* methods cannot use a pre-generated WSDL does nothing more than apply arbitrary rules of engagement and remove power from the developer. No software developer can possibly anticipate all the crazy ways that other developers will want to use his products or services, so it's not a good idea for him to pretend like he knows exactly how everyone is going to use them. Software should have sensible, intuitive default behavior and allow for developers to deviate from the norm (whatever that is) by flipping a few bits. One should not have to flip bits to achieve sensible behavior. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 is ignoring my WSDL
On 9/21/06, Martin Gainty [EMAIL PROTECTED] wrote: But..If the wsdl you provide (either its content or style) is hosed there is no way for the program to correct it However.. If the program is *somehow* able to intuit from the services operations/methods and parameter(s) what the generated operation and the resulting request and response parameters should be *then* that feature should definitely be supported If I understand you correctly, you're saying that if you have a bad .wsdl (whatever that might mean) in your .aar, then Axis should ignore it and generate its own if it can before it pukes. I can't see that being a good thing in my situation. If I have a .wsdl in my .aar that I put there at build time, it means that anyone who has a copy of my .aar has my wsdl and they are going to be coding against it--at least they'd better if they hope to talk to my service and get meaningful results! Now, if you implement this automagical fall-back (which is what you're proposing), then the contract that I have built into my deployed package--the one I'm telling people they *need* to code against--is not going to match what happens in production. So, when a developer codes against a broken built WSDL, he's going to be in for a very rude awakening when he finally deploys his client(s)--the contract that I advertised does not reflect reality. At best, it'll just plain bork...but at worst, it may introduce a very subtle, hard-to-track bug. In my experience, it's better to fail in an obvious manner if you cannot guarantee completely safe fallback. -dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
