I just don't like the boxcarring thing in general, since it's underspecified and there
seem to be all kinds of potential problems - if you have three methods in the same
body, two of which succeed followed by a fault, what do you get back?
Although something like what you propose could work fo
This is perfectly valid schema. The construct:
...
means that the element has a type which isn't explicitly named, but is defined
inline.
Could you be a little more specific about the problem you were having?
--Glen
> -Original Message-
> From: Anukool Rege [mailto:[E
rsitze 02/05/09 11:07:30
Modified:java/src/org/apache/axis/handlers BasicHandler.java
Log:
Added method to 'optionally' set properties, i.e. defaults.
Revision ChangesPath
1.29 +25 -4 xml-axis/java/src/org/apache/axis/handlers/BasicHandler.java
Index: Basi
rsitze 02/05/09 11:13:01
Modified:java/src/org/apache/axis AxisEngine.java
Log:
New static (global) property and environment keys.
Removed NLS from enter/exit log.debug
Cleanup setting defaults.
Revision ChangesPath
1.77 +11 -17xml-axis/java/src/org/apach
rsitze 02/05/09 11:14:49
Modified:java/src/org/apache/axis FaultableHandler.java
Log:
Removed NLS from enter/exit log.debug
Logged wrapped exception as info instead of error, as per guidelines.
Revision ChangesPath
1.34 +5 -5 xml-axis/java/src/org/apache/ax
rsitze 02/05/09 11:16:19
Modified:java/src/org/apache/axis MessageContext.java
Log:
Replace string literal with string constant.
Revision ChangesPath
1.90 +1 -1 xml-axis/java/src/org/apache/axis/MessageContext.java
Index: MessageContext.java
==
> Removed NLS from enter/exit log.debug
While I am +1 to this, this isn't what has been done in the past.
Russell has argued that IBM puts all messages, even debug, in to the message
file and that Axis should too.
--
Tom Jordahl
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAI
rsitze 02/05/09 11:20:16
Modified:java/src/org/apache/axis/client AxisClient.java
Log:
Remove NLS from log.debug entry/exit.
Log wrapped exceptions as info, as per developer guidelines.
Revision ChangesPath
1.43 +3 -3 xml-axis/java/src/org/apache/axis/clie
Hi Richard!
> +/**
> + * Set a default value for the given option:
> + * if the option is not already set, then set it.
> + * if the option is already set, then do not set it.
> + *
> + * If this is called multiple times, the first with a
> non-null value
>
rsitze 02/05/09 11:25:18
Modified:java/src/org/apache/axis/handlers DebugHandler.java
SimpleAuthorizationHandler.java
MD5AttachHandler.java
SimpleAuthenticationHandler.java LogHandler.java
E
rsitze 02/05/09 11:28:57
Modified:java/src/org/apache/axis/handlers/http
HTTPActionHandler.java URLMapper.java
HTTPAuthHandler.java
java/src/org/apache/axis/transport/local LocalSender.java
LocalResp
rsitze 02/05/09 11:29:37
Modified:java/src/org/apache/axis/encoding
DeserializationContextImpl.java
Log:
Remove NLS from log.debug entry/exit, as per logging guidelines
Revision ChangesPath
1.27 +30 -15
xml-axis/java/src/org/apache/axis
rsitze 02/05/09 11:30:46
Modified:java/src/org/apache/axis/encoding/ser ArrayDeserializer.java
JAFDataHandlerDeserializerFactory.java
VectorDeserializer.java MapDeserializer.java
Log:
Remove NLS from log.debug entry/exit, as per loggi
rsitze 02/05/09 11:31:22
Modified:java/src/org/apache/axis/utils resources.properties
Log:
New NLS strings for exceptions
Revision ChangesPath
1.97 +29 -4 xml-axis/java/src/org/apache/axis/utils/resources.properties
Index: resources.properties
==
rsitze 02/05/09 11:31:58
Modified:java/src/org/apache/axis/transport/http AxisServlet.java
Log:
Replace string literal with string constant.
Revision ChangesPath
1.99 +4 -4
xml-axis/java/src/org/apache/axis/transport/http/AxisServlet.java
Index: AxisSer
rsitze 02/05/09 11:33:15
Modified:java/src/org/apache/axis/server AxisServer.java
Log:
Remove NLS from log.debug entry/exit, as per logging guidelines.
Revision ChangesPath
1.66 +28 -33xml-axis/java/src/org/apache/axis/server/AxisServer.java
Index: AxisSe
rsitze 02/05/09 11:35:11
Modified:java/src/org/apache/axis/server
DefaultAxisServerFactory.java
Log:
Cleaned up logic flow, added javadoc comments.
Remove NLS from log.debug entry/exit, as per logging guidelines.
Log ignored exceptions as (NLS enabled)
rsitze 02/05/09 11:36:35
Modified:java/src/org/apache/axis/server JNDIAxisServerFactory.java
Log:
Cleaned up logic flow, added javadoc comments.
Changed to be child of DefaultAxisServerFactory,
to insure proper 'default' behavior and reduce redundent code.
Remove NLS from
tomj02/05/09 11:38:23
Modified:java/src/org/apache/axis/wsdl/symbolTable SymbolTable.java
Log:
Once more fix the getURL function to correctly do imports.
Convert backslashes to forward slashes for URL processing.
The URL class does NOT treat them as the same for file URLs
The AXIS community had decided that what I was doing was overkill. NEW
debug messages weren't going to be NLS'ed. No-one volunteered to clean up
what had been done, though. Looks like Richard's doing it.
Russell Butek
[EMAIL PROTECTED]
Tom Jordahl <[EMAIL PROTECTED]> on 05/09/2002 01:18:55 P
Russell is wrong, at least for our current project :-)
I'm holding of on making across the board changes to log.debug, and only
touching the entry/exit.
We can open the discussion on the remaining debug messages until a later
date.
***
Richard A. Sitze
Sure.
There is a bit of code that does the following while trying to set default
values:
if (getOption == null)
setOption(defaultValue).
This appears in various combinations/sequences that in some cases resembled
spagetti.
I removed the spagetti and replaced with the method below. For examp
Does anyone (Rich?) have any real reasons why we have SerializationContext and
SerializationContextImpl? I know the JAX-RPC SerializationContext is an interface we
have to implement, but it seems to me we could just as easily (and much more
conveniently) have axis.encoding.SerializationContex
Cool by me. +1.
> -Original Message-
> From: Richard Sitze [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 09, 2002 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: Removed NLS from enter/exit log.debug
>
>
> Russell is wrong, at least for our current project :-)
> I'm holding of on making
One example is the AttributeSerializationContextImpl patch that I added to
do correct serialization of simple types into XML Schema attributes
(previously only toString() was called -which didn't work for Calendar and
Qname types for example). I'm sure there are other ways to implement this
fe
Please read and let me know if anyone has strong opinions either way.
==
The 0.9 version of JSR 101 describes a significantly different
XML <-> Java mapping for faults.
There are two different mappings. One for message parts which
reference a s
Generally, separating interfaces from implementation is a good thing.
For one, it gives us the opportunity to make this a pluggable piece in the future.
Also it establishes better boundaries between the components. Before I made these changes,
there was a lot of interactions between components
+1 on keeping separate interfaces.
***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
I
guess what I'm saying is that I don't think this is a place where there is going
to be any call for pluggability. YAGNI.
--Glen
-Original Message-From: R J Scheuerle Jr
[mailto:[EMAIL PROTECTED]]Sent: Thursday, May 09, 2002 3:40
PMTo: [EMAIL PROTECTED]Subject: Re:
Seri
But that's an extension of SerializationContextImpl, not a new implementation of
SerializationContext. So this would still work fine if the interface/impl split went
away.
I also agree there are other ways to do this, and in fact that's something I was going
to mention re: your patches at so
tomj02/05/09 13:17:57
Modified:java/test/wsdl/qualify Qualify_ServiceTestCase.java
Qualify_BindingImpl.java
Log:
Update to Qualify test cases to do more validation.
There are still some bugs in the way I check the DOM, so there is work left to do
on t
The interfaces define the methods for using the SerializationContext and DeserializationContext. I don't see how this hinders development. In fact it helps development, since it forces committers to use the interface instead of communicating via visible fields.
I don't know what YAGNI means.
YAGNI
= You Ain't Gonna Need It :)
You
can design a perfectly usable class which has public methods defining a
clean public interface without actually splitting out a full-fledged
separate Interface class. I'm -1 on using public fields, +1 on good
interface (as opposed to Interface) desi
Hi !
I am migrating our Collaxa's WebService Orchestration Server from SOAP2.2 to
Axis.
I need to plug in a different RPCProvider to take care of the SOAP calls. I
saw an
option in server-config.wsdd:
but it doesn't seem to make any difference.
Is that an outdated option that needs to be remove
You might have to take care of it from deploy.wsdd.
I had written a provider for Aixs to expose Structs to soap service. In the
deploy.wsdd
Thank you for the response. I tried to add the handler in the response flow
and it is called. But it seems that it's still handled by the provider first
and then reprocessed again by the new handler. And then I tried the provider
option and it doesn't work, no matter if I put it in deploy.wsdd or
Just some minor patches to allow you to turn on and off xsd:any -> object
deserialization. If it is turned off a dom Element will always be
constructed. Note the extensibility test case has been updated and has to
be applied together with the src fixes.
/Thomas
src.diff
Description: Binary
Title: Web service implementation with stateful EJB
I believe that I found a problem with the axis EJB provider when a stateful EJB is used as a session scope service implementation.
It seems that the EJB specification is saying that if a runtime exception occurs when calling a stateful EJB,
Hi Sam,
What's the build timeout. I've already shortened the signing stuff
quite a bit. Is this the only project that is running into this
timeout?
Ted
On Thu, 2002-05-09 at 06:51, Sam Ruby wrote:
>
> This email is autogenerated from the ou
39 matches
Mail list logo
