You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ronald Pieterse <ro...@gmail.com> on 2008/12/01 10:26:20 UTC
Different object types in list
Hello.
In my webservice I would like to be able to accept a list of different types
of objects. So the client would send a list of different objects and the
server would then be able to see which object is which.
I understand that JAXB does not handle interfaces. Is there maybe another
way to get this working if it is at all possible?
To clearify, I imagine something like:
<object-type-one>
<prop-one>...</prop-one>
</object-type-one>
<object-type-two>
<prop-two-one>...</prop-two-one>
<prop-two-two>...</prop-two-two>
</object-type-two>
and then both objects would maybe extend or implement something. Probably a
little vague but hope you understand what I mean :-)
Greetz,
Ronald
--
View this message in context: http://www.nabble.com/Different-object-types-in-list-tp20768640p20768640.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Different object types in list
Posted by Ronald Pieterse <ro...@gmail.com>.
It's a JAX-WS (SOAP) service.
Sergey Beryozkin-3 wrote:
>
> Is it a JAXWS or JAXRS service you're referring to ?
>
> Cheers, Sergey
>
>>
>> Hello.
>>
>> In my webservice I would like to be able to accept a list of different
>> types
>> of objects. So the client would send a list of different objects and the
>> server would then be able to see which object is which.
>> I understand that JAXB does not handle interfaces. Is there maybe another
>> way to get this working if it is at all possible?
>> To clearify, I imagine something like:
>>
>> <object-type-one>
>> <prop-one>...</prop-one>
>> </object-type-one>
>> <object-type-two>
>> <prop-two-one>...</prop-two-one>
>> <prop-two-two>...</prop-two-two>
>> </object-type-two>
>>
>> and then both objects would maybe extend or implement something. Probably
>> a
>> little vague but hope you understand what I mean :-)
>>
>> Greetz,
>>
>> Ronald
>> --
>> View this message in context:
>> http://www.nabble.com/Different-object-types-in-list-tp20768640p20768640.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/Different-object-types-in-list-tp20768640p20769227.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Different object types in list
Posted by Sergey Beryozkin <se...@progress.com>.
Is it a JAXWS or JAXRS service you're referring to ?
Cheers, Sergey
>
> Hello.
>
> In my webservice I would like to be able to accept a list of different types
> of objects. So the client would send a list of different objects and the
> server would then be able to see which object is which.
> I understand that JAXB does not handle interfaces. Is there maybe another
> way to get this working if it is at all possible?
> To clearify, I imagine something like:
>
> <object-type-one>
> <prop-one>...</prop-one>
> </object-type-one>
> <object-type-two>
> <prop-two-one>...</prop-two-one>
> <prop-two-two>...</prop-two-two>
> </object-type-two>
>
> and then both objects would maybe extend or implement something. Probably a
> little vague but hope you understand what I mean :-)
>
> Greetz,
>
> Ronald
> --
> View this message in context: http://www.nabble.com/Different-object-types-in-list-tp20768640p20768640.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: Different object types in list
Posted by Ronald Pieterse <ro...@gmail.com>.
Yeah that was the first thing I tried but I keep getting ClassCastException
whenever I try to downcast an object from the list to either ObjectOne or
ObjectTwo. I now also tried to use @XmlSeeAlso in the BaseObject but that
made no difference (@XmlSeeAlso(value = { ObjectOne.class, ObjectTwo.class
}))
If I use List<Object> I also get an exception:
java.lang.ClassCastException: org.apache.xerces.dom.ElementNSImpl
Ronald
dkulp wrote:
>
> On Monday 01 December 2008 4:26:20 am Ronald Pieterse wrote:
>> In my webservice I would like to be able to accept a list of different
>> types of objects. So the client would send a list of different objects
>> and
>> the server would then be able to see which object is which.
>> I understand that JAXB does not handle interfaces. Is there maybe another
>> way to get this working if it is at all possible?
>
> JAXB doesn't really handle interfaces, but it does handle object
> heiarchies.
> If you have a "BaseObject" and ObjectOne and ObjectTwo both subclass it,
> a "List<BaseObject>" would work just fine. You may need to add some
> @XmlSeeAlso annotations to point at ObjectOne and ObjectTwo so the JAXB
> runtime will know about them, but that's relatively minor.
>
> Alternatively, you CAN just have "List" (which maps to a xsd:any) and
> use the XmlSeeAlso to point at ObjectOne and ObjectTwo and throw them in
> the
> list. JAXB can also handle that. It kind of depends on what you want
> the
> resulting schema to look like.
>
> Dan
>
>
>> To clearify, I imagine something like:
>>
>> <object-type-one>
>> <prop-one>...</prop-one>
>> </object-type-one>
>> <object-type-two>
>> <prop-two-one>...</prop-two-one>
>> <prop-two-two>...</prop-two-two>
>> </object-type-two>
>>
>> and then both objects would maybe extend or implement something. Probably
>> a
>> little vague but hope you understand what I mean :-)
>>
>> Greetz,
>>
>> Ronald
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Different-object-types-in-list-tp20768640p20789736.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Different object types in list
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 03 December 2008 8:11:25 am Ronald Pieterse wrote:
> Yeah that was the first thing I tried but I keep getting ClassCastException
> whenever I try to downcast an object from the list to either ObjectOne or
> ObjectTwo.
>
> I now also tried to use @XmlSeeAlso - had to put it in the service
> interface so they would appear in my wsdl but it makes no difference
> (@XmlSeeAlso(value = { ObjectOne.class, ObjectTwo.class })); still a
> ClassCastException.
>
> If I use List I also get an exception: java.lang.ClassCastException:
> org.apache.xerces.dom.ElementNSImpl
>
> Am I doing something wrong here?
It sounds like JAXB is not getting all the the classes somehow. You might
need to try debugging a bit and putting a breakpoint in
the "createJAXBContextAndSchemas" method of JAXBDataBinding to see what
classes are in the set.
However, if the classes are appearing in the wsdl, it looks like it's working
properly on the server side. You may want to use wireshark or something to
see the soap messages on the wire to see what they look like. They SHOULD
have appropriate xsi:type="ns:ObjectOne" attributes on the elements.
Dan
> Ronald
>
> dkulp wrote:
> > On Monday 01 December 2008 4:26:20 am Ronald Pieterse wrote:
> >> In my webservice I would like to be able to accept a list of different
> >> types of objects. So the client would send a list of different objects
> >> and
> >> the server would then be able to see which object is which.
> >> I understand that JAXB does not handle interfaces. Is there maybe
> >> another way to get this working if it is at all possible?
> >
> > JAXB doesn't really handle interfaces, but it does handle object
> > heiarchies.
> > If you have a "BaseObject" and ObjectOne and ObjectTwo both subclass it,
> > a "List<BaseObject>" would work just fine. You may need to add some
> > @XmlSeeAlso annotations to point at ObjectOne and ObjectTwo so the JAXB
> > runtime will know about them, but that's relatively minor.
> >
> > Alternatively, you CAN just have "List" (which maps to a xsd:any) and
> > use the XmlSeeAlso to point at ObjectOne and ObjectTwo and throw them in
> > the
> > list. JAXB can also handle that. It kind of depends on what you want
> > the
> > resulting schema to look like.
> >
> > Dan
> >
> >> To clearify, I imagine something like:
> >>
> >> <object-type-one>
> >> <prop-one>...</prop-one>
> >> </object-type-one>
> >> <object-type-two>
> >> <prop-two-one>...</prop-two-one>
> >> <prop-two-two>...</prop-two-two>
> >> </object-type-two>
> >>
> >> and then both objects would maybe extend or implement something.
> >> Probably a
> >> little vague but hope you understand what I mean :-)
> >>
> >> Greetz,
> >>
> >> Ronald
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Different object types in list
Posted by Ronald Pieterse <ro...@gmail.com>.
Yeah that was the first thing I tried but I keep getting ClassCastException
whenever I try to downcast an object from the list to either ObjectOne or
ObjectTwo.
I now also tried to use @XmlSeeAlso - had to put it in the service interface
so they would appear in my wsdl but it makes no difference
(@XmlSeeAlso(value = { ObjectOne.class, ObjectTwo.class })); still a
ClassCastException.
If I use List I also get an exception: java.lang.ClassCastException:
org.apache.xerces.dom.ElementNSImpl
Am I doing something wrong here?
Ronald
dkulp wrote:
>
> On Monday 01 December 2008 4:26:20 am Ronald Pieterse wrote:
>> In my webservice I would like to be able to accept a list of different
>> types of objects. So the client would send a list of different objects
>> and
>> the server would then be able to see which object is which.
>> I understand that JAXB does not handle interfaces. Is there maybe another
>> way to get this working if it is at all possible?
>
> JAXB doesn't really handle interfaces, but it does handle object
> heiarchies.
> If you have a "BaseObject" and ObjectOne and ObjectTwo both subclass it,
> a "List<BaseObject>" would work just fine. You may need to add some
> @XmlSeeAlso annotations to point at ObjectOne and ObjectTwo so the JAXB
> runtime will know about them, but that's relatively minor.
>
> Alternatively, you CAN just have "List" (which maps to a xsd:any) and
> use the XmlSeeAlso to point at ObjectOne and ObjectTwo and throw them in
> the
> list. JAXB can also handle that. It kind of depends on what you want
> the
> resulting schema to look like.
>
> Dan
>
>
>> To clearify, I imagine something like:
>>
>> <object-type-one>
>> <prop-one>...</prop-one>
>> </object-type-one>
>> <object-type-two>
>> <prop-two-one>...</prop-two-one>
>> <prop-two-two>...</prop-two-two>
>> </object-type-two>
>>
>> and then both objects would maybe extend or implement something. Probably
>> a
>> little vague but hope you understand what I mean :-)
>>
>> Greetz,
>>
>> Ronald
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Different-object-types-in-list-tp20768640p20812667.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: commons-dbcp in class path fails CXF deployment
Posted by "Petr V." <gr...@yahoo.com>.
Okay I put version 1.2.2 of commons-dbcp and it worked fine. Can't believe that it took me 2 hours to narrow down issue and 1 minute to resolve.
I debugged issue by hit and trial and removing all the code I added, how would you have done ? Is there any thing I could learn from this expereince. Experts opinion needed.
Thanks,
Petr
--- On Tue, 12/2/08, Petr V. <gr...@yahoo.com> wrote:
From: Petr V. <gr...@yahoo.com>
Subject: commons-dbcp in class path fails CXF deployment
To: users@cxf.apache.org
Date: Tuesday, December 2, 2008, 4:48 AM
I simply added dependency on commons-dbcp in my project via maven.
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.2.1</version>
</dependency>
I am not using any class from this package at all. It is just in class path via
maven
and now my CXF services could not be deployed and I get following exception.
When I access wsdl in browser, I get blank page
I had to spend couple of hours to narrow down the issue. Never imagined that
adding dependency on commans-dbcp would create an havoc. Is this some known
issue, I eventually have to use hibernate and I am using
org.apache.commons.dbcp.BasicDataSource for my data source.
I am simply using Endpoint.publish(address, service); to publish my service
The exception log is
javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException: Failed to create
service.
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:134)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65)
at javax.xml.ws.Service.<init>(Service.java:56)
at
com.mypc.jcollector.collectorwebservice.serviceimpl.DefaultCollectorService.<init>(DefaultCollectorService.java:59)
at
com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.createClient(Test_CollectorServiceContract.java:39)
at
com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.access$000(Test_CollectorServiceContract.java:20)
at
com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract$1.runDelegate(Test_CollectorServiceContract.java:77)
at
com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.runService(Test_CollectorServiceContract.java:29)
at
com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.test_getComputer(Test_CollectorServiceContract.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed
to create service.
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:83)
at
org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:140)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:132)
... 34 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR:
Problem parsing 'http://localhost:8185/CollectorService?wsdl'.:
java.io.IOException: Server returned HTTP response code: 500 for URL:
http://localhost:8185/CollectorService?wsdl
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:212)
at
org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:176)
at
org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
... 36 more
Caused by: java.io.IOException: Server returned HTTP response code: 500 for
URL: http://localhost:8185/CollectorService?wsdl
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
at java.net.URL.openStream(URL.java:1009)
at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:796)
at
org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(XMLEntityManager.java:741)
at
org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(XMLDocumentScannerImpl.java:260)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:498)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
... 42 more
commons-dbcp in class path fails CXF deployment
Posted by "Petr V." <gr...@yahoo.com>.
I simply added dependency on commons-dbcp in my project via maven.
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.2.1</version>
</dependency>
I am not using any class from this package at all. It is just in class path via maven
and now my CXF services could not be deployed and I get following exception. When I access wsdl in browser, I get blank page
I had to spend couple of hours to narrow down the issue. Never imagined that adding dependency on commans-dbcp would create an havoc. Is this some known issue, I eventually have to use hibernate and I am using org.apache.commons.dbcp.BasicDataSource for my data source.
I am simply using Endpoint.publish(address, service); to publish my service
The exception log is
javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:134)
at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.mypc.jcollector.collectorwebservice.serviceimpl.DefaultCollectorService.<init>(DefaultCollectorService.java:59)
at com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.createClient(Test_CollectorServiceContract.java:39)
at com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.access$000(Test_CollectorServiceContract.java:20)
at com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract$1.runDelegate(Test_CollectorServiceContract.java:77)
at com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.runService(Test_CollectorServiceContract.java:29)
at com.mypc.jcollector.collectorwebservice.Test_CollectorServiceContract.test_getComputer(Test_CollectorServiceContract.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:83)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:140)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:132)
... 34 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://localhost:8185/CollectorService?wsdl'.: java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8185/CollectorService?wsdl
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:212)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:176)
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:81)
... 36 more
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8185/CollectorService?wsdl
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1290)
at java.net.URL.openStream(URL.java:1009)
at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:796)
at org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(XMLEntityManager.java:741)
at org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(XMLDocumentScannerImpl.java:260)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:498)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
... 42 more
Re: Different object types in list
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 01 December 2008 4:26:20 am Ronald Pieterse wrote:
> In my webservice I would like to be able to accept a list of different
> types of objects. So the client would send a list of different objects and
> the server would then be able to see which object is which.
> I understand that JAXB does not handle interfaces. Is there maybe another
> way to get this working if it is at all possible?
JAXB doesn't really handle interfaces, but it does handle object heiarchies.
If you have a "BaseObject" and ObjectOne and ObjectTwo both subclass it,
a "List<BaseObject>" would work just fine. You may need to add some
@XmlSeeAlso annotations to point at ObjectOne and ObjectTwo so the JAXB
runtime will know about them, but that's relatively minor.
Alternatively, you CAN just have "List<Object>" (which maps to a xsd:any) and
use the XmlSeeAlso to point at ObjectOne and ObjectTwo and throw them in the
list. JAXB can also handle that. It kind of depends on what you want the
resulting schema to look like.
Dan
> To clearify, I imagine something like:
>
> <object-type-one>
> <prop-one>...</prop-one>
> </object-type-one>
> <object-type-two>
> <prop-two-one>...</prop-two-one>
> <prop-two-two>...</prop-two-two>
> </object-type-two>
>
> and then both objects would maybe extend or implement something. Probably a
> little vague but hope you understand what I mean :-)
>
> Greetz,
>
> Ronald
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog