Which will only work if both ends are using Java *and* you have access
to the same classes.
> -Original Message-
> From: Milind Gadre [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2003 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: Simple little trick for easing (de)serialization issues
Title: Message
Is there any way to
get axis to treat null values as the default value for an element and simply
omit it in the encoding?
If I set sendXsiTypes to false in the server WSDD file it doesn't look
at the actual type of a bean being serialized to see if it should set
xsi:type attribute. So, for example
Public class base
{
}
Public class derived extends base
{
}
Public Class bean1 {
public base getValue() { retur
They use the reflection package. If you implement BeanInfo classes you
can control precisely what gets serialized/deserialized. Look in the
java.beans package for more info.
> -Original Message-
> From: Mike DuVall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 2:38 PM
> To: [
I've had a look back through the list archives and looked for some
example in the ditribution but I can't see anything that tells me how I
deploy a service that can throw exceptions and what I should expect to
see back in the client if one of those exceptions is thrown.
1. Do I need to specify ser
Here I go again. Mea Culpa - I forgot to define the derived type in the
WSDD file.
> -Original Message-
> From: Paul Andrews [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 3:56 PM
> To: [EMAIL PROTECTED]
> Subject: Question about bean properties
>
>
I have beans whose properties are themselves beans, but I have a problem
that the bean serializer just looks at the type of the properties rather
than at the type of the properties' values - some of those values are
sub-classes of the property type.
E.g.:
Public class base {
public int ge
Doh. I was using wrapped style :-/
> -Original Message-
> From: Paul Andrews [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 03, 2003 5:45 PM
> To: [EMAIL PROTECTED]
> Subject: type information in return values?
>
>
> When a return value is a complex bean (i.e.
When a return value is a complex bean (i.e. beans within beans), is it
possible to force the xsi:type of the elements to get set. I need this
because certain attributes are defined in terms of a common super-class,
but a return value would typically set that attribute to one of the
sub-classes. Unl
How do I add bean serializers/deserializers into client-config.wsdd? Can
I use these elements outside of a element? Do I have to define
a service? Is it possible at all? Is there any reference documentation
for WSDD files?
Anyone? I can't find this information in the documentation, nor in the
examples.
> -Original Message-
> From: Paul Andrews [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 5:43 PM
> To: [EMAIL PROTECTED]
> Subject: Client side deserializer?
>
>
>
How do I install serializers and de-serializers for one of my beans in a
client?
I've had a few problems with using java2wsdl to generate wrapped style
wsdl files.
Firstly it throws an index oout of bounds error if your methods throw
any exceptions.
Secondly it has problems with overloaded methods - it only creates one
element for the method and then it bundles all the parame
ith any JVM
> version, as it depends on the bytecode format, which doesn't
> change much if ever.
>
> --
> Tom Jordahl
> Macromedia Server Development
>
> -Original Message-
> From: Paul Andrews [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 25, 200
3 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: BCEL in java2wsdl
>
>
> http://cvs.apache.org/viewcvs.cgi/xml-axis/java/src/org/apache
> /axis/utils/bytecode/
>
> --- Paul Andrews <[EMAIL PROTECTED]> wrote:
> > I remember reading somewhere that java2wsdl would us
I remember reading somewhere that java2wsdl would use debug information
from a class file if it was available to generate parameter names. It
doesn't seem to, and looking through the code I can't see anywhere that
would do it.
Is this an omission or am I just not looking hard enough :-) ?
I've noticed what I think are a few problems with the WSDL that
java2wsdl generates (I might well be wrong though, I'm fairly new to
WSDL).
- If a method is void, I get empty message definitions defined for the
return value.
- If a method takes no arguments I get an empty message definition for
th
Java2Wsdl currently requires bean classes as the arguments to method
calls on a port (it throws an exception if there isn't a default
constructor). Is this necessary? In particular, I have a bunch of
*interfaces* as arguments to these calls that are written in the
JavaBean style - obviously they do
is will be the future for enterprise messaging.
> > >
> > > HTH
> > > Mark
> > >
> > > >>> [EMAIL PROTECTED] 31.01.2003 15.03 Uhr >>>
> > > I've just read back through the archive of this mailing
> list and I
> > > notice that there was talk at the end of october of providing an
> > > asynchronous method invocation mechanism in Axis. I would be
> > > interested to hear how this is progressing.
> > >
> > > Thanks - Paul Andrews.
> > >
> > >
> > >
>
>
EE standard because of redundancy with
JMS.
> Therefore JMS+Axis will be the future for enterprise messaging.
>
> HTH
> Mark
>
> >>> [EMAIL PROTECTED] 31.01.2003 15.03 Uhr >>>
> I've just read back through the archive of this mailing list and I
> notice that there was talk at the end of october of providing an
> asynchronous method invocation mechanism in Axis. I would be
> interested to hear how this is progressing.
>
> Thanks - Paul Andrews.
>
>
>
I've just read back through the archive of this mailing list and I
notice that there was talk at the end of october of providing an
asynchronous method invocation mechanism in Axis. I would be interested
to hear how this is progressing.
Thanks - Paul Andrews.
21 matches
Mail list logo
