You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Ruault Gaetan <gr...@sopragroup.com> on 2010/09/16 11:01:54 UTC
objects extends with binding.ws
Hi,
I have a problem to use Objects extends with Tuscany.
This my classes organization:
public class Personne implements Serializable {
protected Set<CanalContact> setCanalContact;
}
public class CanalContact implements Serializable {
..
}
public class AdressePersonne extends CanalContact implements
Serializable {
..
}
This is my destination Service :
@Service(ClientAm.class)
public class ClientAmImpl implements ClientAm {
public EntetePersonne modifierClient(Personne personne);
}
And the associate composite :
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
name="Client"
targetNamespace="http://am.client.xxx.com/">
<component name="ClientComponent">
<implementation.java
class="com.xxx.referentiel.client.am.ClientAmImpl" />
<service name="ClientAm" >
<interface.java interface="com.xxx.referentiel.client.am.ClientAm" />
</service>
</component>
<service name="ClientAm" requires="authentication"
promote="ClientComponent/ClientAm">
<binding.ws
wsdlElement="http://am.client.xxx.com/ClientService#wsdl.service(ClientS
ervice)"/>
</service>
</composite>
then my problem :
when i call my service from another compoiste like this :
public class tes{
private ClientAm clientService;
@Reference
public void setClientService (ClientAm clientService) {
this.clientService = clientService;
}
public void method(){
Personne personne = new Personne();
personne.setSetCanalContact(new HashSet<CanalContact>());
AdressePersonne adresse = new AdressePersonne();
adresse.setEntree(adrAnonyme);
adresse.setRue(adrAnonyme);
adresse.setLieuDit("");
personne.getSetCanalContact().add(adresse);
clientService.modifierClient(personne);
}
}
In my modifierClient method, i don't receive an instance of
AdressePersonne but an CanalContact instance.
How i can solve my problem ?
thanks.
Gaetan
RE: objects extends with binding.ws
Posted by Ruault Gaetan <gr...@sopragroup.com>.
Hi,
Thanks for your answer.
I join the WSDL file and this my ClientAm interface declaration :
@Remotable
public interface ClientAm {
public Personne modifierClient(Personne personne) throws AbstractException;
}
Thanks for your help
Yours,Gaetan
-----Message d'origine-----
De : Mike Edwards [mailto:mike.edwards.inglenook@gmail.com]
Envoyé : jeudi 16 septembre 2010 12:37
À : user@tuscany.apache.org
Objet : Re: objects extends with binding.ws
Ruault Gaetan wrote:
> Hi,
>
> I have a problem to use Objects extends with Tuscany.
>
> This my classes organization:
>
>
> public class Personne implements Serializable {
> protected Set<CanalContact> setCanalContact;
> }
>
> public class CanalContact implements Serializable {
> ..
> }
> public class AdressePersonne extends CanalContact implements
> Serializable { ..
> }
>
>
> This is my destination Service :
> @Service(ClientAm.class)
> public class ClientAmImpl implements ClientAm {
> public EntetePersonne modifierClient(Personne personne); }
>
> And the associate composite :
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
> name="Client"
> targetNamespace="http://am.client.xxx.com/">
> <component name="ClientComponent">
> <implementation.java
> class="com.xxx.referentiel.client.am.ClientAmImpl" />
> <service name="ClientAm" >
> <interface.java interface="com.xxx.referentiel.client.am.ClientAm" />
> </service>
> </component>
> <service name="ClientAm" requires="authentication"
> promote="ClientComponent/ClientAm">
> <binding.ws
> wsdlElement="http://am.client.xxx.com/ClientService#wsdl.service(ClientService)"/>
> </service>
> </composite>
>
>
>
>
> then my problem :
>
> when i call my service from another compoiste like this :
>
> public class tes{
>
> private ClientAm clientService;
>
> @Reference
> public void setClientService (ClientAm clientService) {
> this.clientService = clientService;
> }
> public void method(){
> Personne personne = new Personne();
> personne.setSetCanalContact(new HashSet<CanalContact>());
> AdressePersonne adresse = new AdressePersonne();
> adresse.setEntree(adrAnonyme); adresse.setRue(adrAnonyme);
> adresse.setLieuDit(""); personne.getSetCanalContact().add(adresse);
>
> clientService.modifierClient(personne);
>
> }
> }
>
>
> In my modifierClient method, i don't receive an instance of
> AdressePersonne but an CanalContact instance.
>
> How i can solve my problem ?
>
> thanks.
> Gaetan
Gaetan,
To help further, I need to see more artifacts belonging to your application:
1) The declaration of the ClientAm interface
2) The WSDL file for the <binding.ws/> element for the "ClientAm" service
I suspect that the problem is that the service interface is *only* defined in terms of the superclass and as a result, the Web services serialization code will only serialize the fields belonging to the superclass.
To allow for the use of subclasses in the interface, you must add extra metadata in the interface definition to enable serialization of subclasses to take place, such as the JAXB @XmlSeeAlso annotation (effectively this is equivalent to tweaking the WSDL / XSD to indicate an extension point in the XML).
This is an important aspect of Service interfaces - they must be EXPLICIT about all the types they are going to use. How else would the client even be aware that a subclass is a possible response type for a given operation?
Yours, Mike.
Re: fault extends with binding.ws
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> Millies, Sebastian wrote:
>> Hello Gaetan,
>>
>>
>>
>> I asked this same question in September, and Simon Nash all explained
>> it to me.
>>
>> I attach Simon’s responses to this mail.
>>
>>
>>
>> n Sebastian
>>
>>
>>
>> *From:* Ruault Gaetan [mailto:gruault@sopragroup.com]
>> *Sent:* Tuesday, October 26, 2010 6:07 PM
>> *To:* user@tuscany.apache.org
>> *Subject:* fault extends with binding.ws
>>
>>
>>
>> Hi,
>>
>>
>>
>> I have a problem with exception inheritance
>>
>> I have two exceptions like this
>>
>>
>>
>> public AbstractException extends Exception;
>>
>> public BusinessException extends AbstractException;
>>
>>
>>
>>
>>
>> and my service like this
>>
>>
>>
>> public method(param1,param2) throws AbstractException
>>
>>
>>
>>
>>
>>
>>
>> but when my service throw an BusinessException i receive an
>> AbstractException.
>>
>>
>>
>> Could you help me for receive the good Exception Type.
>>
>>
>>
>> i join my wsdl.
>>
>>
>>
>> thank
>>
>>
>>
>>
>>
>>
>>
>> Gaëtan RUAULT
>>
>> Consultant - Business Consulting Atlantique
>>
>> Sopra group.
>>
>> 28, rue Léo Lagrange 79000 Niort
>>
>> Phone : +33 (0)5 49 77 38 20
>>
>> gruault@sopragroup.com - www.sopragroup.com
>>
>> Ce message peut contenir des informations confidentielles dont la
>> divulgation est à ce titre rigoureusement interdite en l'absence
>> d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous
>> auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur
>> et de détruire toute copie.
>>
>>
>>
>> P Pensez à l'environnement avant d'imprimer.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: Abstract exception classes and web services
>> From:
>> "Simon Nash" <na...@apache.org>
>> Date:
>> Thu, 9 Sep 2010 14:12:59 +0200
>> To:
>> <us...@tuscany.apache.org>
>>
>> To:
>> <us...@tuscany.apache.org>
>>
>>
>> I think it's important to establish general principles for these
>> interoperability cases, and then look at specific cases to see
>> how the general principles are applied.
>>
>> The general principle for SCA components communicating over the
>> Web Service binding is:
>>
>> 1. The service interface is mapped to WSDL (if not already WSDL).
>> 2. The client interface is mapped to WSDL (if not already WSDL).
>> 3. If either interface can't be mapped to WSDL, interoperability
>> isn't possible and an error should be reported.
>> 4. The SCA compatibility rules are applied to the mapped WSDL
>> interfaces. If the mapped WSDL interfaces don't pass the
>> compatibility test, interoperability isn't possible and an
>> error should be reported.
>> 5. If no errors were reported by steps 3 and 4, the client and
>> service should interoperate correctly at runtime.
>>
>> The implication here is that every Java interface and implementation
>> that passes steps 3 and 4 will also pass step 5. However this isn't
>> always the case for JAX-WS and JAXB. In some cases it's necessary to
>> add custom marshalling/unmarshalling code using the @XmlJavaTypeAdapter
>> annotation to enable the JAXB runtime to successfully marshal and
>> unmarshal certain object types. In some cases (e.g., interface types)
>> the need for such customization is detected by the Java-WSDL mapping.
>> In other cases (e.g., abstract class types), the Java-WSDL mapping
>> doesn't produce any error message, but it's still necessary to add
>> custom unmarshalling code to get things to work.
>>
>> I don't think there's anything special about using an abstract class
>> as a thrown exception rather than using an abstract class as a passed
>> or returned parameter. In all these cases the Java-WSDL mapping
>> works OK without errors, but runtime unmarshalling doesn't work
>> unless @XmlJavaTypeAdapter is used.
>>
>> If you want to be able to throw and catch any of a number of concrete
>> exception classes when using an abstract exception class on the
>> service interface, you'll need to write a JAXB custom marshalling/
>> unmarshalling adapter that stores the desired concrete class name
>> in the XML data passed across the wire for the WSDL fault and uses
>> this information on the client side to create the correct concrete
>> subclass. This is effectively what the RMI runtime is doing
>> automatically for you.
>>
>> The bottom line is that if using abstract exception classes you need
>> to write some extra marshalling/unmarshalling adapter code and you
>> need to design your abstract exception classes to hold the necessary
>> information to enable custom unmarshalling. If you do this, the same
>> business exception logic will work over both Web Services and RMI.
>>
>> Simon
>>
>> Millies, Sebastian wrote:
>> > Hello there,
>> >
>> > >
>> > in Tuscany SCA 1.6, it seems not to be possible to have a remote
>> method
>> > that declares
>> >
>> > an abstract exception class in its interface, and access that method
>> > from a remote node
>> >
>> > over a webservice binding.
>> >
>> > >
>> > For example, say CurrencyConverterException is an abstract base class
>> > for my checked
>> >
>> > exceptions, and it has UnknownCurrencyException as an immediate
>> concrete
>> > subclass.
>> >
>> > Then my service interface and implementation may look like this.
>> >
>> > >
>> > @Remotable
>> >
>> > *public* *interface* CurrencyConverter
>> >
>> > {
>> >
>> > *double* getExchangeRate( String fromCurrencyCode, String
>> > toCurrencyCode ) *throws* CurrencyConverterException;
>> >
>> > }
>> >
>> > >
>> > @Service(interfaces =
>> >
>> > { CurrencyConverter.*class* })
>> >
>> > *public* *class* CurrencyConverterImpl *implements* CurrencyConverter
>> >
>> > {
>> >
>> > >
>> > *public* *double* getExchangeRate( String fromCurrencyCode, String
>> > toCurrencyCode ) *throws* CurrencyConverterException
>> >
>> > {
>> >
>> > *if*( true )
>> >
>> > {
>> >
>> > *throw* *new* UnknownCurrencyException( "Unknown source
>> currency:
>> > " + fromCurrencyCode );
>> >
>> > }
>> >
>> > }
>> >
>> > }
>> >
>> > >
>> > The client component has a reference to the CurrencyConverter service:
>> >
>> > <sca:component name=/"ClientComponent"/>
>> >
>> > <sca:reference name=/"converter"/>
>> >
>> > <sca:binding.ws
>> uri=/"http://localhost:8080/CurrencyConverter"//>
>> >
>> > </sca:reference>
>> >
>> > </sca:component>
>> >
>> > >
>> > When running the client in its own node, calling getExchangeRate on
>> the
>> > injected CurrencyConverter reference,
>> >
>> > I will get a _java.lang.InstantiationException _in the class
>> >
>> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper
>> >
>> > >
>> > Of course, the wsdl didn’t change a bit when I changed my service
>> > implementation and made CurrencyConverterException abstract.
>> >
>> > A normal JAX-WS Java client can continue to use the JAX-WS
>> artefacts as
>> > it always did and will not encounter this InstantiationException,
>> >
>> > because it doesn’t even try to reconstruct a server side exception.
>> >
>> > >
>> > And of course, when using the webservice binding, the client should
>> not
>> > have to rely on technical
>> >
>> > implementation details of the server (after all, the whole idea is
>> they
>> > may be implemented in different technologies). So
>> >
>> > Tuscany shouldn’t try to give me the original exception, but the
>> > corresponding web fault. Which would force the client
>> >
>> > to use different exception handling code for a webservice than say for
>> > an RMI binding. The technologies are just too different
>> >
>> > to be handled in a uniform fashion.
>> >
>> > >
>> > We had this point before. I find it interesting that I keep running up
>> > against it in the context of exceptions.
>> >
>> > >
>> > -- Sebastian
>> >
>> > >
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: Abstract exception classes and web services
>> From:
>> "Simon Nash" <na...@apache.org>
>> Date:
>> Sun, 12 Sep 2010 16:38:28 +0200
>> To:
>> <us...@tuscany.apache.org>
>>
>> To:
>> <us...@tuscany.apache.org>
>>
>>
>> Simon Laws wrote:
>> > On Thu, Sep 9, 2010 at 3:35 PM, Millies, Sebastian
>> > <Se...@ids-scheer.com> wrote:
>> >> thanks for the explanation. However, when I tested this just now,
>> it didn't
>> >> work. Perhaps I misunderstood, or there's a bug in Tuscany.
>> >>
>> >> What I did was annotate the abstract exception class as follows
>> >>
>> >> @XmlJavaTypeAdapter(CurrencyConverterExceptionAdapter.class)
>> >> public abstract class CurrencyConverterException extends Exception
>> >>
>> >> and implement the adapter class in the same server-side package,
>> so it can
>> >> get imported by the client together with the exception. The
>> adapter simply
>> >> serializes the exception to and from a string in the format
>> >> "concreteClassName#message".
>> >>
>> >> On the client side I changed nothing. When I ran this code in
>> Tuscany 1.6
>> >> (calling the server from a different node to make sure the
>> ws-binding is used),
>> >> the unmarshal/marshal methods in the adapter do not even get
>> called. Is there
>> >> anything more I have to do except implement the adapter class? I'm
>> sorry if
>> >> this is a naive question, but it really sounded so simple in your
>> post.
>> >>
>> >> -- Sebastian
>> >
>> > Hi Sebastien
>> >
>> > Unfortunately I don't think the @XmlJavaTypeAdapter JAXB annotation is
>> > supported in the 1.x code base. If was added to the 2.x code base at
>> > r743192 if you want to look it up. The interface test was extended
>> > here [1]
>> >
>> > [1]
>> http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/interface-java-jaxws/src/test/java/org/apache/tuscany/sca/interfacedef/java/jaxws/TestInterface.java
>>
>>
>> >
>> > Regards
>> >
>> > Simon
>> >
>> It looks like this code change (but not the test case?) was added to the
>> Tuscany 1.x codebase under r744091. This was marked as a fix for
>> TUSCANY-2840,
>> and there were additional commits to 1.x for this JIRA under r745778 and
>> r745779. I'll do some investigation to try to find out why this
>> annotation
>> isn't working with 1.x.
>>
>> Simon
>>
> I'm looking at this 1.x problem with @XmlJavaTypeAdapter now and I will
> post an update when I have more information.
>
> Simon
>
>
>
I wrote a simple itest for @XmlJavaTypeAdapter and checked it into the 1.x
trunk under revision r1028105. This revision also contains the remaining
test code from revision r743192 that was previously only in 2.x. The runtime
code from revision r743192 to support this was added to 1.x some time ago.
The itest that I added works as expected. It passes a simple abstract class
as a method parameter across the Web Service binding using @XmlJavaTypeAdapter
to marshal the abstract class as a string. The @XmlJavaTypeAdapter annotation
is applied to the declaration of the abstract class.
Encouraged by this success, I tried extending the itest to include an abstract
exception class annotated with @XmlJavaTypeAdapter. Unfortunately this isn't
working as I expected. I'm getting an InstantiationException which suggests
that the @XmlJavaTypeAdapter annotation is being ignored. I'll continue to
investigate this.
Simon
Re: fault extends with binding.ws
Posted by Simon Nash <na...@apache.org>.
Millies, Sebastian wrote:
> Hello Gaetan,
>
>
>
> I asked this same question in September, and Simon Nash all explained it
> to me.
>
> I attach Simon’s responses to this mail.
>
>
>
> n Sebastian
>
>
>
> *From:* Ruault Gaetan [mailto:gruault@sopragroup.com]
> *Sent:* Tuesday, October 26, 2010 6:07 PM
> *To:* user@tuscany.apache.org
> *Subject:* fault extends with binding.ws
>
>
>
> Hi,
>
>
>
> I have a problem with exception inheritance
>
> I have two exceptions like this
>
>
>
> public AbstractException extends Exception;
>
> public BusinessException extends AbstractException;
>
>
>
>
>
> and my service like this
>
>
>
> public method(param1,param2) throws AbstractException
>
>
>
>
>
>
>
> but when my service throw an BusinessException i receive an
> AbstractException.
>
>
>
> Could you help me for receive the good Exception Type.
>
>
>
> i join my wsdl.
>
>
>
> thank
>
>
>
>
>
>
>
> Gaëtan RUAULT
>
> Consultant - Business Consulting Atlantique
>
> Sopra group.
>
> 28, rue Léo Lagrange 79000 Niort
>
> Phone : +33 (0)5 49 77 38 20
>
> gruault@sopragroup.com - www.sopragroup.com
>
> Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur et de détruire toute copie.
>
>
>
> P Pensez à l'environnement avant d'imprimer.
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Abstract exception classes and web services
> From:
> "Simon Nash" <na...@apache.org>
> Date:
> Thu, 9 Sep 2010 14:12:59 +0200
> To:
> <us...@tuscany.apache.org>
>
> To:
> <us...@tuscany.apache.org>
>
>
> I think it's important to establish general principles for these
> interoperability cases, and then look at specific cases to see
> how the general principles are applied.
>
> The general principle for SCA components communicating over the
> Web Service binding is:
>
> 1. The service interface is mapped to WSDL (if not already WSDL).
> 2. The client interface is mapped to WSDL (if not already WSDL).
> 3. If either interface can't be mapped to WSDL, interoperability
> isn't possible and an error should be reported.
> 4. The SCA compatibility rules are applied to the mapped WSDL
> interfaces. If the mapped WSDL interfaces don't pass the
> compatibility test, interoperability isn't possible and an
> error should be reported.
> 5. If no errors were reported by steps 3 and 4, the client and
> service should interoperate correctly at runtime.
>
> The implication here is that every Java interface and implementation
> that passes steps 3 and 4 will also pass step 5. However this isn't
> always the case for JAX-WS and JAXB. In some cases it's necessary to
> add custom marshalling/unmarshalling code using the @XmlJavaTypeAdapter
> annotation to enable the JAXB runtime to successfully marshal and
> unmarshal certain object types. In some cases (e.g., interface types)
> the need for such customization is detected by the Java-WSDL mapping.
> In other cases (e.g., abstract class types), the Java-WSDL mapping
> doesn't produce any error message, but it's still necessary to add
> custom unmarshalling code to get things to work.
>
> I don't think there's anything special about using an abstract class
> as a thrown exception rather than using an abstract class as a passed
> or returned parameter. In all these cases the Java-WSDL mapping
> works OK without errors, but runtime unmarshalling doesn't work
> unless @XmlJavaTypeAdapter is used.
>
> If you want to be able to throw and catch any of a number of concrete
> exception classes when using an abstract exception class on the
> service interface, you'll need to write a JAXB custom marshalling/
> unmarshalling adapter that stores the desired concrete class name
> in the XML data passed across the wire for the WSDL fault and uses
> this information on the client side to create the correct concrete
> subclass. This is effectively what the RMI runtime is doing
> automatically for you.
>
> The bottom line is that if using abstract exception classes you need
> to write some extra marshalling/unmarshalling adapter code and you
> need to design your abstract exception classes to hold the necessary
> information to enable custom unmarshalling. If you do this, the same
> business exception logic will work over both Web Services and RMI.
>
> Simon
>
> Millies, Sebastian wrote:
> > Hello there,
> >
> >
> >
> > in Tuscany SCA 1.6, it seems not to be possible to have a remote method
> > that declares
> >
> > an abstract exception class in its interface, and access that method
> > from a remote node
> >
> > over a webservice binding.
> >
> >
> >
> > For example, say CurrencyConverterException is an abstract base class
> > for my checked
> >
> > exceptions, and it has UnknownCurrencyException as an immediate concrete
> > subclass.
> >
> > Then my service interface and implementation may look like this.
> >
> >
> >
> > @Remotable
> >
> > *public* *interface* CurrencyConverter
> >
> > {
> >
> > *double* getExchangeRate( String fromCurrencyCode, String
> > toCurrencyCode ) *throws* CurrencyConverterException;
> >
> > }
> >
> >
> >
> > @Service(interfaces =
> >
> > { CurrencyConverter.*class* })
> >
> > *public* *class* CurrencyConverterImpl *implements* CurrencyConverter
> >
> > {
> >
> >
> >
> > *public* *double* getExchangeRate( String fromCurrencyCode, String
> > toCurrencyCode ) *throws* CurrencyConverterException
> >
> > {
> >
> > *if*( true )
> >
> > {
> >
> > *throw* *new* UnknownCurrencyException( "Unknown source currency:
> > " + fromCurrencyCode );
> >
> > }
> >
> > }
> >
> > }
> >
> >
> >
> > The client component has a reference to the CurrencyConverter service:
> >
> > <sca:component name=/"ClientComponent"/>
> >
> > <sca:reference name=/"converter"/>
> >
> > <sca:binding.ws uri=/"http://localhost:8080/CurrencyConverter"//>
> >
> > </sca:reference>
> >
> > </sca:component>
> >
> >
> >
> > When running the client in its own node, calling getExchangeRate on the
> > injected CurrencyConverter reference,
> >
> > I will get a _java.lang.InstantiationException _in the class
> > org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper
> >
> >
> >
> > Of course, the wsdl didn’t change a bit when I changed my service
> > implementation and made CurrencyConverterException abstract.
> >
> > A normal JAX-WS Java client can continue to use the JAX-WS artefacts as
> > it always did and will not encounter this InstantiationException,
> >
> > because it doesn’t even try to reconstruct a server side exception.
> >
> >
> >
> > And of course, when using the webservice binding, the client should not
> > have to rely on technical
> >
> > implementation details of the server (after all, the whole idea is they
> > may be implemented in different technologies). So
> >
> > Tuscany shouldn’t try to give me the original exception, but the
> > corresponding web fault. Which would force the client
> >
> > to use different exception handling code for a webservice than say for
> > an RMI binding. The technologies are just too different
> >
> > to be handled in a uniform fashion.
> >
> >
> >
> > We had this point before. I find it interesting that I keep running up
> > against it in the context of exceptions.
> >
> >
> >
> > -- Sebastian
> >
> >
> >
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Abstract exception classes and web services
> From:
> "Simon Nash" <na...@apache.org>
> Date:
> Sun, 12 Sep 2010 16:38:28 +0200
> To:
> <us...@tuscany.apache.org>
>
> To:
> <us...@tuscany.apache.org>
>
>
> Simon Laws wrote:
> > On Thu, Sep 9, 2010 at 3:35 PM, Millies, Sebastian
> > <Se...@ids-scheer.com> wrote:
> >> thanks for the explanation. However, when I tested this just now, it
> didn't
> >> work. Perhaps I misunderstood, or there's a bug in Tuscany.
> >>
> >> What I did was annotate the abstract exception class as follows
> >>
> >> @XmlJavaTypeAdapter(CurrencyConverterExceptionAdapter.class)
> >> public abstract class CurrencyConverterException extends Exception
> >>
> >> and implement the adapter class in the same server-side package, so
> it can
> >> get imported by the client together with the exception. The adapter
> simply
> >> serializes the exception to and from a string in the format
> >> "concreteClassName#message".
> >>
> >> On the client side I changed nothing. When I ran this code in
> Tuscany 1.6
> >> (calling the server from a different node to make sure the
> ws-binding is used),
> >> the unmarshal/marshal methods in the adapter do not even get called.
> Is there
> >> anything more I have to do except implement the adapter class? I'm
> sorry if
> >> this is a naive question, but it really sounded so simple in your post.
> >>
> >> -- Sebastian
> >
> > Hi Sebastien
> >
> > Unfortunately I don't think the @XmlJavaTypeAdapter JAXB annotation is
> > supported in the 1.x code base. If was added to the 2.x code base at
> > r743192 if you want to look it up. The interface test was extended
> > here [1]
> >
> > [1]
> http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/interface-java-jaxws/src/test/java/org/apache/tuscany/sca/interfacedef/java/jaxws/TestInterface.java
>
> >
> > Regards
> >
> > Simon
> >
> It looks like this code change (but not the test case?) was added to the
> Tuscany 1.x codebase under r744091. This was marked as a fix for
> TUSCANY-2840,
> and there were additional commits to 1.x for this JIRA under r745778 and
> r745779. I'll do some investigation to try to find out why this annotation
> isn't working with 1.x.
>
> Simon
>
I'm looking at this 1.x problem with @XmlJavaTypeAdapter now and I will
post an update when I have more information.
Simon
RE: fault extends with binding.ws
Posted by "Millies, Sebastian" <Se...@ids-scheer.com>.
Hello Gaetan,
I asked this same question in September, and Simon Nash all explained it to me.
I attach Simon’s responses to this mail.
n Sebastian
From: Ruault Gaetan [mailto:gruault@sopragroup.com]
Sent: Tuesday, October 26, 2010 6:07 PM
To: user@tuscany.apache.org
Subject: fault extends with binding.ws
Hi,
I have a problem with exception inheritance
I have two exceptions like this
public AbstractException extends Exception;
public BusinessException extends AbstractException;
and my service like this
public method(param1,param2) throws AbstractException
but when my service throw an BusinessException i receive an AbstractException.
Could you help me for receive the good Exception Type.
i join my wsdl.
thank
Gaëtan RUAULT
Consultant - Business Consulting Atlantique
Sopra group.
28, rue Léo Lagrange 79000 Niort
Phone : +33 (0)5 49 77 38 20
gruault@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur et de détruire toute copie.
P Pensez à l'environnement avant d'imprimer.
fault extends with binding.ws
Posted by Ruault Gaetan <gr...@sopragroup.com>.
Hi,
I have a problem with exception inheritance
I have two exceptions like this
public AbstractException extends Exception;
public BusinessException extends AbstractException;
and my service like this
public method(param1,param2) throws AbstractException
but when my service throw an BusinessException i receive an AbstractException.
Could you help me for receive the good Exception Type.
i join my wsdl.
thank
Gaëtan RUAULT
Consultant - Business Consulting Atlantique
Sopra group.
28, rue Léo Lagrange 79000 Niort
Phone : +33 (0)5 49 77 38 20
gruault@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur et de détruire toute copie.
P Pensez à l'environnement avant d'imprimer.
________________________________
De: Ruault Gaetan [mailto:gruault@sopragroup.com]
Date: mar. 9/21/2010 15:48
À: user@tuscany.apache.org
Objet : RE : objects extends with binding.ws
Hi,
I tried with @XmlSeeAlso and it works
Thanks
Gaëtan RUAULT
Consultant - Business Consulting Atlantique
Sopra group.
28, rue Léo Lagrange 79000 Niort
Phone : +33 (0)5 49 77 38 20
gruault@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur et de détruire toute copie.
P Pensez à l'environnement avant d'imprimer.
________________________________
De: Mike Edwards [mailto:mike.edwards.inglenook@gmail.com]
Date: jeu. 9/16/2010 12:37
À: user@tuscany.apache.org
Objet : Re: objects extends with binding.ws
Ruault Gaetan wrote:
> Hi,
>
> I have a problem to use Objects extends with Tuscany.
>
> This my classes organization:
>
>
> public class Personne implements Serializable {
> protected Set<CanalContact> setCanalContact;
> }
>
> public class CanalContact implements Serializable {
> ..
> }
> public class AdressePersonne extends CanalContact implements
> Serializable {
> ..
> }
>
>
> This is my destination Service :
> @Service(ClientAm.class)
> public class ClientAmImpl implements ClientAm {
> public EntetePersonne modifierClient(Personne personne);
> }
>
> And the associate composite :
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
> name="Client"
> targetNamespace="http://am.client.xxx.com/">
> <component name="ClientComponent">
> <implementation.java
> class="com.xxx.referentiel.client.am.ClientAmImpl" />
> <service name="ClientAm" >
> <interface.java interface="com.xxx.referentiel.client.am.ClientAm" />
> </service>
> </component>
> <service name="ClientAm" requires="authentication"
> promote="ClientComponent/ClientAm">
> <binding.ws
> wsdlElement="http://am.client.xxx.com/ClientService#wsdl.service(ClientService)"/>
> </service>
> </composite>
>
>
>
>
> then my problem :
>
> when i call my service from another compoiste like this :
>
> public class tes{
>
> private ClientAm clientService;
>
> @Reference
> public void setClientService (ClientAm clientService) {
> this.clientService = clientService;
> }
> public void method(){
> Personne personne = new Personne();
> personne.setSetCanalContact(new HashSet<CanalContact>());
> AdressePersonne adresse = new AdressePersonne();
> adresse.setEntree(adrAnonyme);
> adresse.setRue(adrAnonyme);
> adresse.setLieuDit("");
> personne.getSetCanalContact().add(adresse);
>
> clientService.modifierClient(personne);
>
> }
> }
>
>
> In my modifierClient method, i don't receive an instance of
> AdressePersonne but an CanalContact instance.
>
> How i can solve my problem ?
>
> thanks.
> Gaetan
Gaetan,
To help further, I need to see more artifacts belonging to your application:
1) The declaration of the ClientAm interface
2) The WSDL file for the <binding.ws/> element for the "ClientAm" service
I suspect that the problem is that the service interface is *only* defined in terms of the
superclass and as a result, the Web services serialization code will only serialize the fields
belonging to the superclass.
To allow for the use of subclasses in the interface, you must add extra metadata in the interface
definition to enable serialization of subclasses to take place, such as the JAXB @XmlSeeAlso
annotation (effectively this is equivalent to tweaking the WSDL / XSD to indicate an extension point
in the XML).
This is an important aspect of Service interfaces - they must be EXPLICIT about all the types they
are going to use. How else would the client even be aware that a subclass is a possible response
type for a given operation?
Yours, Mike.
RE : objects extends with binding.ws
Posted by Ruault Gaetan <gr...@sopragroup.com>.
Hi,
I tried with @XmlSeeAlso and it works
Thanks
Gaëtan RUAULT
Consultant - Business Consulting Atlantique
Sopra group.
28, rue Léo Lagrange 79000 Niort
Phone : +33 (0)5 49 77 38 20
gruault@sopragroup.com - www.sopragroup.com
Ce message peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite en l'absence d'autorisation explicite de l'émetteur. Dans l'hypothèse où vous auriez reçu par erreur ce message, merci de le renvoyer à l'émetteur et de détruire toute copie.
P Pensez à l'environnement avant d'imprimer.
________________________________
De: Mike Edwards [mailto:mike.edwards.inglenook@gmail.com]
Date: jeu. 9/16/2010 12:37
À: user@tuscany.apache.org
Objet : Re: objects extends with binding.ws
Ruault Gaetan wrote:
> Hi,
>
> I have a problem to use Objects extends with Tuscany.
>
> This my classes organization:
>
>
> public class Personne implements Serializable {
> protected Set<CanalContact> setCanalContact;
> }
>
> public class CanalContact implements Serializable {
> ..
> }
> public class AdressePersonne extends CanalContact implements
> Serializable {
> ..
> }
>
>
> This is my destination Service :
> @Service(ClientAm.class)
> public class ClientAmImpl implements ClientAm {
> public EntetePersonne modifierClient(Personne personne);
> }
>
> And the associate composite :
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
> name="Client"
> targetNamespace="http://am.client.xxx.com/">
> <component name="ClientComponent">
> <implementation.java
> class="com.xxx.referentiel.client.am.ClientAmImpl" />
> <service name="ClientAm" >
> <interface.java interface="com.xxx.referentiel.client.am.ClientAm" />
> </service>
> </component>
> <service name="ClientAm" requires="authentication"
> promote="ClientComponent/ClientAm">
> <binding.ws
> wsdlElement="http://am.client.xxx.com/ClientService#wsdl.service(ClientService)"/>
> </service>
> </composite>
>
>
>
>
> then my problem :
>
> when i call my service from another compoiste like this :
>
> public class tes{
>
> private ClientAm clientService;
>
> @Reference
> public void setClientService (ClientAm clientService) {
> this.clientService = clientService;
> }
> public void method(){
> Personne personne = new Personne();
> personne.setSetCanalContact(new HashSet<CanalContact>());
> AdressePersonne adresse = new AdressePersonne();
> adresse.setEntree(adrAnonyme);
> adresse.setRue(adrAnonyme);
> adresse.setLieuDit("");
> personne.getSetCanalContact().add(adresse);
>
> clientService.modifierClient(personne);
>
> }
> }
>
>
> In my modifierClient method, i don't receive an instance of
> AdressePersonne but an CanalContact instance.
>
> How i can solve my problem ?
>
> thanks.
> Gaetan
Gaetan,
To help further, I need to see more artifacts belonging to your application:
1) The declaration of the ClientAm interface
2) The WSDL file for the <binding.ws/> element for the "ClientAm" service
I suspect that the problem is that the service interface is *only* defined in terms of the
superclass and as a result, the Web services serialization code will only serialize the fields
belonging to the superclass.
To allow for the use of subclasses in the interface, you must add extra metadata in the interface
definition to enable serialization of subclasses to take place, such as the JAXB @XmlSeeAlso
annotation (effectively this is equivalent to tweaking the WSDL / XSD to indicate an extension point
in the XML).
This is an important aspect of Service interfaces - they must be EXPLICIT about all the types they
are going to use. How else would the client even be aware that a subclass is a possible response
type for a given operation?
Yours, Mike.
Re: objects extends with binding.ws
Posted by Mike Edwards <mi...@gmail.com>.
Ruault Gaetan wrote:
> Hi,
>
> I have a problem to use Objects extends with Tuscany.
>
> This my classes organization:
>
>
> public class Personne implements Serializable {
> protected Set<CanalContact> setCanalContact;
> }
>
> public class CanalContact implements Serializable {
> ..
> }
> public class AdressePersonne extends CanalContact implements
> Serializable {
> ..
> }
>
>
> This is my destination Service :
> @Service(ClientAm.class)
> public class ClientAmImpl implements ClientAm {
> public EntetePersonne modifierClient(Personne personne);
> }
>
> And the associate composite :
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"
> name="Client"
> targetNamespace="http://am.client.xxx.com/">
> <component name="ClientComponent">
> <implementation.java
> class="com.xxx.referentiel.client.am.ClientAmImpl" />
> <service name="ClientAm" >
> <interface.java interface="com.xxx.referentiel.client.am.ClientAm" />
> </service>
> </component>
> <service name="ClientAm" requires="authentication"
> promote="ClientComponent/ClientAm">
> <binding.ws
> wsdlElement="http://am.client.xxx.com/ClientService#wsdl.service(ClientService)"/>
> </service>
> </composite>
>
>
>
>
> then my problem :
>
> when i call my service from another compoiste like this :
>
> public class tes{
>
> private ClientAm clientService;
>
> @Reference
> public void setClientService (ClientAm clientService) {
> this.clientService = clientService;
> }
> public void method(){
> Personne personne = new Personne();
> personne.setSetCanalContact(new HashSet<CanalContact>());
> AdressePersonne adresse = new AdressePersonne();
> adresse.setEntree(adrAnonyme);
> adresse.setRue(adrAnonyme);
> adresse.setLieuDit("");
> personne.getSetCanalContact().add(adresse);
>
> clientService.modifierClient(personne);
>
> }
> }
>
>
> In my modifierClient method, i don't receive an instance of
> AdressePersonne but an CanalContact instance.
>
> How i can solve my problem ?
>
> thanks.
> Gaetan
Gaetan,
To help further, I need to see more artifacts belonging to your application:
1) The declaration of the ClientAm interface
2) The WSDL file for the <binding.ws/> element for the "ClientAm" service
I suspect that the problem is that the service interface is *only* defined in terms of the
superclass and as a result, the Web services serialization code will only serialize the fields
belonging to the superclass.
To allow for the use of subclasses in the interface, you must add extra metadata in the interface
definition to enable serialization of subclasses to take place, such as the JAXB @XmlSeeAlso
annotation (effectively this is equivalent to tweaking the WSDL / XSD to indicate an extension point
in the XML).
This is an important aspect of Service interfaces - they must be EXPLICIT about all the types they
are going to use. How else would the client even be aware that a subclass is a possible response
type for a given operation?
Yours, Mike.