Axis 1.2.1 - Lockdown and cutting the release.

[Davanum Srinivas]

Folks,
That's it folks, time to cut the release. Please dont commit anything
without talking to Glen (or me).

Tom, Guillaume, Venkat, 
Please run your tests one last time :)

Glen,
All yours...

thanks,
dims

-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

jax-rpc handlers and axis handlers

[patricia zuno]

Hello,

I have series of jax-rpc handlers defined in the handlerInfoChain and
a generic axis handler. As each jax-rpc handler is called, I want it
to be executed via the generic axis handler that I have defined. Is it
possiable pass the jax-rpc handlers to axis handler. And if so can
this be defined in the *wsdd file.

thanks, pat

RE: AdminClient Deployment problem, possibly user related

[Steven Smith]

The WSDL:


http://www.geometryit.com/WebService/Forestry/Mapping";
xmlns="http://schemas.xmlsoap.org/wsdl/";
xmlns:tns="http://www.geometryit.com/WebService/Forestry/Mapping";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:gml="http://www.opengis.net/gml";
>
http://www.geometryit.com/WebService/Forestry/Mapping";
xmlns="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>

http://www.opengis.net/gml";
schemaLocation="feature.xsd" />




























































































































































 

Re: AdminClient Deployment problem, possibly user related

[Anne Thomas Manes]

WSDL please...

On 6/13/05, Steven Smith <[EMAIL PROTECTED]> wrote:
>  
>  
> I am trying to develop a Web Service and have come to a stage where I want
> to deploy it to start testing. However, I can't deploy and the error it
> gives me is totally useless. I have noticed others with the same error on
> the mailing list, but I can't find an answer to any of them. 
>   
> I am deploying to Tomcat 4.1.24 containing Axis 1.2. I have tried both
> calling the AdminClient directly and using the Ant task, both of which give
> the same error. 
>   
> I created the WSDL file by hand and then used that to generate the Java code
> and WSDD files so I am pretty sure that these are fine. I think the problem
> is to do with admin users. I have explicitly set the admin password but
> there is no mention of a username to use with it anywhere I have looked. I
> can find the password in the server-config.wsdd file but where do users came
> from? According to all of the documentation you don't even need to specify a
> user. I have tried anything I can think of, but no success. I am on the same
> machine, but have enabled remote administration anyway (to no avail). 
>   
> The error message is: 
>   
> deploy:
> [axis-admin] Processing file \deploy.wsdd
> [axis-admin] AxisFault
> [axis-admin]  faultCode:
> {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
> [axis-admin]  faultSubcode: 
> [axis-admin]  faultString:
> java.lang.reflect.InvocationTargetException
> [axis-admin]  faultActor: 
> [axis-admin]  faultNode: 
> [axis-admin]  faultDetail: 
> [axis-admin]  {http://xml.apache.org/axis/}hostname:kalel
> [axis-admin] Running axis-admin with parameters:
> [axis-admin]   action:
> [axis-admin]  
> url:http://localhost:8080/axis/services/AdminService
> [axis-admin]   hostname:null
> [axis-admin]   port:0
> [axis-admin]   servletPath:null
> [axis-admin]   fileProtocol:null
> [axis-admin]   username:null
> [axis-admin]   password:null
> [axis-admin]   transportChain:null
> [axis-admin]   debug:true 
>   
> BUILD FAILED
> file:/WebServices/development/build/anthill_build.xml:136:
> axis-admin failed with 
> {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
> java.lang.reflect.InvocationTargetException
>  
>   
> Any help would be greatly appreciated. 
>   
> Thankyou. 
>   
> 
> -- 
> Steven Smith <[EMAIL PROTECTED]>
> Software Developer / Analyst
>  
>  
>  
>  Telephone :  03 6223 1999 
>  Facsimile :  03 6223 1988 
>  Web :  www.geometryit.com 
>  Address :  31 Salamanca Square, Battery Point, TAS 7004, Australia 
>  Postal :  PO Box 844, Sandy Bay, TAS 7006, Australia 
>

Re: Overloading on Axis 1.1 vs. 1.2

[Anne Thomas Manes]

Yes -- but you must remember that SOAP isn't a distributed object
system. It's a message passing system. The SOAP server is supposed to
figure out what to do with an incoming message by examining the QName
of the child element of the SOAP Body (the signature). But that
signature doesn't differentiate between overloaded methods. If the
QName maps to multiple object methods, then Axis must dig deeper into
the message to figure out how to process it, but it doesn't know how
to dig deeper into the message until it knows what method it's
supposed to invoke. It's just bad.

And there's no telling what might happen if you try to access the
service from a non-Axis client.

You have the following choices:
- define a different operation for each set of possible parameters
- define one operation which contains choice elements (bad for interop) 
- define one operation using the message style, and your application
programmatically dispatches the appropriate methods (much more work
for you)

The first option is definitely the winner. 

One suggestion: submit a feature request that would allow you to
define mappings between multiple WSDL operations to overloaded method
signatures. That way you wouldn't need to change your application, but
you could expose unique operation names.

Anne

On 6/13/05, Andy Kriger <[EMAIL PROTECTED]> wrote:
> What is the suggested strategy for dealing with methods where
> overloading makes sense?
> 
> I know that you recommend working from the WSDL to the code, but the
> Axis code generation makes working from code to WSDL easy enough to
> avoid that step, therefore I ask these questions without so much
> familiarity with what WSDL affords in terms of parameter defintions.
> As I see it, either you have a lot of similarly named methods exposing
> each overload variant or you have one method that takes all of the
> parameters possible. Not sure how removing overloading is a win for
> the developer if those are our options.
> 
> On 6/13/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > The SOAP 1.1 and WSDL 1.1 specifications allow method overloading. I
> > just looked through the SOAP 1.2 specification, and it also appears to
> > allow method overloading. WSDL 2.0 disallows method overloading. The
> > WS-I Basic Profile also disallows method overloading.
> >
> > Axis 1.2 should support method overloading. If it doesn't it's a bug.
> > But you shouldn't do it.
> >
> > Anne
> >
> > On 6/13/05, Brian Gladish <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > Hi,
> > >
> > >
> > >
> > > Our Web Service has a number of "execute" methods which were being invoked
> > > properly on 1.1, but which seem to cause Axis confusion on 1.2.  The
> > > specific case now is that a method in Java which has the signature
> > > execute(String, String) is being confused with execute(String, byte[]) 
> > > (the
> > > latter is being called on the server when the former is invoked on the
> > > client).  In addition, the byte[] parameter is being passed in as null 
> > > even
> > > though the string passed as the second argument on the client call is not
> > > null and not empty.
> > >
> > >
> > >
> > > WSDL for execute(String, String) (this is the method I expect to be
> > > invoked):
> > >
> > >
> > >
> > >
> > >
> > >   
> > >
> > >   
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > WSDL for execute(String, byte[]) (the method actually invoked):
> > >
> > >
> > >
> > >
> > >
> > >   
> > >
> > >   
> > >
> > >
> > >
> > >
> > >
> > > Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2 acting
> > > correctly and the problem was that 1.1 should not have supported this
> > > overloading?
> > >
> > >
> > >
> > > Brian J. Gladish
> > >
> > > Senior Software Engineer
> > >
> > > Raining Data Corporation (http://www.rainingdata.com)
> > >
> > > (949) 260-5140
> > >
> > >
> >
>

AdminClient Deployment problem, possibly user related

[Steven Smith]

I am trying to develop a 
Web Service and have come to a stage where I want to deploy it to start testing. 
However, I can't deploy and the error it gives me is totally useless. I have 
noticed others with the same error on the mailing list, but I can't find an 
answer to any of them.
 
I am deploying to Tomcat 
4.1.24 containing Axis 1.2. I have tried both calling the AdminClient directly 
and using the Ant task, both of which give the same error.
 
I created the WSDL file by 
hand and then used that to generate the Java code and WSDD files so I am pretty 
sure that these are fine. I think the problem is to do with admin users. I have 
explicitly set the admin password but there is no mention of a username to use 
with it anywhere I have looked. I can find the password in the 
server-config.wsdd file but where do users came from? According to all of the 
documentation you don't even need to specify a user. I have tried anything I can 
think of, but no success. I am on the same machine, but have enabled remote 
administration anyway (to no avail).
 
The error message 
is:
 
deploy:[axis-admin] 
Processing file \deploy.wsdd[axis-admin] 
AxisFault[axis-admin]  faultCode: 
{http://schemas.xmlsoap.org/soap/envelope/}Server.userException[axis-admin]  
faultSubcode: [axis-admin]  faultString: 
java.lang.reflect.InvocationTargetException[axis-admin]  faultActor: 
[axis-admin]  faultNode: [axis-admin]  faultDetail: 
[axis-admin] 
 {http://xml.apache.org/axis/}hostname:kalel[axis-admin] Running 
axis-admin with parameters:[axis-admin]   
action:[axis-admin]   url:http://localhost:8080/axis/services/AdminService[axis-admin]   hostname:null[axis-admin]   
port:0[axis-admin]   servletPath:null[axis-admin]   
fileProtocol:null[axis-admin]   
username:null[axis-admin]   
password:null[axis-admin]   
transportChain:null[axis-admin]   debug:true
 
BUILD 
FAILEDfile:/WebServices/development/build/anthill_build.xml:136: 
axis-admin failed with  
{http://schemas.xmlsoap.org/soap/envelope/}Server.userException 
java.lang.reflect.InvocationTargetException
 
Any help would be greatly 
appreciated.
 
Thankyou.


 

-- Steven Smith <[EMAIL PROTECTED]>Software 
Developer / Analyst

  
  

  


  

  Telephone
  : 
  03 6223 1999

  Facsimile
  : 
  03 6223 1988

  Web
  : 
  www.geometryit.com

  Address
  : 
  31 Salamanca Square, Battery Point, TAS 7004, Australia

  Postal
  : 
  PO Box 844, Sandy Bay, TAS 7006, 
Australia

 

 

RE: Overloading on Axis 1.1 vs. 1.2

[Brian Gladish]

We have a new WS interface which does not overload, but we wanted to
support the old interface on 1.2.

Brian J. Gladish
Senior Software Engineer
Raining Data Corporation (http://www.rainingdata.com)
(949) 260-5140
 

-Original Message-
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 13, 2005 12:43 PM
To: axis-user@ws.apache.org
Subject: Re: Overloading on Axis 1.1 vs. 1.2

The SOAP 1.1 and WSDL 1.1 specifications allow method overloading. I
just looked through the SOAP 1.2 specification, and it also appears to
allow method overloading. WSDL 2.0 disallows method overloading. The
WS-I Basic Profile also disallows method overloading.

Axis 1.2 should support method overloading. If it doesn't it's a bug.
But you shouldn't do it.

Anne 

On 6/13/05, Brian Gladish <[EMAIL PROTECTED]> wrote:
>  
>  
> 
> Hi, 
> 
>   
> 
> Our Web Service has a number of "execute" methods which were being
invoked
> properly on 1.1, but which seem to cause Axis confusion on 1.2.  The
> specific case now is that a method in Java which has the signature
> execute(String, String) is being confused with execute(String, byte[])
(the
> latter is being called on the server when the former is invoked on the
> client).  In addition, the byte[] parameter is being passed in as null
even
> though the string passed as the second argument on the client call is
not
> null and not empty. 
> 
>   
> 
> WSDL for execute(String, String) (this is the method I expect to be
> invoked): 
> 
>   
> 
> 
> 
>
> 
>
> 
> 
> 
>   
> 
>   
> 
> WSDL for execute(String, byte[]) (the method actually invoked): 
> 
>   
> 
> 
> 
>
> 
>
> 
> 
> 
>   
> 
> Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2 acting
> correctly and the problem was that 1.1 should not have supported this
> overloading? 
> 
>   
> 
> Brian J. Gladish 
> 
> Senior Software Engineer 
> 
> Raining Data Corporation (http://www.rainingdata.com) 
> 
> (949) 260-5140 
> 
>

Re: Overloading on Axis 1.1 vs. 1.2

[Andy Kriger]

What is the suggested strategy for dealing with methods where
overloading makes sense?

I know that you recommend working from the WSDL to the code, but the
Axis code generation makes working from code to WSDL easy enough to
avoid that step, therefore I ask these questions without so much
familiarity with what WSDL affords in terms of parameter defintions.
As I see it, either you have a lot of similarly named methods exposing
each overload variant or you have one method that takes all of the
parameters possible. Not sure how removing overloading is a win for
the developer if those are our options.

On 6/13/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> The SOAP 1.1 and WSDL 1.1 specifications allow method overloading. I
> just looked through the SOAP 1.2 specification, and it also appears to
> allow method overloading. WSDL 2.0 disallows method overloading. The
> WS-I Basic Profile also disallows method overloading.
> 
> Axis 1.2 should support method overloading. If it doesn't it's a bug.
> But you shouldn't do it.
> 
> Anne
> 
> On 6/13/05, Brian Gladish <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Hi,
> >
> >
> >
> > Our Web Service has a number of "execute" methods which were being invoked
> > properly on 1.1, but which seem to cause Axis confusion on 1.2.  The
> > specific case now is that a method in Java which has the signature
> > execute(String, String) is being confused with execute(String, byte[]) (the
> > latter is being called on the server when the former is invoked on the
> > client).  In addition, the byte[] parameter is being passed in as null even
> > though the string passed as the second argument on the client call is not
> > null and not empty.
> >
> >
> >
> > WSDL for execute(String, String) (this is the method I expect to be
> > invoked):
> >
> >
> >
> >
> >
> >   
> >
> >   
> >
> >
> >
> >
> >
> >
> >
> > WSDL for execute(String, byte[]) (the method actually invoked):
> >
> >
> >
> >
> >
> >   
> >
> >   
> >
> >
> >
> >
> >
> > Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2 acting
> > correctly and the problem was that 1.1 should not have supported this
> > overloading?
> >
> >
> >
> > Brian J. Gladish
> >
> > Senior Software Engineer
> >
> > Raining Data Corporation (http://www.rainingdata.com)
> >
> > (949) 260-5140
> >
> >
>

Simple type exception

[Kador, Daniel]

I've asked a question similar to this on the list before, but it went
unanswered.  I'm not sure what could be causing this, as I believe my
schemas are proper (they certainly are well-formed according to XMLSpy)
and that I'm doing everything correctly in terms of generating the Java
code.  Please refer to the attached files if you have any schema or
wsdl-specific questions.

The problem is that I cannot view the deployed service's WSDL in my
browser (at http://localhost:8080/axis/services/WSDLExPort?wsdl, in this
case).  I receive this error:

AXIS error

Sorry, something seems to have gone wrong... here are the details:

Fault - Bean attribute model is of type java.lang.String, which is not a
simple type

AxisFault
 faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultSubcode: 
 faultString: Bean attribute model is of type java.lang.String, which is
not a simple type
 faultActor: 
 faultNode: 
 faultDetail: 
{http://xml.apache.org/axis/}hostname:ORLIWG2H5Y61

First of all, that error message doesn't make sense to me because
java.lang.String IS a simple type.  If anybody can explain that, I'd
appreciate it.

Secondly, regardless of my WSDL's non-viewable status, I appear to not
have any problems actually sending requests to the server and receiving
responses.  I can view what's sent over the line with TCPMonitor, and
everything looks like it should.  I'd like to be able to explain why the
WSDL viewing page is blowing up though, so the service simply working
isn't really an option for me at this time.

Thanks for taking the time to read this.

Dan Kador



CEM4-2e.xsd
Description: CEM4-2e.xsd


trans-schema.xsd
Description: trans-schema.xsd


wsdl-xml.wsdl
Description: wsdl-xml.wsdl


wsdl-xml.xsd
Description: wsdl-xml.xsd

Re: Overloading on Axis 1.1 vs. 1.2

[Anne Thomas Manes]

The SOAP 1.1 and WSDL 1.1 specifications allow method overloading. I
just looked through the SOAP 1.2 specification, and it also appears to
allow method overloading. WSDL 2.0 disallows method overloading. The
WS-I Basic Profile also disallows method overloading.

Axis 1.2 should support method overloading. If it doesn't it's a bug.
But you shouldn't do it.

Anne 

On 6/13/05, Brian Gladish <[EMAIL PROTECTED]> wrote:
>  
>  
> 
> Hi, 
> 
>   
> 
> Our Web Service has a number of "execute" methods which were being invoked
> properly on 1.1, but which seem to cause Axis confusion on 1.2.  The
> specific case now is that a method in Java which has the signature
> execute(String, String) is being confused with execute(String, byte[]) (the
> latter is being called on the server when the former is invoked on the
> client).  In addition, the byte[] parameter is being passed in as null even
> though the string passed as the second argument on the client call is not
> null and not empty. 
> 
>   
> 
> WSDL for execute(String, String) (this is the method I expect to be
> invoked): 
> 
>   
> 
> 
> 
>
> 
>
> 
> 
> 
>   
> 
>   
> 
> WSDL for execute(String, byte[]) (the method actually invoked): 
> 
>   
> 
> 
> 
>
> 
>
> 
> 
> 
>   
> 
> Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2 acting
> correctly and the problem was that 1.1 should not have supported this
> overloading? 
> 
>   
> 
> Brian J. Gladish 
> 
> Senior Software Engineer 
> 
> Raining Data Corporation (http://www.rainingdata.com) 
> 
> (949) 260-5140 
> 
>

Overloading on Axis 1.1 vs. 1.2

[Brian Gladish]

Hi,

 

Our Web Service has a number of “execute”
methods which were being invoked properly on 1.1, but which seem to cause Axis
confusion on 1.2.  The specific case
now is that a method in Java which has the signature execute(String,
String) is being confused with execute(String, byte[]) (the latter is being
called on the server when the former is invoked on the client).  In addition, the byte[] parameter is
being passed in as null even though the string passed as the second argument on
the client call is not null and not empty.

 

WSDL for execute(String, String)
(this is the method I expect to be invoked):

 

   :message name="executeRequest3">

  

  

   :message>

 

 

WSDL for execute(String, byte[])
(the method actually invoked):

 

   :message name="executeRequest">

  

  

   :message>

 

Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2
acting correctly and the problem was that 1.1 should not have supported this
overloading?

 

Brian J. Gladish

Senior Software Engineer

Raining Data Corporation (http://www.rainingdata.com)

(949) 260-5140

 

How to carry Soap:header along with Soap:fault

[Feng Xie \(fxie\)]

I hope I can get 
some help on this issue:
 
In my wsdd, I have 
document/literal binding for the following operation ( please see the 
snippet from my wsdl) , if the server return normally for this 
operation, the Soap response carries the Soap:header. However, whenever an 
expection ( either remoteException or data defined exception) is thrown at the 
server side, the Soap response message only carries the Soap:fault element. NO 
Soap:header element.
 
Thanks in 
advance,
 
Feng
 
The snippet from my 
wsdl






input>



output>


fault>
operation>

Axis Exception & WSS4J

[Hal]

Hi all,

I have successfully installed Axis and deployed a few web services.
Recently I tried to install the WSS4J.jar package in order to add some 
ws-security to my web services.

So I modified my deploy.wsdd file and added these lines :

 
  
   
   
  
 

The I execute the command "java org.apache.axis.client.AdminClient 
deploy.wsdd", which works.
But then when I try to list the web services deployed in Axis via this page :

http://localhost:8080/axis/servlet/AxisServlet

Nothing appears and I get this error in Apache Tomcat log : 
java.lang.NoClassDefFoundError: org/apache/axis/handlers/BasicHandler
(complete trace at the end). But this class is in the axis.jar package ??

I'm running Apache Tomcat 5.0.30, Axis 1.1, and axis.jar and the other jars are 
in the classpath (including wss4j.jar).
I found someone with exacty the same problem here but no real answer:
http://www.archivum.info/axis-user@ws.apache.org/2005-06/msg00292.html

Any help would be greatly appreciated. Thank you in advance for all your 
answers..
Regards,

Alexis.

--
java.lang.NoClassDefFoundError: org/apache/axis/handlers/BasicHandler
   at java.lang.ClassLoader.defineClass0(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
   at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.ja=va:123)
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
   at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
   at 
org.apache.catalina.loader.StandardClassLoader.findClass(Standar=dClassLoader.java:485)
   at 
org.apache.catalina.loader.StandardClassLoader.loadClass(Standar=dClassLoader.java:820)
   at 
org.apache.catalina.loader.StandardClassLoader.loadClass(Standar=dClassLoader.java:721)
   at 
org.apache.catalina.loader.StandardClassLoader.loadClass(Standar=dClassLoader.java:803)
   at 
org.apache.catalina.loader.StandardClassLoader.loadClass(Standar=dClassLoader.java:721)
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappCla=ssLoader.java:1327)
   at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappCla=ssLoader.java:1189)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:219)
   at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:187)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:171)
   at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:112)
   at 
org.apache.axis.deployment.wsdd.WSDDDeployableItem.getJavaClass(=WSDDDeployableItem.java:389)

RE: Unknown Location

[Grossberger, Guenter]

Someone elase had a very similar problem and got this answer:

i believe because the core Java classes will only be loaded from your
JAVA_HOME location

there are very specific rules to how Tomcat classloading works. 
specific packages will only be loaded from specific locations only.

more info here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html



On a Linux bos you can do something like
find . -name *.jar |xargs grep "javax.xml.soap.SOAPBody.class"
in order to find all jar-Files containing SAAJ.

Bye,
Guenter
 

> -Original Message-
> From: J R [mailto:[EMAIL PROTECTED] 
> Sent: Monday, June 13, 2005 3:31 PM
> To: axis-user@ws.apache.org
> Subject: Unknown Location
> 
> Hi everyone,
> I followed the installation for Axis to the 't'. 
> However, when I look at the happyaxis page, I get the
> following:
> 
>   Error: Invalid version of SAAJ API found in an
> unknown location.
> Make sure that Axis' saaj.jar precedes an unknown
> location in
> CLASSPATH.
>  Axis will not work.
>  See http://ws.apache.org/axis/java/install.html
>* Found JAX-RPC API ( javax.xml.rpc.Service ) at an
> unknown location
> 
>* Found Apache-Axis (
> org.apache.axis.transport.http.AxisServlet ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/l
> ib/axis.jar
> 
>* Found Jakarta-Commons Discovery (
> org.apache.commons.discovery.Resource ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/l
> ib/commons-discovery-0.2.jar
> 
>* Found Jakarta-Commons Logging (
> org.apache.commons.logging.Log ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/bin/commons-logging-api.jar
> 
>* Found Log4j ( org.apache.log4j.Layout ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/l
> ib/log4j-1.2.8.jar
> 
>* Found IBM's WSDL4Java (
> com.ibm.wsdl.factory.WSDLFactoryImpl ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/l
> ib/wsdl4j-1.5.1.jar
> 
>* Found JAXP implementation (
> javax.xml.parsers.SAXParserFactory ) at
> an unknown location
> 
>* Found Activation API (
> javax.activation.DataHandler ) at
> /usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/l
> ib/activation.jar
> 
> Any ideas how to correct?
> 
> JR
> 
> 
>   
> __ 
> Do you Yahoo!? 
> Make Yahoo! your home page 
> http://www.yahoo.com/r/hs
> 

Unknown Location

[J R]

Hi everyone,
I followed the installation for Axis to the 't'. 
However, when I look at the happyaxis page, I get the
following:

  Error: Invalid version of SAAJ API found in an
unknown location.
Make sure that Axis' saaj.jar precedes an unknown
location in
CLASSPATH.
 Axis will not work.
 See http://ws.apache.org/axis/java/install.html
   * Found JAX-RPC API ( javax.xml.rpc.Service ) at an
unknown location

   * Found Apache-Axis (
org.apache.axis.transport.http.AxisServlet ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/lib/axis.jar

   * Found Jakarta-Commons Discovery (
org.apache.commons.discovery.Resource ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/lib/commons-discovery-0.2.jar

   * Found Jakarta-Commons Logging (
org.apache.commons.logging.Log ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/bin/commons-logging-api.jar

   * Found Log4j ( org.apache.log4j.Layout ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/lib/log4j-1.2.8.jar

   * Found IBM's WSDL4Java (
com.ibm.wsdl.factory.WSDLFactoryImpl ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/lib/wsdl4j-1.5.1.jar

   * Found JAXP implementation (
javax.xml.parsers.SAXParserFactory ) at
an unknown location

   * Found Activation API (
javax.activation.DataHandler ) at
/usr/local/tomcat/jakarta-tomcat-5.0.18/webapps/axis/WEB-INF/lib/activation.jar

Any ideas how to correct?

JR



__ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

[Andreas Bohnert]

thanks!

Davanum Srinivas wrote:

The jdk15 comes with dom3 which is a not compatible with SAAJ 1.2
spec. can you please drop the xercesImpl.jar and xmlParserAPIs.jar in
java/lib directory. if that does not work, please drop them into
JDK15\jre\lib\endorsed directory (as per
http://java.sun.com/j2se/1.4.2/docs/guide/standards/).

thanks,
dims


On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:
 

hi dims,

I would like to help, but I am not able to compile the sources.
the problem is related to org.w3c.dom.* which comes with the the jdk 1.5
(rt.jar).
I get this:

   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45:
org.apache.axis.message.NodeImpl is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class NodeImpl implements org.w3c.dom.Node,
javax.xml.soap.Node,
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73:
org.apache.axis.message.MessageElement is not abstract and does not
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class MessageElement extends NodeImpl implements
SOAPElement,
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40:
org.apache.axis.message.SOAPHeaderElement is not abstract and does not
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class SOAPHeaderElement extends MessageElement
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90:
org.apache.axis.SOAPPart is not abstract and does not override abstract
method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in
org.w3c.dom.Document
   [javac] public class SOAPPart extends javax.xml.soap.SOAPPart
implements Part
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50:
org.apache.axis.message.SOAPEnvelope is not abstract and does not
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class SOAPEnvelope extends MessageElement
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50:
org.apache.axis.message.SOAPHeader is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class SOAPHeader extends MessageElement
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46:
org.apache.axis.message.SOAPBody is not abstract and does not override
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class SOAPBody extends MessageElement
   [javac] ^
   [javac]
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37:
org.apache.axis.message.SOAPBodyElement is not abstract and does not
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class SOAPBodyElement extends MessageElement

regards,
andreas


Davanum Srinivas wrote:
   

Andreas,

if you can help with reviewing the code in CommonsHTTPSender and
coming up with a patch that will be the quickest way to deal with
this. you see I don't have a way to test this. Please open a new bug
or add comments for me to reopen this one once u have a patch.

thanks,
dims

On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:

 

hi,

for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
blocker. http 1.1 connections are not working with older apache proxies
(<=1.3.33)

the issue is already marked as fixed, but unfortunately the patch
doesn't work for me. I still stuck with axis 1.2RC3

I have added a comment to this issue together with a snippet of my
client code.


regards,
andreas


   


 
   



 

Re: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

[Davanum Srinivas]

please see my comment in the bug.

thanks,
dims

On 6/13/05, Gerry Gao <[EMAIL PROTECTED]> wrote:
> Hi dims,
> 
> I have submit a patch to http://issues.apache.org/jira/browse/AXIS-895.
> 
> I don't know what's wrong with JIRA, the patch's name is wrong.
> 
> Anyway it is the one named HTTPSender and with 11kb size.
> 
> http://issues.apache.org/jira/secure/attachment/12310695/HTTPSender.java
> 
> regards
> Gerry
> 
> - Original Message -
> From: "Davanum Srinivas" <[EMAIL PROTECTED]>
> To: "Gerry Gao" <[EMAIL PROTECTED]>
> Cc: 
> Sent: Monday, June 13, 2005 6:59 PM
> Subject: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))
> 
> 
> Gerry,
> 
> Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
> worry about a test case right now...i'd like to review the code patch
> first.
> 
> thanks,
> dims
> 
> On 6/13/05, Gerry Gao <[EMAIL PROTECTED]> wrote:
> > Hi dims,
> >
> > Well done! And hope this is not too late.
> >
> > I still have some concern about 
> > http://issues.apache.org/jira/browse/AXIS-895.
> >
> > As I reviewed the latest CVS code and do a basic test on it, I think there 
> > is still some issue will the cookie stuff in HTTPSender and 
> > CommonsHTTPSender.
> >
> > Now the HTTPSender and CommonsHTTPSender have different cookie behavior for 
> > "maintainSession" client, and both of the behaviors are not completely 
> > correct.
> >
> > According to my test, now HTTPSender is a closer to the perfect.
> >
> > Here is a sample for HTTPSender now (paste from tcpmon):
> >
> > request 1:
> > 
> > respones 1:
> > Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> > Set-Cookie: a=a
> > Set-Cookie: b=b
> >
> > request 2:
> > Cookie: JSESSIONID=14qbbc5mptua2
> > Cookie: a=a
> > Cookie: b=b
> > respnonse 2:
> > Set-Cookie: a=a1
> > Set-Cookie: c=c
> >
> > request 3:
> > Cookie: JSESSIONID=14qbbc5mptua2
> > Cookie: a=a
> > Cookie: b=b
> > Cookie: a=a1
> > Cookie: c=c
> >
> > IMO, the reqesut 3 should only have one cookie with name "a" and it should 
> > be "a=a1" instead of tow cookies.
> >
> > For the same sitation for CommonsHTTPSender, it can't even maintain the 
> > session correctly!
> >
> > request 1:
> > 
> > respones 1:
> > Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> > Set-Cookie: a=a
> > Set-Cookie: b=b
> >
> > request 2:
> > Cookie: JSESSIONID=bpg1ne69gl099
> > Cookie: a=a
> > Cookie: b=b
> > respnonse 2:
> > Set-Cookie: a=a1
> > Set-Cookie: c=c
> >
> >
> > request 3:
> > Cookie: a=a1
> > Cookie: c=c
> >
> > With CommonsHTTPSender, it only send to sever the cookies which are added 
> > in the very last response.
> >
> > This result is consistent with the code I reviewed.
> >
> > IMO, it should use HashMap or Hashtable instead of String[] to handle 
> > multicookies.
> > Hope this helps.
> >
> > BTW, I do want submit a test case to reoccur this, but I don't know if it 
> > must be a standalone runnable JUnit test case. Actually, don't know how to 
> > pack a test comfortable for AXIS.
> >
> > Gerry
> >
> > - Original Message -
> > From: "Davanum Srinivas" <[EMAIL PROTECTED]>
> > To: ; 
> > Sent: Monday, June 13, 2005 11:03 AM
> > Subject: Re: Blockers for Axis 1.2.1 Release(?)
> >
> >
> > Team, Folks,
> >
> > Zero blockers now...Please try latest CVS / Nightly ASAP!
> >
> > thanks,
> > dims
> >
> 
> 
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

[Gerry Gao]

Hi dims, 

I have submit a patch to http://issues.apache.org/jira/browse/AXIS-895.

I don't know what's wrong with JIRA, the patch's name is wrong.

Anyway it is the one named HTTPSender and with 11kb size.

http://issues.apache.org/jira/secure/attachment/12310695/HTTPSender.java

regards
Gerry

- Original Message - 
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: "Gerry Gao" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, June 13, 2005 6:59 PM
Subject: AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))


Gerry,

Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
worry about a test case right now...i'd like to review the code patch
first.

thanks,
dims

On 6/13/05, Gerry Gao <[EMAIL PROTECTED]> wrote:
> Hi dims,
> 
> Well done! And hope this is not too late.
> 
> I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.
> 
> As I reviewed the latest CVS code and do a basic test on it, I think there is 
> still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.
> 
> Now the HTTPSender and CommonsHTTPSender have different cookie behavior for 
> "maintainSession" client, and both of the behaviors are not completely 
> correct.
> 
> According to my test, now HTTPSender is a closer to the perfect.
> 
> Here is a sample for HTTPSender now (paste from tcpmon):
> 
> request 1:
> 
> respones 1:
> Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> request 3:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> Cookie: a=a1
> Cookie: c=c
> 
> IMO, the reqesut 3 should only have one cookie with name "a" and it should be 
> "a=a1" instead of tow cookies.
> 
> For the same sitation for CommonsHTTPSender, it can't even maintain the 
> session correctly!
> 
> request 1:
> 
> respones 1:
> Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=bpg1ne69gl099
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> 
> request 3:
> Cookie: a=a1
> Cookie: c=c
> 
> With CommonsHTTPSender, it only send to sever the cookies which are added in 
> the very last response.
> 
> This result is consistent with the code I reviewed.
> 
> IMO, it should use HashMap or Hashtable instead of String[] to handle 
> multicookies.
> Hope this helps.
> 
> BTW, I do want submit a test case to reoccur this, but I don't know if it 
> must be a standalone runnable JUnit test case. Actually, don't know how to 
> pack a test comfortable for AXIS.
> 
> Gerry
> 
> - Original Message -
> From: "Davanum Srinivas" <[EMAIL PROTECTED]>
> To: ; 
> Sent: Monday, June 13, 2005 11:03 AM
> Subject: Re: Blockers for Axis 1.2.1 Release(?)
> 
> 
> Team, Folks,
> 
> Zero blockers now...Please try latest CVS / Nightly ASAP!
> 
> thanks,
> dims
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

[Davanum Srinivas]

The jdk15 comes with dom3 which is a not compatible with SAAJ 1.2
spec. can you please drop the xercesImpl.jar and xmlParserAPIs.jar in
java/lib directory. if that does not work, please drop them into
JDK15\jre\lib\endorsed directory (as per
http://java.sun.com/j2se/1.4.2/docs/guide/standards/).

thanks,
dims


On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:
> hi dims,
> 
> I would like to help, but I am not able to compile the sources.
> the problem is related to org.w3c.dom.* which comes with the the jdk 1.5
> (rt.jar).
> I get this:
> 
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45:
> org.apache.axis.message.NodeImpl is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class NodeImpl implements org.w3c.dom.Node,
> javax.xml.soap.Node,
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73:
> org.apache.axis.message.MessageElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class MessageElement extends NodeImpl implements
> SOAPElement,
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40:
> org.apache.axis.message.SOAPHeaderElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class SOAPHeaderElement extends MessageElement
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90:
> org.apache.axis.SOAPPart is not abstract and does not override abstract
> method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in
> org.w3c.dom.Document
> [javac] public class SOAPPart extends javax.xml.soap.SOAPPart
> implements Part
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50:
> org.apache.axis.message.SOAPEnvelope is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class SOAPEnvelope extends MessageElement
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50:
> org.apache.axis.message.SOAPHeader is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class SOAPHeader extends MessageElement
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46:
> org.apache.axis.message.SOAPBody is not abstract and does not override
> abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class SOAPBody extends MessageElement
> [javac] ^
> [javac]
> /home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37:
> org.apache.axis.message.SOAPBodyElement is not abstract and does not
> override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
> [javac] public class SOAPBodyElement extends MessageElement
> 
> regards,
> andreas
> 
> 
> Davanum Srinivas wrote:
> >Andreas,
> >
> >if you can help with reviewing the code in CommonsHTTPSender and
> >coming up with a patch that will be the quickest way to deal with
> >this. you see I don't have a way to test this. Please open a new bug
> >or add comments for me to reopen this one once u have a patch.
> >
> >thanks,
> >dims
> >
> >On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:
> >
> >>hi,
> >>
> >>for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
> >>blocker. http 1.1 connections are not working with older apache proxies
> >>(<=1.3.33)
> >>
> >>the issue is already marked as fixed, but unfortunately the patch
> >>doesn't work for me. I still stuck with axis 1.2RC3
> >>
> >>I have added a comment to this issue together with a snippet of my
> >>client code.
> >>
> >>
> >>regards,
> >>andreas
> >>
> >>
> >
> >
> >
> 
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

[Andreas Bohnert]

hi dims,

I would like to help, but I am not able to compile the sources.
the problem is related to org.w3c.dom.* which comes with the the jdk 1.5 
(rt.jar).

I get this:

   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/NodeImpl.java:45: 
org.apache.axis.message.NodeImpl is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class NodeImpl implements org.w3c.dom.Node, 
javax.xml.soap.Node,

   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/MessageElement.java:73: 
org.apache.axis.message.MessageElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node
   [javac] public class MessageElement extends NodeImpl implements 
SOAPElement,

   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeaderElement.java:40: 
org.apache.axis.message.SOAPHeaderElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node

   [javac] public class SOAPHeaderElement extends MessageElement
   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/SOAPPart.java:90: 
org.apache.axis.SOAPPart is not abstract and does not override abstract 
method renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in 
org.w3c.dom.Document
   [javac] public class SOAPPart extends javax.xml.soap.SOAPPart 
implements Part

   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPEnvelope.java:50: 
org.apache.axis.message.SOAPEnvelope is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node

   [javac] public class SOAPEnvelope extends MessageElement
   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPHeader.java:50: 
org.apache.axis.message.SOAPHeader is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node

   [javac] public class SOAPHeader extends MessageElement
   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBody.java:46: 
org.apache.axis.message.SOAPBody is not abstract and does not override 
abstract method getUserData(java.lang.String) in org.w3c.dom.Node

   [javac] public class SOAPBody extends MessageElement
   [javac] ^
   [javac] 
/home/abo/workspace/ws-axis/java/src/org/apache/axis/message/SOAPBodyElement.java:37: 
org.apache.axis.message.SOAPBodyElement is not abstract and does not 
override abstract method getUserData(java.lang.String) in org.w3c.dom.Node

   [javac] public class SOAPBodyElement extends MessageElement

regards,
andreas


Davanum Srinivas wrote:

Andreas,

if you can help with reviewing the code in CommonsHTTPSender and
coming up with a patch that will be the quickest way to deal with
this. you see I don't have a way to test this. Please open a new bug
or add comments for me to reopen this one once u have a patch.

thanks,
dims

On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:
 

hi,

for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
blocker. http 1.1 connections are not working with older apache proxies
(<=1.3.33)

the issue is already marked as fixed, but unfortunately the patch
doesn't work for me. I still stuck with axis 1.2RC3

I have added a comment to this issue together with a snippet of my
client code.


regards,
andreas

   



 

RE: Automated server-config.wsdd generation using ant

[Ephemeris Lappis]

How does it work to generate a wsdd file, and jar it into a deployable war ?

>>> -Original Message-
>>> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
>>> Sent: Monday, June 13, 2005 1:16 PM
>>> To: axis-user@ws.apache.org
>>> Cc: Amiel, Meir
>>> Subject: Re: Automated server-config.wsdd generation using ant
>>> 
>>> 
>>> org.apache.axis.utils.Admin client|server 
>>> 
>>> On 6/13/05, Ephemeris Lappis <[EMAIL PROTECTED]> wrote:
>>> >  
>>> > Hello again. 
>>> > Just for your information, i do it, currently, using the 
>>> xmltask to merge
>>> > the axis default server-config.wsdd with the generated deploy.wsdd. 
>>> > It seems to work, but it's a bit 'heavy' ! 
>>> > Any other suggestion is welcome ! 
>>> > 
>>> >  
>>> > 
>>> > --
>>> > Ephemeris Lappis 
>>> >  
>>> >  
>>> > -Original Message-
>>> > From: Amiel, Meir [mailto:[EMAIL PROTECTED]
>>> > Sent: Monday, June 13, 2005 9:07 AM
>>> > To: 'Ephemeris Lappis '; 'Axis-User '
>>> > Subject: RE: Automated server-config.wsdd generation using ant
>>> > 
>>> >  
>>> > 
>>> > I took a different approach in solving the same issue. I have 
>>> a servlet that
>>> > inits on server startup; it then iterates the war file, looks for all
>>> > deploy.wsdd files and deploys the new services.
>>> >  
>>> > 
>>> > -Original Message- 
>>> > From: Ephemeris Lappis 
>>> > To: Axis-User 
>>> > Sent: 6/12/2005 11:40 PM 
>>> > Subject: Automated server-config.wsdd generation using ant 
>>> > 
>>> > Hello. 
>>> > 
>>> > Does anyone know a simple way to automate the generation of a 
>>> deployable 
>>> > server wsdd. Indeed, to build a deployable war, the default 
>>> > server-config.wsdd must be extended with the application's services 
>>> > descriptors, and, to achieve this, we have to either copy/paste the 
>>> > generated services elements, or code a DOM program to add them... 
>>> > 
>>> > I imagine a wsdl2java ant task (or command) extension could 
>>> generate a 
>>> > deployable server-config.wsdd instead of the simple 
>>> deploy.wsdd, based, 
>>> > either on the default axis one, or a task custom one, for 
>>> those who need 
>>> > specific handlers... 
>>> > 
>>> > Some idea ? 
>>> > Thanks... 
>>> > 
>>> > -- 
>>> > Ephemeris Lappis 
>>> 
>>> 
>>> -- 
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: Automated server-config.wsdd generation using ant

[Davanum Srinivas]

org.apache.axis.utils.Admin client|server 

On 6/13/05, Ephemeris Lappis <[EMAIL PROTECTED]> wrote:
>  
> Hello again. 
> Just for your information, i do it, currently, using the xmltask to merge
> the axis default server-config.wsdd with the generated deploy.wsdd. 
> It seems to work, but it's a bit 'heavy' ! 
> Any other suggestion is welcome ! 
> 
>  
> 
> --
> Ephemeris Lappis 
>  
>  
> -Original Message-
> From: Amiel, Meir [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 13, 2005 9:07 AM
> To: 'Ephemeris Lappis '; 'Axis-User '
> Subject: RE: Automated server-config.wsdd generation using ant
> 
>  
> 
> I took a different approach in solving the same issue. I have a servlet that
> inits on server startup; it then iterates the war file, looks for all
> deploy.wsdd files and deploys the new services.
>  
> 
> -Original Message- 
> From: Ephemeris Lappis 
> To: Axis-User 
> Sent: 6/12/2005 11:40 PM 
> Subject: Automated server-config.wsdd generation using ant 
> 
> Hello. 
> 
> Does anyone know a simple way to automate the generation of a deployable 
> server wsdd. Indeed, to build a deployable war, the default 
> server-config.wsdd must be extended with the application's services 
> descriptors, and, to achieve this, we have to either copy/paste the 
> generated services elements, or code a DOM program to add them... 
> 
> I imagine a wsdl2java ant task (or command) extension could generate a 
> deployable server-config.wsdd instead of the simple deploy.wsdd, based, 
> either on the default axis one, or a task custom one, for those who need 
> specific handlers... 
> 
> Some idea ? 
> Thanks... 
> 
> -- 
> Ephemeris Lappis 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Retrieving original data

[Laura Baño]

Hi there,

 

I’m working with axis 1_2RC3 with xml
documents. I wonder how to preserve the original data, so it isn’t
omitted the namespaces that have appeared before. Is there any way to get this?
The matter is the next one:

 

 



…



prueba





 

The problem occurs when I try to retrieve the data, I
only can retrieve the string “prueba”.
Does anybody know how can I obtain the full string?

 

Thanks in advance.

 

Regards, 

 

Laura.

AXIS-2033 (Re: Blockers for Axis 1.2.1 Release(?))

[Davanum Srinivas]

Andreas,

if you can help with reviewing the code in CommonsHTTPSender and
coming up with a patch that will be the quickest way to deal with
this. you see I don't have a way to test this. Please open a new bug
or add comments for me to reopen this one once u have a patch.

thanks,
dims

On 6/13/05, Andreas Bohnert <[EMAIL PROTECTED]> wrote:
> hi,
> 
> for me http://issues.apache.org/jira/browse/AXIS-2033 is still a
> blocker. http 1.1 connections are not working with older apache proxies
> (<=1.3.33)
> 
> the issue is already marked as fixed, but unfortunately the patch
> doesn't work for me. I still stuck with axis 1.2RC3
> 
> I have added a comment to this issue together with a snippet of my
> client code.
> 
> 
> regards,
> andreas
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

AXIS-895 (Re: Blockers for Axis 1.2.1 Release(?))

[Davanum Srinivas]

Gerry,

Please submit a patch for HTTPSender/CommonsHTTPSender ASAP!. Don't
worry about a test case right now...i'd like to review the code patch
first.

thanks,
dims

On 6/13/05, Gerry Gao <[EMAIL PROTECTED]> wrote:
> Hi dims,
> 
> Well done! And hope this is not too late.
> 
> I still have some concern about http://issues.apache.org/jira/browse/AXIS-895.
> 
> As I reviewed the latest CVS code and do a basic test on it, I think there is 
> still some issue will the cookie stuff in HTTPSender and CommonsHTTPSender.
> 
> Now the HTTPSender and CommonsHTTPSender have different cookie behavior for 
> "maintainSession" client, and both of the behaviors are not completely 
> correct.
> 
> According to my test, now HTTPSender is a closer to the perfect.
> 
> Here is a sample for HTTPSender now (paste from tcpmon):
> 
> request 1:
> 
> respones 1:
> Set-Cookie: JSESSIONID=14qbbc5mptua2;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> request 3:
> Cookie: JSESSIONID=14qbbc5mptua2
> Cookie: a=a
> Cookie: b=b
> Cookie: a=a1
> Cookie: c=c
> 
> IMO, the reqesut 3 should only have one cookie with name "a" and it should be 
> "a=a1" instead of tow cookies.
> 
> For the same sitation for CommonsHTTPSender, it can't even maintain the 
> session correctly!
> 
> request 1:
> 
> respones 1:
> Set-Cookie: JSESSIONID=bpg1ne69gl099;Path=/axis
> Set-Cookie: a=a
> Set-Cookie: b=b
> 
> request 2:
> Cookie: JSESSIONID=bpg1ne69gl099
> Cookie: a=a
> Cookie: b=b
> respnonse 2:
> Set-Cookie: a=a1
> Set-Cookie: c=c
> 
> 
> request 3:
> Cookie: a=a1
> Cookie: c=c
> 
> With CommonsHTTPSender, it only send to sever the cookies which are added in 
> the very last response.
> 
> This result is consistent with the code I reviewed.
> 
> IMO, it should use HashMap or Hashtable instead of String[] to handle 
> multicookies.
> Hope this helps.
> 
> BTW, I do want submit a test case to reoccur this, but I don't know if it 
> must be a standalone runnable JUnit test case. Actually, don't know how to 
> pack a test comfortable for AXIS.
> 
> Gerry
> 
> - Original Message -
> From: "Davanum Srinivas" <[EMAIL PROTECTED]>
> To: ; 
> Sent: Monday, June 13, 2005 11:03 AM
> Subject: Re: Blockers for Axis 1.2.1 Release(?)
> 
> 
> Team, Folks,
> 
> Zero blockers now...Please try latest CVS / Nightly ASAP!
> 
> thanks,
> dims
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: deploying web service

[Kanchana Welagedara]

Hi 

Hope you are refering Axis 2?(Note that you put [Axis 2] in your email
heading if  you write to Axis 2) or what?
If it is Axis 2 , Please refer 

http://ws.apache.org/axis2/

If it's Axis 1 Please refer

http://ws.apache.org/axis/java/user-guide.html

There's  nothing in complex .. This is pretty cool stuff and very
clear documentation to experience Web Services.I have deployed My
service Web Service using Axis2  and Axis 1.Every thing went smooth
and fine.

It seems your web application is Tomcat .Once installed tomcat, the
folder structure will be created for you automatically and then you
need to configure axis by following the instruction given in above
links.
Kanchana

On 6/13/05, Plorks mail <[EMAIL PROTECTED]> wrote:
> 
> 
> Hi all,
> 
> I'm trying to deploy my web service to tomcat, but i'm getting a bit stuck
> as to where i put the files
> 
> I've created a folder under tomcat_home\webapps call myService
> 
> e.g. C:\Tomcat\webapps\myservice
> 
> I've then created a WEB-INF folder.  In the WEB-INF folder I've created a
> classes and a lib folder
> 
> e.g.  C:\Tomcat\webapps\myService\WEB-INF\classes
>C:\Tomcat\webapps\myService\WEB-INF\lib
> 
> 
> I've then copied 2 files into the WEB-INF folder server-config.wsdd and
> web.xml
> 
> e.g.  C:\Tomcat\webapps\myService\WEB-INF contains
>  \classes
>  \lib
>  server-config.wsdd
>  web.xml
> 
> 
> Can someone please tell me where i put myService.WSDL file?
> 
> Also do i need to create a myService.WAR file?  Where do i put this file
> 
> Do i need any other files ?
> 
> Thanks for any help
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >From: Woodchuck <[EMAIL PROTECTED]>
> >Reply-To: axis-user@ws.apache.org
> >To: axis-user@ws.apache.org
> >Subject: Re: deploying web service
> >Date: Fri, 10 Jun 2005 12:55:35 -0700 (PDT)
> >
> >hihi,
> >
> >the deploy/undeploy.wsdd are not needed in production.  they are used
> >to generate the server-config.wsdd
> >
> >the server-config.wsdd goes into your webapp/WEB-INF folder (same as
> >your web.xml deployment descriptor file)
> >
> >if you have web services working on your local machine, deploying it on
> >'the network' requires no change to your web service.  you should be
> >able to just copy your entire web service app to your network server
> >and have it work just the same.  only the clients who access the web
> >service needs to change, they need to know where the new location of
> >your web service is (eg. the proxy/stub classes if you're using any).
> >
> >hth,
> >woodchuck
> >
> >
> >--- Plorks mail <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > Hi all
> > >
> > > I've developeed a web service on my local PC.
> > >
> > > I now need to deploy this to our network so it can be used.
> > >
> > > Can someone point to an example of deploying a webservice to tomcat.
> > > I've
> > > read a few articles but they don't seem to be relevant/quite complex
> > > to
> > > understand
> > >
> > > I have my deploy/undeploy/server-cofig wsdd and my wsdl - i just
> > > don't know
> > > where to put them and what to change once they are on the network e.g
> > > the
> > > endpoint in the wsdl file
> > >
> > > Also, i don't understand how the web service will see the java files.
> > >  It
> > > works on my PC i have a project with packages and java files in each
> > > and my
> > > web service can see them
> > >
> > > Sorry for my dumb questions
> > >
> > > Thanks for any help
> > >
> > > _
> > > It's fast, it's easy and it's free. Get MSN Messenger 7.0 today!
> > > http://messenger.msn.co.uk
> > >
> > >
> >
> >
> >
> >
> >__
> >Yahoo! Mail Mobile
> >Take Yahoo! Mail with you! Check email on your mobile phone.
> >http://mobile.yahoo.com/learn/mail
> 
> _
> Winks & nudges are here - download MSN Messenger 7.0 today!
> http://messenger.msn.co.uk
> 
>

RE: Automated server-config.wsdd generation using ant

[Ephemeris Lappis]

Title: RE: Automated server-config.wsdd generation using ant



Hello 
again.
Just 
for your information, i do it, currently, using the xmltask to merge the axis 
default server-config.wsdd with the generated deploy.wsdd.
It 
seems to work, but it's a bit 'heavy' !
Any 
other suggestion is welcome !

--Ephemeris Lappis 

  -Original Message-From: Amiel, Meir 
  [mailto:[EMAIL PROTECTED]Sent: Monday, June 13, 2005 9:07 
  AMTo: 'Ephemeris Lappis '; 'Axis-User 'Subject: RE: 
  Automated server-config.wsdd generation using ant
  I took a different approach in solving the same issue. I have 
  a servlet that inits on server startup; it then iterates the war file, looks 
  for all deploy.wsdd files and deploys the new services.
  -Original Message- From: 
  Ephemeris Lappis To: Axis-User Sent: 6/12/2005 11:40 PM Subject: Automated 
  server-config.wsdd generation using ant 
  Hello. 
  Does anyone know a simple way to automate the generation of a 
  deployable server wsdd. Indeed, to build a deployable 
  war, the default server-config.wsdd must be extended 
  with the application's services descriptors, and, to 
  achieve this, we have to either copy/paste the generated services elements, or code a DOM program to add 
  them... 
  I imagine a wsdl2java ant task (or command) extension could 
  generate a deployable server-config.wsdd instead of 
  the simple deploy.wsdd, based, either on the default 
  axis one, or a task custom one, for those who need specific handlers... 
  Some idea ? Thanks... 
  -- Ephemeris Lappis 

Re: deploying web service

[Plorks mail]

Hi all,

I'm trying to deploy my web service to tomcat, but i'm getting a bit stuck 
as to where i put the files


I've created a folder under tomcat_home\webapps call myService

e.g. C:\Tomcat\webapps\myservice

I've then created a WEB-INF folder.  In the WEB-INF folder I've created a 
classes and a lib folder


e.g.  C:\Tomcat\webapps\myService\WEB-INF\classes
   C:\Tomcat\webapps\myService\WEB-INF\lib


I've then copied 2 files into the WEB-INF folder server-config.wsdd and 
web.xml


e.g.  C:\Tomcat\webapps\myService\WEB-INF contains
 \classes
 \lib
 server-config.wsdd
 web.xml


Can someone please tell me where i put myService.WSDL file?

Also do i need to create a myService.WAR file?  Where do i put this file

Do i need any other files ?

Thanks for any help














From: Woodchuck <[EMAIL PROTECTED]>
Reply-To: axis-user@ws.apache.org
To: axis-user@ws.apache.org
Subject: Re: deploying web service
Date: Fri, 10 Jun 2005 12:55:35 -0700 (PDT)

hihi,

the deploy/undeploy.wsdd are not needed in production.  they are used
to generate the server-config.wsdd

the server-config.wsdd goes into your webapp/WEB-INF folder (same as
your web.xml deployment descriptor file)

if you have web services working on your local machine, deploying it on
'the network' requires no change to your web service.  you should be
able to just copy your entire web service app to your network server
and have it work just the same.  only the clients who access the web
service needs to change, they need to know where the new location of
your web service is (eg. the proxy/stub classes if you're using any).

hth,
woodchuck


--- Plorks mail <[EMAIL PROTECTED]> wrote:

>
>
> Hi all
>
> I've developeed a web service on my local PC.
>
> I now need to deploy this to our network so it can be used.
>
> Can someone point to an example of deploying a webservice to tomcat.
> I've
> read a few articles but they don't seem to be relevant/quite complex
> to
> understand
>
> I have my deploy/undeploy/server-cofig wsdd and my wsdl - i just
> don't know
> where to put them and what to change once they are on the network e.g
> the
> endpoint in the wsdl file
>
> Also, i don't understand how the web service will see the java files.
>  It
> works on my PC i have a project with packages and java files in each
> and my
> web service can see them
>
> Sorry for my dumb questions
>
> Thanks for any help
>
> _
> It's fast, it's easy and it's free. Get MSN Messenger 7.0 today!
> http://messenger.msn.co.uk
>
>




__
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail


_
Winks & nudges are here - download MSN Messenger 7.0 today! 
http://messenger.msn.co.uk

Re: Blockers for Axis 1.2.1 Release(?)

[Andreas Bohnert]

hi,

for me http://issues.apache.org/jira/browse/AXIS-2033 is still a 
blocker. http 1.1 connections are not working with older apache proxies 
(<=1.3.33)


the issue is already marked as fixed, but unfortunately the patch 
doesn't work for me. I still stuck with axis 1.2RC3


I have added a comment to this issue together with a snippet of my 
client code.



regards,
andreas

Re: deploying web service

[Plorks mail]

hi

I keep reading about a war file - do i need to create this as well?

Thanks for your help





From: Woodchuck <[EMAIL PROTECTED]>
Reply-To: axis-user@ws.apache.org
To: axis-user@ws.apache.org
Subject: Re: deploying web service
Date: Fri, 10 Jun 2005 12:55:35 -0700 (PDT)

hihi,

the deploy/undeploy.wsdd are not needed in production.  they are used
to generate the server-config.wsdd

the server-config.wsdd goes into your webapp/WEB-INF folder (same as
your web.xml deployment descriptor file)

if you have web services working on your local machine, deploying it on
'the network' requires no change to your web service.  you should be
able to just copy your entire web service app to your network server
and have it work just the same.  only the clients who access the web
service needs to change, they need to know where the new location of
your web service is (eg. the proxy/stub classes if you're using any).

hth,
woodchuck


--- Plorks mail <[EMAIL PROTECTED]> wrote:

>
>
> Hi all
>
> I've developeed a web service on my local PC.
>
> I now need to deploy this to our network so it can be used.
>
> Can someone point to an example of deploying a webservice to tomcat.
> I've
> read a few articles but they don't seem to be relevant/quite complex
> to
> understand
>
> I have my deploy/undeploy/server-cofig wsdd and my wsdl - i just
> don't know
> where to put them and what to change once they are on the network e.g
> the
> endpoint in the wsdl file
>
> Also, i don't understand how the web service will see the java files.
>  It
> works on my PC i have a project with packages and java files in each
> and my
> web service can see them
>
> Sorry for my dumb questions
>
> Thanks for any help
>
> _
> It's fast, it's easy and it's free. Get MSN Messenger 7.0 today!
> http://messenger.msn.co.uk
>
>




__
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail


_
Use MSN Messenger to send music and pics to your friends 
http://messenger.msn.co.uk

deploying web service from remote

[Gerardo]

Hi,

I finished the implementation of my web services, and i´m trying to 
install web service in othr machine to check the services. I install 
Tomcat in the machine, import war file from tomcat. i try to deploy the 
service from my machine changing in build.xml localhost to 192.168.0.x , 
ip of remote machine.

When i execute the ant task to deploy, i received next message:

faultString:(404) Unauthorized user,

looks like i must configurate the tomcat permisses, but i don´t know 
where is this feature.



Thanks, and excuse my english.

RE: Automated server-config.wsdd generation using ant

[Amiel, Meir]

Title: RE: Automated server-config.wsdd generation using ant





I took a different approach in solving the same issue. I have a servlet that inits on server startup; it then iterates the war file, looks for all deploy.wsdd files and deploys the new services.


-Original Message-
From: Ephemeris Lappis
To: Axis-User
Sent: 6/12/2005 11:40 PM
Subject: Automated server-config.wsdd generation using ant


Hello.


Does anyone know a simple way to automate the generation of a deployable
server wsdd. Indeed, to build a deployable war, the default
server-config.wsdd must be extended with the application's services
descriptors, and, to achieve this, we have to either copy/paste the
generated services elements, or code a DOM program to add them...


I imagine a wsdl2java ant task (or command) extension could generate a
deployable server-config.wsdd instead of the simple deploy.wsdd, based,
either on the default axis one, or a task custom one, for those who need
specific handlers...


Some idea ?
Thanks...


--
Ephemeris Lappis