>>
Posted this to axis-user but as yet have had no response. So any tips from
the dev side?
>>
Hi,
I am currently looking into a way of integrating Axis into a Cocoon based
scenario. Basically this is what I want to do:
Deploy a Java class into Axis that represents the functionality provided b
+1
Russell Butek
[EMAIL PROTECTED]
Glen Daniels <[EMAIL PROTECTED]> on 02/07/2002 11:43:19 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: Caching generated WSDL
Let's say we wanted to cache the WSDL generated by the ?WSDL URLs, and als
I was under the impression that URIs could be arbitrary strings. Within
the space of URI's are URLs with specific rules (like starting with http:,
ftp:, etc) and URNs that start with urn:; but URIs can be anything. Is
that impression wrong?
Russell Butek
[EMAIL PROTECTED]
"Theodore W. Leung"
Title: Default bean mappings
This bugs me for a while already. May be there is a reason it is happening this way, but please refresh me on it.
Here is what:
By default Emitter generates type namespaces and type declarations like this:
http://model.address.myapp" ...>
http://model.address.m
I think caching should be selectable by a parameter on the service.
I can have a dynamic classloader, similar to catalina's WebAppClassLoader that would
refresh JARs when they are updated on the file system. It may be very difficult for
Axis, or for anyone really, to check all type dependencies
URIs are Uniform resource Identifiers. Hence can be ANY string. (They just
have to be Unique!)
Warm Regards,
Paramdeep
- Original Message -
From: "Russell Butek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 08, 2002 7:19 PM
Subject: Re: [PATCH] switch relative URI's
Hi Igor!
> I think caching should be selectable by a parameter on the service.
> I can have a dynamic classloader, similar to catalina's
> WebAppClassLoader that would refresh JARs when they are
> updated on the file system. It may be very difficult for
> Axis, or for anyone really, to check a
Title: Default bean mappings
I want
to understand exactly what you're after here. You're looking for
transparent end-to-end Java->WSDL->Java, right?
First
off, for services where you have an explicit mapping of a type, you should get
whatever QName you've mapped. In other words, the "mod
gdaniels02/02/08 06:45:02
Modified:java/src/org/apache/axis/handlers EchoHandler.java
Log:
Framework for static WSDL generation from the EchoHandler.
Revision ChangesPath
1.27 +43 -0 xml-axis/java/src/org/apache/axis/handlers/EchoHandler.java
Index: EchoHan
Dave,
Thanks for the note.
The current mapping is defined by Chap 20 of JSR 101, so it should not be
changed. I will add a comment to the code.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen,
I also didn't think that AxisClassLodaer was doing what it should, but rather, I was
thinking to extend it a bit. I don't care about the class cache, but I have my own
classloader that does what I need. Currently I had to go crazy with Axis and do things
like this:
ClassLoader oldL
Thanks, I'll make the change.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Dave Dunkin
+1 to the "wsldFile" parameter in the service. The WSDL2Java emitter
should automatically set this parameter.
Question 1:
Is the "wsldFile" path a remote url ?
Question 2:
I am not sure whether I think caching is a good idea for non-JWS files,
since TypeMappingRegistry can change
during process
scheu 02/02/08 07:24:23
Modified:java/src/org/apache/axis/deployment/wsdd
WSDDTypeMapping.java
java/src/org/apache/axis/utils JavaUtils.java
JavapUtils.java
Log:
Minor fixes per axis-dev and Greg Truty requests.
R
Title: Message
Glen,
I want to understand exactly what you're after
here. You're looking for transparent end-to-end Java->WSDL->Java,
right?
Pertty
much easy Java->WSDL->.NET (C#) mostly for the sake of
interop.
Right now, I think we may not even emit unmapped
types for dy
This is a long message. At the end I propose a standard SOAP header which
would eventually be supported by SOAP servers. I need some opinions on
this so that I can advance the SOAP support in the Mozilla project to
be part of the default build.
First the problem:
Browser scripts can endanger s
Dave,
If you read the JAX-RPC Appendix, there is a complete description of how XML names are
mapped to Java names. While I didn't implement 100% of the algorithm described
within, we are pretty close.
JAX-RPC says to remove punctuation characters, which is why we don't use the
isJavaIdenti
If the JSR's came up with a namespace <-> package mapping I would be
inclined to do agree with you.
You also need to worry about array mappings. What if the QName is QName
("http://model.address.myapp";, "ArrayOfAddress") ?
in such cases it should figure out to map to model.address.myApp.Address
The latest log4j has made a incompatible change from the previous release version.
There are certain people who believe Axis should build against the absolute bleeding
edge CVS code of our dependencies, which are currently log4j and wsdl4j, not against
the jar files checked in to our tree. I a
+1
--
Tom Jordahl
Macromedia
-Original Message-
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 08, 2002 12:43 AM
To: '[EMAIL PROTECTED]'
Subject: Caching generated WSDL
Let's say we wanted to cache the WSDL generated by the ?WSDL URLs, and also perhaps
provide
Tom Jordahl wrote:
>
> The latest log4j has made a incompatible change from the previous
> release version.
Have you communicated this to the log4j development team? Such changes
would eventually impact Axis users... I can tell you that the log4j team
takes backwards compatibility very seriousl
Rich,
>You also need to worry about array mappings.
Not really. In WSDL they'll be generated properly anyways, and when it gets down to
SOAP pipeline it'll resolve it, for example, to ArrayDeserializer, which in turn would
componentType = context.getTypeMapping().getClassForQName(arrayItemType)
scheu 02/02/08 08:52:12
Modified:java/src/org/apache/axis Constants.java
java/src/org/apache/axis/wsdl/fromJava Types.java
Log:
Enhanced the javaType -> qname processing in Java2WSDL
Revision ChangesPath
1.53 +43 -0 xml-axis/java/src/org/apache/
Given:
1. my earlier proposal to replace the direct Log4J dependency in AXIS with
the Jakarta Common Logging Interface (defaulting to Log4J),
2. The resounding silence (defaulting to a Yes vote), and
3. The current situation...
I'm moving forward as proposed. This should either correct the
Hi Richard:
We did discuss this a few times previously, but never got traction on actually doing
it. I for one would be fine with this, with the understanding that we lose a bit of
the dynamic configuration power in log4j once we hide it behind the Log
abstraction Your point #3 strikes
The JCLI is an interface with thin-wrapper implementations of that
interface for Log4J, Avalon Toolkit, J2EE 1.4 Logging API, a simple
(System.out) logger, and a NoOp Logger. The "category" notion is handed
straight through, so if you are using Log4J you loose only the benefits of
using the Categ
There are 2 issues:
1) what is a valid URI -- this is explained in RFC 2396 - particularly
section 3
2) Can any URI be used in a namespace declaration -- that is answered by
the link in the original message. The W3C XML Plenary has deprecated
usage of relative URI's. This affects the definition
Richard Sitze wrote:
>
> The JCLI is an interface with thin-wrapper implementations of that
> interface for Log4J, Avalon Toolkit, J2EE 1.4 Logging API, a simple
> (System.out) logger, and a NoOp Logger. The "category" notion is handed
> straight through, so if you are using Log4J you loose only
scheu 02/02/08 09:45:39
Modified:java/src/org/apache/axis/utils resources.properties
java/src/org/apache/axis/wsdl/fromJava Emitter.java
MethodRep.java
Log:
small java2wsdl change
Revision ChangesPath
1.51 +1 -1 xml-axis
I'll take this on incrementally. I'll start with one package (is anything
"stable"?) to get it up and going, then I'll run as quickly (but
incrementally :-) as I can through other AXIS packages.
***
Richard A. Sitze[EMAIL PROTECTED]
> If I recall correctly, JCLI didn't exist when we last had
> this discussion,
> and the impression (possibly incorrect) at the time was that Avalon's
> LogKit prereqed the Avalon Framework. In any case, JCLI not
> only doesn't
> prereq any outside framework, it has it as a part of it's design
rubys 02/02/08 10:24:21
Modified:java/samples/echo TestClient.java
Log:
Be more tolerant as not every implementation will preserve the same
level of granularity for dates.
Problem reported by Simon Fell (PocketSOAP)
Revision ChangesPath
1.48 +3 -3 xml-
Tom Jordahl wrote:
> The latest log4j from CVS has made a incompatible change from the previous
> release version.
Sam Ruby wrote:
> Have you communicated this to the log4j development team? Such changes
> would eventually impact Axis users... I can tell you that the log4j team
> takes backward
Hi all!
I think this is a result of the change to make Category extend Logger. All of our
code uses Category, and so using code compiled with log4j 1.2 with log4j 1.1.3 causes
some problem with Logger not being found. Sorry I can't be more detailed myself. Are
you guys aware of any problem
Log4j 1.2alpha is perfectly backward compatible with 1.1.3. It's not
maybe or perhaps. Please provide exact details about the
nature of the problem. Thank you, Ceki
At 11:40 08.02.2002 -0500, Glen Daniels wrote:
>Hi all!
>
>I think this is a result of the change to make Category extend
>Logger
Hi Tom,
Nothing that would affect backward compatibility was added or removed in the
recent past. So I can't think of anything. Could you provide more detail
about the problem
please? Thank you, Ceki
At 11:36 08.02.2002 -0500, Tom Jordahl wrote:
>Tom Jordahl wrote:
> > The latest log4j from C
On JRun 3.1, we get this when invoking Axis:
org/apache/log4j/Logger
java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at
allaire.jrun.servlet.JRunServletLoader.loadServle
Hi all,
Has anybody noticed an anonymoly occurring as follows:
I have the following 2 test classes (simplified here for brevity)
public class DataWrapper
{
private HashMap storage; //Primary object storage
private long startTime; //Used to store an arbitrary start time
private lon
This seems like a job for a new API:
call.setReturnClass(Vector.class);
This would set the return type and also automatically do any conversion necessary to
return it in the correct form. This would also make it much easier for people in that
they wouldn't have to remember the XML QName for
I agree Glen. But don't we need this support for any output parameter ?
Maybe we should move further discussion to axis-dev.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Hi,
Does anyone know the tentative release dates of Axis? When is next alpha,
beta1.. and final release?
Thanks,
Venkat
Venkat Dokiparthi
Staff Engineer
Peregrine Systems
650-903-5294(pH) 650-919-5676(fax)
mailto:[EMAIL PROTECTED]
http://www.peregrine.com
butek 02/02/08 12:48:21
Modified:java/src/org/apache/axis MessageContext.java
java/src/org/apache/axis/client Call.java Stub.java
java/src/org/apache/axis/transport/http HTTPConstants.java
java/src/org/apache/axis/wsdl/toJava JavaStubWriter
tomj02/02/08 12:48:30
Modified:java/src/org/apache/axis/wsdl/fromJava ClassRep.java
Log:
Skip over the getParameterName functions in the Skeleton class
when generating WSDL.
Revision ChangesPath
1.13 +8 -4 xml-axis/java/src/org/apache/axis/wsdl/fromJava/C
>>You also need to worry about array mappings.
>Not really. In WSDL they'll be generated properly anyways, and when it
gets down to SOAP pipeline it'll >resolve it, for example, to
ArrayDeserializer, which in turn would
>componentType = context.getTypeMapping().getClassForQName(arrayItemType);
>A
Rich,
>If the xml is set over the wire with type="soapenc:Array" then
>the array deserializer will be called. But the xml could be sent
>across the wire with type="ns:ArrayOfFoo", in which case, the runtime needs to call
>the array
>deserializer instead of the bean deserializer.
So what woul
tomj02/02/08 13:21:46
Modified:java/src/org/apache/axis/wsdl/toJava JavaStubWriter.java
Log:
Take advantage of the OPERATION_STYLE_PROPERTY and set
it to document or rpc depending on what was in the WSDL.
Note: The engine currently doesn't do anything with this info.
>>If the xml is set over the wire with type="soapenc:Array" then
>>the array deserializer will be called. But the xml could be sent
>>across the wire with type="ns:ArrayOfFoo", in which case, the runtime
needs to call the array
>>deserializer instead of the bean deserializer.
>So what would arr
Folks,
The runtime uses the information in the default TypeMapping to
get the base qname <-> java information.
The Java2WSDL emitter uses the default TypeMapping information to
get java -> qname information.
However WSDL2Java uses the routine Utils.getBaseJavaName(qname)
method to get the qnam
butek 02/02/08 14:14:12
Modified:java/samples/attachments EchoAttachment.java
java/samples/bidbuy TestClient.java v3.java
java/samples/echo TestClient.java
java/samples/misc TestClient.java
java/samples/security Client.java
Rich, you knew I would say +1!
Russell Butek
[EMAIL PROTECTED]
R J Scheuerle Jr/Austin/IBM@IBMUS on 02/08/2002 04:07:31 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: WSDL2Java Plus TypeMapping (+1 ?)
Folks,
The runtime uses the information in the default Typ
butek 02/02/08 14:25:01
Modified:java/src/org/apache/axis/transport/http AxisServlet.java
Log:
(OOPS! Missed one!)
Improve performance of Call/MessageContext properties in 3 steps:
1. (done in earlier commit) Turn the common properties into accessors while still
maki
butek 02/02/08 14:25:55
Modified:java/src/org/apache/axis/wsdl/toJava JavaStubWriter.java
Log:
Same result, slightly more efficient.
Revision ChangesPath
1.29 +2 -2
xml-axis/java/src/org/apache/axis/wsdl/toJava/JavaStubWriter.java
Index: JavaStubWriter.
Axis-dev -
I'm attempting to use the main branch log4j code to obtain
log4j.appender.SyslogAppender functionality (a file not in
log4j-core.jar), but I'm running into an interop issue with Axis.
Can the main branch versions of the two libraries to work together? If
not, is there a good fallb
Rich,
>So everything is fine if all services send arrays over with type
="soapenc:Array".
>But if a service sends over a more specific type="ns:ArrayOfFoo", then the
client
>runtime needs to know that they are arrays and not beans.
Ok, then anyway with what I wanted to fix we'll support the be
This is very much goodness.
+1
I was looking at the Sun xrpcc tool (WSDL2Java/Java2WSDL equivalent).
In order to run it, the argument is an XML config file which contains
various bits of information. One the things it has are TypeMappings.
I couldn't get it to accept any WSDL file I tried.
We
scheu 02/02/08 14:57:19
Modified:java/src/org/apache/axis/deployment/wsdd WSDDService.java
Log:
added addTypeMapping so a type mapping can be added to the service without having to
deploy it at the same time
Revision ChangesPath
1.38 +10 -1
xml-axis/java/src
gdaniels02/02/08 15:03:36
Modified:java/src/org/apache/axis/message SOAPFaultBuilder.java
java/src/org/apache/axis/encoding/ser ArrayDeserializer.java
Log:
Make sure we can pick up classes from the context's classloader
Revision ChangesPath
1.17 +
scheu 02/02/08 15:05:21
Modified:java/src/org/apache/axis/utils JavaUtils.java
Log:
Added the reverse of the getLoadableClassName called getTextClassName.
Added support in convert() to convert between Hex/byte[] which among
other things improves our interop. (for echoHexBi
scheu 02/02/08 15:14:44
Modified:java/src/org/apache/axis/encoding/ser ArrayDeserializer.java
Log:
Made changes to hopefully fix David Cole's problem reported on axis-dev.
In his case, a deserialized HashMap contained values of ArrayList instead
of the expected User[]. Cha
scheu 02/02/08 15:18:54
Modified:java/samples/echo TestClient.java
java/src/org/apache/axis/encoding
DefaultTypeMappingImpl.java Hex.java
java/src/org/apache/axis/encoding/ser HexDeserializer.java
HexDeseria
David,
I just committed a chagne to the array deserializer which may fix this
problem.
Please try it out and respond.
Thanks,
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
So we now return the specific Array type (whatever[]) by default?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 08, 2002 6:15 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: xml-axis/java/src/org/apache/axis/encoding/ser
> ArrayDeser
Glen addressed a similar issue on axis-user today.
The deserialization engine always deserializes arrays into ArrayList
objects.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Let me think about this some more. There may be a way to fix this now in
the array deserializer.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
I was writing a handler that looks at header values, and as far as i
can see SOAPHeader.getValue() always returns null. I couldn't see
anywhere where the de-serialized value of the header gets set into the
value field. I used getValueAsType() instead, which worked fine.
Cheers
Simon
www.pocketso
65 matches
Mail list logo
