You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Sam.Wang" <Bi...@ge.com> on 2009/08/17 12:11:59 UTC
Exception about "*** nor any of its super class is known to this
context"
I found this issue today, but I don't understand why?
2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
handleJAXBException
Warning: javax.xml.bind.MarshalException
- with linked exception:
[javax.xml.bind.JAXBException: class com.demo.Apple nor any of its super
class is known to this context.]
Following is my demo code:
@XmlRootElement(name = "apple")
public class Apple {
private int id = -1;
private String name;
private String color;
private int size;
set...
get...
}
@XmlRootElement(name = "response")
public class CRUDResponse<T extends Object> {
private int total;
private int limit;
private int start;
private boolean success = true;
private T entity;
private List<T> entityList;
set...
get...
}
public Response getApple(String id) throws Exception {
Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
return Response.ok(new CRUDResponse<Apple>(apple)).build();
}
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25004234.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by "Sam.Wang" <Bi...@ge.com>.
Hello Sergey:
Thanks your reply and supports!
According to your method, I updated it and it works fine. So now I can use
the generic type to help me to implement a flexible and beautiful structure.
Thanks so much!
Sam
Sergey Beryozkin wrote:
>
> In the end it proved to be a rather strange Jettison bug :
>
> http://jira.codehaus.org/browse/JETTISON-82
>
> so now I have a list of about 4 bugs which I hope will eventually be fixed
> for 1.1.2
>
> Here's how you can workaround it :
>
> public class DropXSIAttributeWriter extends DelegatingXMLStreamWriter {
> public DropXSIAttributeWriter(XMLStreamWriter writer) {
> super(writer);
> }
>
> public void writeAttribute(String prefix, String uri,
> String local, String value) throws
> XMLStreamException {
> if (local.equals("type") && prefix.equals("xsi")) {
> return;
> }
> super.writeAttribute(prefix, uri, local, value);
> }
> }
>
> JSONProvider p = new JSONProvider() {
> @Override
> protected XMLStreamWriter createWriter(Object actualObject,
> Class<?> actualClass,
> Type genericType,
> String enc, OutputStream os, boolean isCollection) throws Exception {
> XMLStreamWriter writer = super.createWriter(actualObject,
> actualClass, genericType,
> enc, os,
> isCollection);
>
> return new DropXSIAttributeWriter(writer);
> }
> };
>
> and then proceed setting the provider properties as before.
>
> thanks, Sergey
>
>
> Sergey Beryozkin wrote:
>>
>> Having said that, I think the problem may be to do with the fact that
>> you've configured the provider to drop a root element but the provider
>> still 'leaks' attributes such as 'xsi:type' which belong to that root
>> element and makes them available to the underlying (Jettison) writer.
>> I'll fix it and then let you know how you can do it with the custom
>> JSONProvider as well...
>>
>> cheers, Sergey
>>
>>
>> Sergey Beryozkin wrote:
>>>
>>> Hi Sam
>>>
>>> So does it work before you set a namespaceMap ? In other words, how do
>>> you obtain JSON data given that a JSONProvider reports the problem with
>>> the missing xsi namespace ?
>>>
>>> thanks, Sergey
>>>
>>>
>>> Sam.Wang wrote:
>>>>
>>>> Hi Sergey:
>>>>
>>>> Thanks your reply!
>>>> Follow your said, I configured a namsepaceMap to JSONProvider and it
>>>> works.
>>>> But there is a little issue about Serialize Array, my mean is this
>>>> feature doesn't work. Following is my code:
>>>>
>>>> JSONProvider jp = new JSONProvider();
>>>> jp.setCollectionWrapperName("list");
>>>> jp.setSerializeAsArray(true);
>>>>
>>>> List<String> arrayKeys=new ArrayList<String>();
>>>> arrayKeys.add("entityList");
>>>> jp.setArrayKeys(arrayKeys);
>>>> jp.setDropRootElement(true);
>>>>
>>>> Map<String,String> map=new HashMap<String, String>();
>>>> map.put("http://www.w3.org/2001/XMLSchema-instance", "xsins");
>>>> jp.setNamespaceMap(map);
>>>>
>>>> List listProviders = new ArrayList();
>>>> listProviders.add(jp);
>>>> listProviders.add(new GenericExceptionMapper());
>>>>
>>>> sf.setProviders(listProviders);
>>>>
>>>> The JSonData before configuring namespace:
>>>> {"entityList":[{"color":"red","id":1,"name":"apple_1","size":1}],"limit":0,"start":0,"success":true,"total":1}
>>>>
>>>> After:
>>>> {"entityList":{"@xsins.type":"apple","color":"red","id":1,"name":"apple_1","size":1},"limit":0,"start":0,"success":true,"total":1}
>>>>
>>>> Is it a little bug? or something wrong in my code?
>>>> Thanks, Sam.
>>>>
>>>>
>>>> Sergey Beryozkin wrote:
>>>>>
>>>>> I added 'ether' there without completing the sentence... If you parse
>>>>> JSON manually on the client side then you may want to specify an empty
>>>>> prefix for "http://www.w3.org/2001/XMLSchema-instance"
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>> Hi Sam
>>>>>>
>>>>>> At the moment you need to explicitly register an
>>>>>> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with
>>>>>> a namespaceMap map property, see here for example :
>>>>>>
>>>>>> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>>>>>>
>>>>>> This map should include
>>>>>> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi"
>>>>>> as a value.
>>>>>>
>>>>>> New JSON providers such as AegisJSONProvider and
>>>>>> DataBindingJSONProvider actually do it by default - I'll update a
>>>>>> JSONProvider to do it too - it really won't harm, but in meantime
>>>>>> please do it manually...
>>>>>>
>>>>>> cheers, Sergey
>>>>>>
>>>>>>
>>>>>> Sam.Wang wrote:
>>>>>>>
>>>>>>> Hi dkulp:
>>>>>>>
>>>>>>> Thanks your reply!
>>>>>>> I was tried your method, however I get an exception when the
>>>>>>> response message be serialized in JAXRSOutInterceptor class. I debug
>>>>>>> it and find out the detailed exception info.
>>>>>>>
>>>>>>> javax.ws.rs.WebApplicationException:
>>>>>>> java.lang.IllegalStateException: Invalid JSON namespace:
>>>>>>> http://www.w3.org/2001/XMLSchema-instance
>>>>>>>
>>>>>>> I only added the annotation in CRUDResponse class, just like this:
>>>>>>>
>>>>>>> @XmlRootElement(name = "response")
>>>>>>> @XmlSeeAlso( { Apple.class })
>>>>>>> public class CRUDResponse <T extends Object> {
>>>>>>>
>>>>>>> Are there others specific reasons in my code?
>>>>>>> thanks, Sam.
>>>>>>>
>>>>>>>
>>>>>>> dkulp wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Well, the basic reason is that many of the generic types get
>>>>>>>> compiled away and
>>>>>>>> thus are not able to be discovered via reflection. In your case:
>>>>>>>>
>>>>>>>> new CRUDResponse<Apple>(apple)
>>>>>>>>
>>>>>>>> The "Apple" gets compiled away to just Object. When we create the
>>>>>>>> JAXBContext, Apple doesn't get added and thus it's now able to
>>>>>>>> write it. The
>>>>>>>> normal way around it is to add @XmlSeeAlso annotations to places
>>>>>>>> JAXB would
>>>>>>>> look. In your case, I THINK if you add an XmlSeeAlso annotation
>>>>>>>> to the
>>>>>>>> CRUDResponse that points at all the objects that it could hold, you
>>>>>>>> should be
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>>>>>>> I found this issue today, but I don't understand why?
>>>>>>>>>
>>>>>>>>> 2009-8-17 18:05:09
>>>>>>>>> org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>>>>>>> handleJAXBException
>>>>>>>>> Warning: javax.xml.bind.MarshalException
>>>>>>>>> - with linked exception:
>>>>>>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>>>>>>> super
>>>>>>>>> class is known to this context.]
>>>>>>>>>
>>>>>>>>> Following is my demo code:
>>>>>>>>>
>>>>>>>>> @XmlRootElement(name = "apple")
>>>>>>>>> public class Apple {
>>>>>>>>>
>>>>>>>>> private int id = -1;
>>>>>>>>> private String name;
>>>>>>>>> private String color;
>>>>>>>>> private int size;
>>>>>>>>>
>>>>>>>>> set...
>>>>>>>>> get...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @XmlRootElement(name = "response")
>>>>>>>>> public class CRUDResponse<T extends Object> {
>>>>>>>>>
>>>>>>>>> private int total;
>>>>>>>>> private int limit;
>>>>>>>>> private int start;
>>>>>>>>> private boolean success = true;
>>>>>>>>> private T entity;
>>>>>>>>> private List<T> entityList;
>>>>>>>>>
>>>>>>>>> set...
>>>>>>>>> get...
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public Response getApple(String id) throws Exception {
>>>>>>>>> Apple apple = new
>>>>>>>>> AppleServiceImpl().getApple(Integer.parseInt(id));
>>>>>>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>>>>>>> }
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel Kulp
>>>>>>>> dkulp@apache.org
>>>>>>>> http://www.dankulp.com/blog
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25110268.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by Sergey Beryozkin <se...@iona.com>.
In the end it proved to be a rather strange Jettison bug :
http://jira.codehaus.org/browse/JETTISON-82
so now I have a list of about 4 bugs which I hope will eventually be fixed
for 1.1.2
Here's how you can workaround it :
public class DropXSIAttributeWriter extends DelegatingXMLStreamWriter {
public DropXSIAttributeWriter(XMLStreamWriter writer) {
super(writer);
}
public void writeAttribute(String prefix, String uri,
String local, String value) throws
XMLStreamException {
if (local.equals("type") && prefix.equals("xsi")) {
return;
}
super.writeAttribute(prefix, uri, local, value);
}
}
JSONProvider p = new JSONProvider() {
@Override
protected XMLStreamWriter createWriter(Object actualObject,
Class<?> actualClass,
Type genericType, String
enc, OutputStream os, boolean isCollection) throws Exception {
XMLStreamWriter writer = super.createWriter(actualObject,
actualClass, genericType,
enc, os,
isCollection);
return new DropXSIAttributeWriter(writer);
}
};
and then proceed setting the provider properties as before.
thanks, Sergey
Sergey Beryozkin wrote:
>
> Having said that, I think the problem may be to do with the fact that
> you've configured the provider to drop a root element but the provider
> still 'leaks' attributes such as 'xsi:type' which belong to that root
> element and makes them available to the underlying (Jettison) writer. I'll
> fix it and then let you know how you can do it with the custom
> JSONProvider as well...
>
> cheers, Sergey
>
>
> Sergey Beryozkin wrote:
>>
>> Hi Sam
>>
>> So does it work before you set a namespaceMap ? In other words, how do
>> you obtain JSON data given that a JSONProvider reports the problem with
>> the missing xsi namespace ?
>>
>> thanks, Sergey
>>
>>
>> Sam.Wang wrote:
>>>
>>> Hi Sergey:
>>>
>>> Thanks your reply!
>>> Follow your said, I configured a namsepaceMap to JSONProvider and it
>>> works.
>>> But there is a little issue about Serialize Array, my mean is this
>>> feature doesn't work. Following is my code:
>>>
>>> JSONProvider jp = new JSONProvider();
>>> jp.setCollectionWrapperName("list");
>>> jp.setSerializeAsArray(true);
>>>
>>> List<String> arrayKeys=new ArrayList<String>();
>>> arrayKeys.add("entityList");
>>> jp.setArrayKeys(arrayKeys);
>>> jp.setDropRootElement(true);
>>>
>>> Map<String,String> map=new HashMap<String, String>();
>>> map.put("http://www.w3.org/2001/XMLSchema-instance", "xsins");
>>> jp.setNamespaceMap(map);
>>>
>>> List listProviders = new ArrayList();
>>> listProviders.add(jp);
>>> listProviders.add(new GenericExceptionMapper());
>>>
>>> sf.setProviders(listProviders);
>>>
>>> The JSonData before configuring namespace:
>>> {"entityList":[{"color":"red","id":1,"name":"apple_1","size":1}],"limit":0,"start":0,"success":true,"total":1}
>>>
>>> After:
>>> {"entityList":{"@xsins.type":"apple","color":"red","id":1,"name":"apple_1","size":1},"limit":0,"start":0,"success":true,"total":1}
>>>
>>> Is it a little bug? or something wrong in my code?
>>> Thanks, Sam.
>>>
>>>
>>> Sergey Beryozkin wrote:
>>>>
>>>> I added 'ether' there without completing the sentence... If you parse
>>>> JSON manually on the client side then you may want to specify an empty
>>>> prefix for "http://www.w3.org/2001/XMLSchema-instance"
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>> Sergey Beryozkin wrote:
>>>>>
>>>>> Hi Sam
>>>>>
>>>>> At the moment you need to explicitly register an
>>>>> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with
>>>>> a namespaceMap map property, see here for example :
>>>>>
>>>>> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>>>>>
>>>>> This map should include
>>>>> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi"
>>>>> as a value.
>>>>>
>>>>> New JSON providers such as AegisJSONProvider and
>>>>> DataBindingJSONProvider actually do it by default - I'll update a
>>>>> JSONProvider to do it too - it really won't harm, but in meantime
>>>>> please do it manually...
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>> Sam.Wang wrote:
>>>>>>
>>>>>> Hi dkulp:
>>>>>>
>>>>>> Thanks your reply!
>>>>>> I was tried your method, however I get an exception when the response
>>>>>> message be serialized in JAXRSOutInterceptor class. I debug it and
>>>>>> find out the detailed exception info.
>>>>>>
>>>>>> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
>>>>>> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>>>>>>
>>>>>> I only added the annotation in CRUDResponse class, just like this:
>>>>>>
>>>>>> @XmlRootElement(name = "response")
>>>>>> @XmlSeeAlso( { Apple.class })
>>>>>> public class CRUDResponse <T extends Object> {
>>>>>>
>>>>>> Are there others specific reasons in my code?
>>>>>> thanks, Sam.
>>>>>>
>>>>>>
>>>>>> dkulp wrote:
>>>>>>>
>>>>>>>
>>>>>>> Well, the basic reason is that many of the generic types get
>>>>>>> compiled away and
>>>>>>> thus are not able to be discovered via reflection. In your case:
>>>>>>>
>>>>>>> new CRUDResponse<Apple>(apple)
>>>>>>>
>>>>>>> The "Apple" gets compiled away to just Object. When we create the
>>>>>>> JAXBContext, Apple doesn't get added and thus it's now able to write
>>>>>>> it. The
>>>>>>> normal way around it is to add @XmlSeeAlso annotations to places
>>>>>>> JAXB would
>>>>>>> look. In your case, I THINK if you add an XmlSeeAlso annotation to
>>>>>>> the
>>>>>>> CRUDResponse that points at all the objects that it could hold, you
>>>>>>> should be
>>>>>>> OK.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>>>>>> I found this issue today, but I don't understand why?
>>>>>>>>
>>>>>>>> 2009-8-17 18:05:09
>>>>>>>> org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>>>>>> handleJAXBException
>>>>>>>> Warning: javax.xml.bind.MarshalException
>>>>>>>> - with linked exception:
>>>>>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>>>>>> super
>>>>>>>> class is known to this context.]
>>>>>>>>
>>>>>>>> Following is my demo code:
>>>>>>>>
>>>>>>>> @XmlRootElement(name = "apple")
>>>>>>>> public class Apple {
>>>>>>>>
>>>>>>>> private int id = -1;
>>>>>>>> private String name;
>>>>>>>> private String color;
>>>>>>>> private int size;
>>>>>>>>
>>>>>>>> set...
>>>>>>>> get...
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> @XmlRootElement(name = "response")
>>>>>>>> public class CRUDResponse<T extends Object> {
>>>>>>>>
>>>>>>>> private int total;
>>>>>>>> private int limit;
>>>>>>>> private int start;
>>>>>>>> private boolean success = true;
>>>>>>>> private T entity;
>>>>>>>> private List<T> entityList;
>>>>>>>>
>>>>>>>> set...
>>>>>>>> get...
>>>>>>>> }
>>>>>>>>
>>>>>>>> public Response getApple(String id) throws Exception {
>>>>>>>> Apple apple = new
>>>>>>>> AppleServiceImpl().getApple(Integer.parseInt(id));
>>>>>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>>>>>> }
>>>>>>>
>>>>>>> --
>>>>>>> Daniel Kulp
>>>>>>> dkulp@apache.org
>>>>>>> http://www.dankulp.com/blog
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25079217.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by Sergey Beryozkin <se...@iona.com>.
Having said that, I think the problem may be to do with the fact that you've
configured the provider to drop a root element but the provider still
'leaks' attributes such as 'xsi:type' which belong to that root element and
makes them available to the underlying (Jettison) writer. I'll fix it and
then let you know how you can do it with the custom JSONProvider as well...
cheers, Sergey
Sergey Beryozkin wrote:
>
> Hi Sam
>
> So does it work before you set a namespaceMap ? In other words, how do you
> obtain JSON data given that a JSONProvider reports the problem with the
> missing xsi namespace ?
>
> thanks, Sergey
>
>
> Sam.Wang wrote:
>>
>> Hi Sergey:
>>
>> Thanks your reply!
>> Follow your said, I configured a namsepaceMap to JSONProvider and it
>> works.
>> But there is a little issue about Serialize Array, my mean is this
>> feature doesn't work. Following is my code:
>>
>> JSONProvider jp = new JSONProvider();
>> jp.setCollectionWrapperName("list");
>> jp.setSerializeAsArray(true);
>>
>> List<String> arrayKeys=new ArrayList<String>();
>> arrayKeys.add("entityList");
>> jp.setArrayKeys(arrayKeys);
>> jp.setDropRootElement(true);
>>
>> Map<String,String> map=new HashMap<String, String>();
>> map.put("http://www.w3.org/2001/XMLSchema-instance", "xsins");
>> jp.setNamespaceMap(map);
>>
>> List listProviders = new ArrayList();
>> listProviders.add(jp);
>> listProviders.add(new GenericExceptionMapper());
>>
>> sf.setProviders(listProviders);
>>
>> The JSonData before configuring namespace:
>> {"entityList":[{"color":"red","id":1,"name":"apple_1","size":1}],"limit":0,"start":0,"success":true,"total":1}
>>
>> After:
>> {"entityList":{"@xsins.type":"apple","color":"red","id":1,"name":"apple_1","size":1},"limit":0,"start":0,"success":true,"total":1}
>>
>> Is it a little bug? or something wrong in my code?
>> Thanks, Sam.
>>
>>
>> Sergey Beryozkin wrote:
>>>
>>> I added 'ether' there without completing the sentence... If you parse
>>> JSON manually on the client side then you may want to specify an empty
>>> prefix for "http://www.w3.org/2001/XMLSchema-instance"
>>>
>>> cheers, Sergey
>>>
>>>
>>> Sergey Beryozkin wrote:
>>>>
>>>> Hi Sam
>>>>
>>>> At the moment you need to explicitly register an
>>>> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with a
>>>> namespaceMap map property, see here for example :
>>>>
>>>> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>>>>
>>>> This map should include
>>>> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi"
>>>> as a value.
>>>>
>>>> New JSON providers such as AegisJSONProvider and
>>>> DataBindingJSONProvider actually do it by default - I'll update a
>>>> JSONProvider to do it too - it really won't harm, but in meantime
>>>> please do it manually...
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>> Sam.Wang wrote:
>>>>>
>>>>> Hi dkulp:
>>>>>
>>>>> Thanks your reply!
>>>>> I was tried your method, however I get an exception when the response
>>>>> message be serialized in JAXRSOutInterceptor class. I debug it and
>>>>> find out the detailed exception info.
>>>>>
>>>>> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
>>>>> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>>>>>
>>>>> I only added the annotation in CRUDResponse class, just like this:
>>>>>
>>>>> @XmlRootElement(name = "response")
>>>>> @XmlSeeAlso( { Apple.class })
>>>>> public class CRUDResponse <T extends Object> {
>>>>>
>>>>> Are there others specific reasons in my code?
>>>>> thanks, Sam.
>>>>>
>>>>>
>>>>> dkulp wrote:
>>>>>>
>>>>>>
>>>>>> Well, the basic reason is that many of the generic types get compiled
>>>>>> away and
>>>>>> thus are not able to be discovered via reflection. In your case:
>>>>>>
>>>>>> new CRUDResponse<Apple>(apple)
>>>>>>
>>>>>> The "Apple" gets compiled away to just Object. When we create the
>>>>>> JAXBContext, Apple doesn't get added and thus it's now able to write
>>>>>> it. The
>>>>>> normal way around it is to add @XmlSeeAlso annotations to places JAXB
>>>>>> would
>>>>>> look. In your case, I THINK if you add an XmlSeeAlso annotation to
>>>>>> the
>>>>>> CRUDResponse that points at all the objects that it could hold, you
>>>>>> should be
>>>>>> OK.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>>>>> I found this issue today, but I don't understand why?
>>>>>>>
>>>>>>> 2009-8-17 18:05:09
>>>>>>> org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>>>>> handleJAXBException
>>>>>>> Warning: javax.xml.bind.MarshalException
>>>>>>> - with linked exception:
>>>>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>>>>> super
>>>>>>> class is known to this context.]
>>>>>>>
>>>>>>> Following is my demo code:
>>>>>>>
>>>>>>> @XmlRootElement(name = "apple")
>>>>>>> public class Apple {
>>>>>>>
>>>>>>> private int id = -1;
>>>>>>> private String name;
>>>>>>> private String color;
>>>>>>> private int size;
>>>>>>>
>>>>>>> set...
>>>>>>> get...
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> @XmlRootElement(name = "response")
>>>>>>> public class CRUDResponse<T extends Object> {
>>>>>>>
>>>>>>> private int total;
>>>>>>> private int limit;
>>>>>>> private int start;
>>>>>>> private boolean success = true;
>>>>>>> private T entity;
>>>>>>> private List<T> entityList;
>>>>>>>
>>>>>>> set...
>>>>>>> get...
>>>>>>> }
>>>>>>>
>>>>>>> public Response getApple(String id) throws Exception {
>>>>>>> Apple apple = new
>>>>>>> AppleServiceImpl().getApple(Integer.parseInt(id));
>>>>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>>>>> }
>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org
>>>>>> http://www.dankulp.com/blog
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25076904.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Sam
So does it work before you set a namespaceMap ? In other words, how do you
obtain JSON data given that a JSONProvider reports the problem with the
missing xsi namespace ?
thanks, Sergey
Sam.Wang wrote:
>
> Hi Sergey:
>
> Thanks your reply!
> Follow your said, I configured a namsepaceMap to JSONProvider and it
> works.
> But there is a little issue about Serialize Array, my mean is this feature
> doesn't work. Following is my code:
>
> JSONProvider jp = new JSONProvider();
> jp.setCollectionWrapperName("list");
> jp.setSerializeAsArray(true);
>
> List<String> arrayKeys=new ArrayList<String>();
> arrayKeys.add("entityList");
> jp.setArrayKeys(arrayKeys);
> jp.setDropRootElement(true);
>
> Map<String,String> map=new HashMap<String, String>();
> map.put("http://www.w3.org/2001/XMLSchema-instance", "xsins");
> jp.setNamespaceMap(map);
>
> List listProviders = new ArrayList();
> listProviders.add(jp);
> listProviders.add(new GenericExceptionMapper());
>
> sf.setProviders(listProviders);
>
> The JSonData before configuring namespace:
> {"entityList":[{"color":"red","id":1,"name":"apple_1","size":1}],"limit":0,"start":0,"success":true,"total":1}
>
> After:
> {"entityList":{"@xsins.type":"apple","color":"red","id":1,"name":"apple_1","size":1},"limit":0,"start":0,"success":true,"total":1}
>
> Is it a little bug? or something wrong in my code?
> Thanks, Sam.
>
>
> Sergey Beryozkin wrote:
>>
>> I added 'ether' there without completing the sentence... If you parse
>> JSON manually on the client side then you may want to specify an empty
>> prefix for "http://www.w3.org/2001/XMLSchema-instance"
>>
>> cheers, Sergey
>>
>>
>> Sergey Beryozkin wrote:
>>>
>>> Hi Sam
>>>
>>> At the moment you need to explicitly register an
>>> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with a
>>> namespaceMap map property, see here for example :
>>>
>>> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>>>
>>> This map should include
>>> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi" as
>>> a value.
>>>
>>> New JSON providers such as AegisJSONProvider and DataBindingJSONProvider
>>> actually do it by default - I'll update a JSONProvider to do it too - it
>>> really won't harm, but in meantime please do it manually...
>>>
>>> cheers, Sergey
>>>
>>>
>>> Sam.Wang wrote:
>>>>
>>>> Hi dkulp:
>>>>
>>>> Thanks your reply!
>>>> I was tried your method, however I get an exception when the response
>>>> message be serialized in JAXRSOutInterceptor class. I debug it and find
>>>> out the detailed exception info.
>>>>
>>>> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
>>>> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>>>>
>>>> I only added the annotation in CRUDResponse class, just like this:
>>>>
>>>> @XmlRootElement(name = "response")
>>>> @XmlSeeAlso( { Apple.class })
>>>> public class CRUDResponse <T extends Object> {
>>>>
>>>> Are there others specific reasons in my code?
>>>> thanks, Sam.
>>>>
>>>>
>>>> dkulp wrote:
>>>>>
>>>>>
>>>>> Well, the basic reason is that many of the generic types get compiled
>>>>> away and
>>>>> thus are not able to be discovered via reflection. In your case:
>>>>>
>>>>> new CRUDResponse<Apple>(apple)
>>>>>
>>>>> The "Apple" gets compiled away to just Object. When we create the
>>>>> JAXBContext, Apple doesn't get added and thus it's now able to write
>>>>> it. The
>>>>> normal way around it is to add @XmlSeeAlso annotations to places JAXB
>>>>> would
>>>>> look. In your case, I THINK if you add an XmlSeeAlso annotation to
>>>>> the
>>>>> CRUDResponse that points at all the objects that it could hold, you
>>>>> should be
>>>>> OK.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>>>> I found this issue today, but I don't understand why?
>>>>>>
>>>>>> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>>>> handleJAXBException
>>>>>> Warning: javax.xml.bind.MarshalException
>>>>>> - with linked exception:
>>>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>>>> super
>>>>>> class is known to this context.]
>>>>>>
>>>>>> Following is my demo code:
>>>>>>
>>>>>> @XmlRootElement(name = "apple")
>>>>>> public class Apple {
>>>>>>
>>>>>> private int id = -1;
>>>>>> private String name;
>>>>>> private String color;
>>>>>> private int size;
>>>>>>
>>>>>> set...
>>>>>> get...
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @XmlRootElement(name = "response")
>>>>>> public class CRUDResponse<T extends Object> {
>>>>>>
>>>>>> private int total;
>>>>>> private int limit;
>>>>>> private int start;
>>>>>> private boolean success = true;
>>>>>> private T entity;
>>>>>> private List<T> entityList;
>>>>>>
>>>>>> set...
>>>>>> get...
>>>>>> }
>>>>>>
>>>>>> public Response getApple(String id) throws Exception {
>>>>>> Apple apple = new
>>>>>> AppleServiceImpl().getApple(Integer.parseInt(id));
>>>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>>>> }
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org
>>>>> http://www.dankulp.com/blog
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25076635.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by "Sam.Wang" <Bi...@ge.com>.
Hi Sergey:
Thanks your reply!
Follow your said, I configured a namsepaceMap to JSONProvider and it works.
But there is a little issue about Serialize Array, this feature doesn't
work. Following is my code:
JSONProvider jp = new JSONProvider();
jp.setCollectionWrapperName("list");
jp.setSerializeAsArray(true);
List<String> arrayKeys=new ArrayList<String>();
arrayKeys.add("entityList");
jp.setArrayKeys(arrayKeys);
jp.setDropRootElement(true);
Map<String,String> map=new HashMap<String, String>();
map.put("http://www.w3.org/2001/XMLSchema-instance", "xsins");
jp.setNamespaceMap(map);
List listProviders = new ArrayList();
listProviders.add(jp);
listProviders.add(new GenericExceptionMapper());
sf.setProviders(listProviders);
The JSonData before configuring namespace:
{"entityList":[{"color":"red","id":1,"name":"apple_1","size":1}],"limit":0,"start":0,"success":true,"total":1}
After:
{"entityList":{"@xsins.type":"apple","color":"red","id":1,"name":"apple_1","size":1},"limit":0,"start":0,"success":true,"total":1}
Is it a little bug? or something wrong in my code?
Thanks, Sam.
Sergey Beryozkin wrote:
>
> I added 'ether' there without completing the sentence... If you parse JSON
> manually on the client side then you may want to specify an empty prefix
> for "http://www.w3.org/2001/XMLSchema-instance"
>
> cheers, Sergey
>
>
> Sergey Beryozkin wrote:
>>
>> Hi Sam
>>
>> At the moment you need to explicitly register an
>> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with a
>> namespaceMap map property, see here for example :
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>>
>> This map should include
>> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi" as
>> a value.
>>
>> New JSON providers such as AegisJSONProvider and DataBindingJSONProvider
>> actually do it by default - I'll update a JSONProvider to do it too - it
>> really won't harm, but in meantime please do it manually...
>>
>> cheers, Sergey
>>
>>
>> Sam.Wang wrote:
>>>
>>> Hi dkulp:
>>>
>>> Thanks your reply!
>>> I was tried your method, however I get an exception when the response
>>> message be serialized in JAXRSOutInterceptor class. I debug it and find
>>> out the detailed exception info.
>>>
>>> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
>>> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>>>
>>> I only added the annotation in CRUDResponse class, just like this:
>>>
>>> @XmlRootElement(name = "response")
>>> @XmlSeeAlso( { Apple.class })
>>> public class CRUDResponse <T extends Object> {
>>>
>>> Are there others specific reasons in my code?
>>> thanks, Sam.
>>>
>>>
>>> dkulp wrote:
>>>>
>>>>
>>>> Well, the basic reason is that many of the generic types get compiled
>>>> away and
>>>> thus are not able to be discovered via reflection. In your case:
>>>>
>>>> new CRUDResponse<Apple>(apple)
>>>>
>>>> The "Apple" gets compiled away to just Object. When we create the
>>>> JAXBContext, Apple doesn't get added and thus it's now able to write
>>>> it. The
>>>> normal way around it is to add @XmlSeeAlso annotations to places JAXB
>>>> would
>>>> look. In your case, I THINK if you add an XmlSeeAlso annotation to
>>>> the
>>>> CRUDResponse that points at all the objects that it could hold, you
>>>> should be
>>>> OK.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>>> I found this issue today, but I don't understand why?
>>>>>
>>>>> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>>> handleJAXBException
>>>>> Warning: javax.xml.bind.MarshalException
>>>>> - with linked exception:
>>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>>> super
>>>>> class is known to this context.]
>>>>>
>>>>> Following is my demo code:
>>>>>
>>>>> @XmlRootElement(name = "apple")
>>>>> public class Apple {
>>>>>
>>>>> private int id = -1;
>>>>> private String name;
>>>>> private String color;
>>>>> private int size;
>>>>>
>>>>> set...
>>>>> get...
>>>>> }
>>>>>
>>>>>
>>>>> @XmlRootElement(name = "response")
>>>>> public class CRUDResponse<T extends Object> {
>>>>>
>>>>> private int total;
>>>>> private int limit;
>>>>> private int start;
>>>>> private boolean success = true;
>>>>> private T entity;
>>>>> private List<T> entityList;
>>>>>
>>>>> set...
>>>>> get...
>>>>> }
>>>>>
>>>>> public Response getApple(String id) throws Exception {
>>>>> Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
>>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>>> }
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://www.dankulp.com/blog
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25073001.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by Sergey Beryozkin <se...@iona.com>.
I added 'ether' there without completing the sentence... If you parse JSON
manually on the client side then you may want to specify an empty prefix for
"http://www.w3.org/2001/XMLSchema-instance"
cheers, Sergey
Sergey Beryozkin wrote:
>
> Hi Sam
>
> At the moment you need to explicitly register an
> org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with a
> namespaceMap map property, see here for example :
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
>
> This map should include
> "http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi" as a
> value.
>
> New JSON providers such as AegisJSONProvider and DataBindingJSONProvider
> actually do it by default - I'll update a JSONProvider to do it too - it
> really won't harm, but in meantime please do it manually...
>
> cheers, Sergey
>
>
> Sam.Wang wrote:
>>
>> Hi dkulp:
>>
>> Thanks your reply!
>> I was tried your method, however I get an exception when the response
>> message be serialized in JAXRSOutInterceptor class. I debug it and find
>> out the detailed exception info.
>>
>> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
>> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>>
>> I only added the annotation in CRUDResponse class, just like this:
>>
>> @XmlRootElement(name = "response")
>> @XmlSeeAlso( { Apple.class })
>> public class CRUDResponse <T extends Object> {
>>
>> Are there others specific reasons in my code?
>> thanks, Sam.
>>
>>
>> dkulp wrote:
>>>
>>>
>>> Well, the basic reason is that many of the generic types get compiled
>>> away and
>>> thus are not able to be discovered via reflection. In your case:
>>>
>>> new CRUDResponse<Apple>(apple)
>>>
>>> The "Apple" gets compiled away to just Object. When we create the
>>> JAXBContext, Apple doesn't get added and thus it's now able to write it.
>>> The
>>> normal way around it is to add @XmlSeeAlso annotations to places JAXB
>>> would
>>> look. In your case, I THINK if you add an XmlSeeAlso annotation to the
>>> CRUDResponse that points at all the objects that it could hold, you
>>> should be
>>> OK.
>>>
>>> Dan
>>>
>>>
>>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>>> I found this issue today, but I don't understand why?
>>>>
>>>> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>>> handleJAXBException
>>>> Warning: javax.xml.bind.MarshalException
>>>> - with linked exception:
>>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its
>>>> super
>>>> class is known to this context.]
>>>>
>>>> Following is my demo code:
>>>>
>>>> @XmlRootElement(name = "apple")
>>>> public class Apple {
>>>>
>>>> private int id = -1;
>>>> private String name;
>>>> private String color;
>>>> private int size;
>>>>
>>>> set...
>>>> get...
>>>> }
>>>>
>>>>
>>>> @XmlRootElement(name = "response")
>>>> public class CRUDResponse<T extends Object> {
>>>>
>>>> private int total;
>>>> private int limit;
>>>> private int start;
>>>> private boolean success = true;
>>>> private T entity;
>>>> private List<T> entityList;
>>>>
>>>> set...
>>>> get...
>>>> }
>>>>
>>>> public Response getApple(String id) throws Exception {
>>>> Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
>>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>>> }
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25062305.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Sam
At the moment you need to explicitly register an
org.apache.cxf.jaxrs.provider.JSONProvider bean and configure it with a
namespaceMap map property, see here for example :
http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs/WEB-INF/beans.xml
This map should include
"http://www.w3.org/2001/XMLSchema-instance" as a key and either "xsi" as a
value.
New JSON providers such as AegisJSONProvider and DataBindingJSONProvider
actually do it by default - I'll update a JSONProvider to do it too - it
really won't harm, but in meantime please do it manually...
cheers, Sergey
Sam.Wang wrote:
>
> Hi dkulp:
>
> Thanks your reply!
> I was tried your method, however I get an exception when the response
> message be serialized in JAXRSOutInterceptor class. I debug it and find
> out the detailed exception info.
>
> javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
> Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
>
> I only added the annotation in CRUDResponse class, just like this:
>
> @XmlRootElement(name = "response")
> @XmlSeeAlso( { Apple.class })
> public class CRUDResponse <T extends Object> {
>
> Are there others specific reasons in my code?
> thanks, Sam.
>
>
> dkulp wrote:
>>
>>
>> Well, the basic reason is that many of the generic types get compiled
>> away and
>> thus are not able to be discovered via reflection. In your case:
>>
>> new CRUDResponse<Apple>(apple)
>>
>> The "Apple" gets compiled away to just Object. When we create the
>> JAXBContext, Apple doesn't get added and thus it's now able to write it.
>> The
>> normal way around it is to add @XmlSeeAlso annotations to places JAXB
>> would
>> look. In your case, I THINK if you add an XmlSeeAlso annotation to the
>> CRUDResponse that points at all the objects that it could hold, you
>> should be
>> OK.
>>
>> Dan
>>
>>
>> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>>> I found this issue today, but I don't understand why?
>>>
>>> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>>> handleJAXBException
>>> Warning: javax.xml.bind.MarshalException
>>> - with linked exception:
>>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its super
>>> class is known to this context.]
>>>
>>> Following is my demo code:
>>>
>>> @XmlRootElement(name = "apple")
>>> public class Apple {
>>>
>>> private int id = -1;
>>> private String name;
>>> private String color;
>>> private int size;
>>>
>>> set...
>>> get...
>>> }
>>>
>>>
>>> @XmlRootElement(name = "response")
>>> public class CRUDResponse<T extends Object> {
>>>
>>> private int total;
>>> private int limit;
>>> private int start;
>>> private boolean success = true;
>>> private T entity;
>>> private List<T> entityList;
>>>
>>> set...
>>> get...
>>> }
>>>
>>> public Response getApple(String id) throws Exception {
>>> Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
>>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>>> }
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25062261.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to
this context"
Posted by "Sam.Wang" <Bi...@ge.com>.
Hi dkulp:
Thanks your reply!
I was tried your method, however I get an exception when the response
message be serialized in JAXRSOutInterceptor class. I debug it and find out
the detailed exception info.
javax.ws.rs.WebApplicationException: java.lang.IllegalStateException:
Invalid JSON namespace: http://www.w3.org/2001/XMLSchema-instance
I only added the annotation in CRUDResponse class, just like this:
@XmlRootElement(name = "response")
@XmlSeeAlso( { Apple.class })
public class CRUDResponse <T extends Object> {
Are there others specific reasons in my code?
thanks, Sam.
dkulp wrote:
>
>
> Well, the basic reason is that many of the generic types get compiled away
> and
> thus are not able to be discovered via reflection. In your case:
>
> new CRUDResponse<Apple>(apple)
>
> The "Apple" gets compiled away to just Object. When we create the
> JAXBContext, Apple doesn't get added and thus it's now able to write it.
> The
> normal way around it is to add @XmlSeeAlso annotations to places JAXB
> would
> look. In your case, I THINK if you add an XmlSeeAlso annotation to the
> CRUDResponse that points at all the objects that it could hold, you should
> be
> OK.
>
> Dan
>
>
> On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
>> I found this issue today, but I don't understand why?
>>
>> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
>> handleJAXBException
>> Warning: javax.xml.bind.MarshalException
>> - with linked exception:
>> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its super
>> class is known to this context.]
>>
>> Following is my demo code:
>>
>> @XmlRootElement(name = "apple")
>> public class Apple {
>>
>> private int id = -1;
>> private String name;
>> private String color;
>> private int size;
>>
>> set...
>> get...
>> }
>>
>>
>> @XmlRootElement(name = "response")
>> public class CRUDResponse<T extends Object> {
>>
>> private int total;
>> private int limit;
>> private int start;
>> private boolean success = true;
>> private T entity;
>> private List<T> entityList;
>>
>> set...
>> get...
>> }
>>
>> public Response getApple(String id) throws Exception {
>> Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
>> return Response.ok(new CRUDResponse<Apple>(apple)).build();
>> }
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Exception-about-%22***-nor-any-of-its-super-class-is-known-to-this-context%22-tp25004234p25054812.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Exception about "*** nor any of its super class is known to this context"
Posted by Daniel Kulp <dk...@apache.org>.
Well, the basic reason is that many of the generic types get compiled away and
thus are not able to be discovered via reflection. In your case:
new CRUDResponse<Apple>(apple)
The "Apple" gets compiled away to just Object. When we create the
JAXBContext, Apple doesn't get added and thus it's now able to write it. The
normal way around it is to add @XmlSeeAlso annotations to places JAXB would
look. In your case, I THINK if you add an XmlSeeAlso annotation to the
CRUDResponse that points at all the objects that it could hold, you should be
OK.
Dan
On Mon August 17 2009 6:11:59 am Sam.Wang wrote:
> I found this issue today, but I don't understand why?
>
> 2009-8-17 18:05:09 org.apache.cxf.jaxrs.provider.AbstractJAXBProvider
> handleJAXBException
> Warning: javax.xml.bind.MarshalException
> - with linked exception:
> [javax.xml.bind.JAXBException: class com.demo.Apple nor any of its super
> class is known to this context.]
>
> Following is my demo code:
>
> @XmlRootElement(name = "apple")
> public class Apple {
>
> private int id = -1;
> private String name;
> private String color;
> private int size;
>
> set...
> get...
> }
>
>
> @XmlRootElement(name = "response")
> public class CRUDResponse<T extends Object> {
>
> private int total;
> private int limit;
> private int start;
> private boolean success = true;
> private T entity;
> private List<T> entityList;
>
> set...
> get...
> }
>
> public Response getApple(String id) throws Exception {
> Apple apple = new AppleServiceImpl().getApple(Integer.parseInt(id));
> return Response.ok(new CRUDResponse<Apple>(apple)).build();
> }
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog