NullPointerException during registerConverter

[Antonio Capurso-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi to all,

I'm using XStream to convert Java bean to XML and vice-versa.

In our application, we have a class with static XStream object and a static 'loadXStream' method that create the XStream object, add alias to classes and register the custom converters for our beans. Currently we have 39 custom converters.

 

While the first invocation to out 'loadXStream' method, sometimes (not always) we have the following exception:

 

java.lang.NullPointerException
 at java.util.TreeMap.rotateRight(TreeMap.java:1278)
 at java.util.TreeMap.fixAfterInsertion(TreeMap.java:1311)
 at java.util.TreeMap.put(TreeMap.java:474)
 at java.util.TreeSet.add(TreeSet.java:210)
 at com.thoughtworks.xstream.core.util.PrioritizedList.add(PrioritizedList.java:40)
 at com.thoughtworks.xstream.core.DefaultConverterLookup.registerConverter(DefaultConverterLookup.java:69)
 at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1140)
 at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1135)
 at it.eustema.ets.utility.XStreamManager.addConverters(XStreamManager.java:178)
 at it.eustema.ets.utility.XStreamManager.loadXStream(XStreamManager.java:94)
 at it.eustema.ets.endpoint.impl.ProgettiEndpointImpl.findAllWithOrdiniContrattiClientiResponsabiliAree(ProgettiEndpointImpl.java:386)
 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:585)
 at flex.messaging.services.remoting.adapters.JavaAdapter.invoke(JavaAdapter.java:421)
 at flex.messaging.services.RemotingService.serviceMessage(RemotingService.java:183)
 at flex.messaging.MessageBroker.routeMessageToService(MessageBroker.java:1503)
 at flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:884)
 at flex.messaging.endpoints.AbstractEndpoint$$FastClassByCGLIB$$1a3ef066.invoke(<generated>)
 at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
 at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:700)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
 at org.springframework.aop.framework.adapter.ThrowsAdviceInterceptor.invoke(ThrowsAdviceInterceptor.java:126)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
 at org.springframework.aop.framework.Cglib2AopProxy$FixedChainStaticTargetInterceptor.intercept(Cglib2AopProxy.java:582)
 at flex.messaging.endpoints.AMFEndpoint$$EnhancerByCGLIB$$c5f440b6.serviceMessage(<generated>)
 at flex.messaging.endpoints.amf.MessageBrokerFilter.invoke(MessageBrokerFilter.java:121)
 at flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:158)
 at flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:44)
 at flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:67)
 at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:146)
 at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:278)
 at flex.messaging.endpoints.AMFEndpoint$$EnhancerByCGLIB$$c5f440b6.service(<generated>)
 at org.springframework.flex.messaging.servlet.MessageBrokerHandlerAdapter.handle(MessageBrokerHandlerAdapter.java:84)
 at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
 at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
 at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
 at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
 at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
 at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.SessionFixationProtectionFilter.doFilterHttp(SessionFixationProtectionFilter.java:67)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:116)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.basicauth.BasicProcessingFilter.doFilterHttp(BasicProcessingFilter.java:174)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:277)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
 at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
 at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
 at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:175)
 at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
 at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:595)

 

Anybody have a workaround for this problem?

Thanks in advance,

Best regards

Antonio Capurso.

Prima di stampare pensa all'ambiente

"Ai sensi e per effetti del T.U. sulla privacy (D.Lgs 196/03) questa mail è destinata unicamente alle persone sopra
indicate e le informazioni in essa contenute sono da considerarsi  strettamente riservate.
E' proibito leggere, copiare, usare o diffondere il contenuto della presente mail senza consenso.
Se avete ricevuto questo messaggio per errore, siete pregati di rispedire la stessa al mittente e di cancellare l'originale.
Grazie"


"This message is for the designated recipient only and may contain priviliged or confidential information.
If you have received it in error please notify the sender immediately and delete the original.
Any other use of the e-mail by you is prohibited"

[Jörg Schaible-2]

Hi Antonio,

Antonio Capurso wrote at Freitag, 2. Oktober 2009 09:57:

> Hi to all,
> I'm using XStream to convert Java bean to XML and vice-versa.
> In our application, we have a class with static XStream object and a
> static 'loadXStream' method that create the XStream object, add alias to
> classes and register the custom converters for our beans. Currently we
> have 39 custom converters.
>
> While the first invocation to out 'loadXStream' method, sometimes (not
> always) we have the following exception:
>
> java.lang.NullPointerException
>  at java.util.TreeMap.rotateRight(TreeMap.java:1278)
>  at java.util.TreeMap.fixAfterInsertion(TreeMap.java:1311)
>  at java.util.TreeMap.put(TreeMap.java:474)
>  at java.util.TreeSet.add(TreeSet.java:210)
>  at
>

com.thoughtworks.xstream.core.util.PrioritizedList.add(PrioritizedList.java:40)
>  at
>
com.thoughtworks.xstream.core.DefaultConverterLookup.registerConverter(DefaultConverterLookup.java:69)
>  at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1140)
>  at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1135)
>  at
>
it.eustema.ets.utility.XStreamManager.addConverters(XStreamManager.java:178)

[snip]
 
>
> Anybody have a workaround for this problem?

Actually I've never seen this before. Which JDK do you use (vendor/version)?
Which version of XStream. Since you mention that the instance is static:
You're aware that configuring (implies converter registration) an XStream
is not threadsafe at all?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Antonio Capurso-2]

Hi Jörg ,
thank you for your sudden answer!

I dont' think JDK version is meaningful, since that exception occurs both
with JDK 1.5 and JDK 1.6.
The version of Xstream we use is 1.3.1 (the last stable one, I suppose).

Maybe in my previous mail I wasn't accurate... though we have a static
method ('loadXStream'), the latter create every time a new insance of
XStream object. The method is like that:


public static XStream loadXStream(){



xstream = new XStream();

addAlias(xstream);

addBasicConverters(xstream);

addConverters(xstream);

return xstream;




So, I think (I hope!) we will not have concurrency problem due to
threadsafety...

Thank you,
Antonio Capurso.



----- Original Message -----
From: "Jörg Schaible" <joerg.schaible@...>
To: <user@...>
Sent: Friday, October 02, 2009 10:29 AM
Subject: [xstream-user] Re: NullPointerException during registerConverter

> Hi Antonio,
>
> Antonio Capurso wrote at Freitag, 2. Oktober 2009 09:57:
>
>> Hi to all,
>> I'm using XStream to convert Java bean to XML and vice-versa.
>> In our application, we have a class with static XStream object and a
>> static 'loadXStream' method that create the XStream object, add alias to
>> classes and register the custom converters for our beans. Currently we
>> have 39 custom converters.
>>
>> While the first invocation to out 'loadXStream' method, sometimes (not
>> always) we have the following exception:
>>
>> java.lang.NullPointerException
>>  at java.util.TreeMap.rotateRight(TreeMap.java:1278)
>>  at java.util.TreeMap.fixAfterInsertion(TreeMap.java:1311)
>>  at java.util.TreeMap.put(TreeMap.java:474)
>>  at java.util.TreeSet.add(TreeSet.java:210)
>>  at
>>
> com.thoughtworks.xstream.core.util.PrioritizedList.add(PrioritizedList.java:40)
>>  at
>>
> com.thoughtworks.xstream.core.DefaultConverterLookup.registerConverter(DefaultConverterLookup.java:69)
>>  at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1140)
>>  at com.thoughtworks.xstream.XStream.registerConverter(XStream.java:1135)
>>  at
>>
> it.eustema.ets.utility.XStreamManager.addConverters(XStreamManager.java:178)
>
> [snip]
>
>>
>> Anybody have a workaround for this problem?
>
> Actually I've never seen this before. Which JDK do you use
> (vendor/version)?
> Which version of XStream. Since you mention that the instance is static:
> You're aware that configuring (implies converter registration) an XStream
> is not threadsafe at all?
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>

Prima di stampare pensa all'ambiente

"Ai sensi e per effetti del T.U. sulla privacy (D.Lgs 196/03) questa mail � destinata unicamente alle persone sopra
indicate e le informazioni in essa contenute sono da considerarsi  strettamente riservate.
E' proibito leggere, copiare, usare o diffondere il contenuto della presente mail senza consenso.
Se avete ricevuto questo messaggio per errore, siete pregati di rispedire la stessa al mittente e di cancellare l'originale.
Grazie"


"This message is for the designated recipient only and may contain priviliged or confidential information.
If you have received it in error please notify the sender immediately and delete the original.
Any other use of the e-mail by you is prohibited"

 







---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Antonio,

Antonio Capurso wrote at Freitag, 2. Oktober 2009 10:59:

> Hi Jörg ,
> thank you for your sudden answer!
>
> I dont' think JDK version is meaningful, since that exception occurs both
> with JDK 1.5 and JDK 1.6.

I suppose you're using Sun's version - which OS?

Sometimes there are subtile differences - often with serialization,
therefore I'd always like to know what is used to run XStream. However,
this exception occurs somewhere in the depths of JDK's TreeMap indicating
that the internal tree structure of the elements is hosed. This is quite
strange and I have no idea, how this may happen. Have a look at the code of
the PrioritzedList yourself, it is not even possible to add a null value to
the TreeSet (resp. TreeMap) in use.

> The version of Xstream we use is 1.3.1 (the last stable one, I suppose).

Yes, that's the latest.

> Maybe in my previous mail I wasn't accurate... though we have a static
> method ('loadXStream'), the latter create every time a new insance of
> XStream object. The method is like that:
>
>
> public static XStream loadXStream(){
> xstream = new XStream();

Local variable or member?

> addAlias(xstream);
> addBasicConverters(xstream);
> addConverters(xstream);
> return xstream;
>
> So, I think (I hope!) we will not have concurrency problem due to
> threadsafety...

OK. While instantiating and configuring an XStream is a rather expensive
operation, you should definitely not run into concurrency problems in your
case - if you deal with a local variable.

The only reference I could find in Sun's bug DB
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4685305) seems to
indicate similar, but not directly related problems.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Antonio Capurso-2]

Hi Jörg,
finally I've solved my problem...
Indeed it was my fault, since - after a deeper insight of our code - I
realize we used a static variable that was instantiated at every call of
'loadXStream' method.
That was:
private static XStream xstream;

public static XStream loadXStream(){
xstream = new XStream();
    addAlias(xstream);
    addBasicConverters(xstream);
    addConverters(xstream);
    return xstream;}

(so that threated also threadsafety...)

I've removed the static variable 'xstream', changing the one inside
'loadXStream' method into a local variable. As result, my exception simply
fade away.

I post my changes in the case other will run into this problem.

Thank you for all Jörg, it's thanks to your answers that I managed to solve
my problem.

Best regards,

Antonio Capurso.







----- Original Message -----
From: "Jörg Schaible" <joerg.schaible@...>
To: <user@...>
Sent: Friday, October 02, 2009 11:30 AM
Subject: [xstream-user] Re: Re: NullPointerException during
registerConverter

> Hi Antonio,
>
> Antonio Capurso wrote at Freitag, 2. Oktober 2009 10:59:
>
>> Hi Jörg ,
>> thank you for your sudden answer!
>>
>> I dont' think JDK version is meaningful, since that exception occurs both
>> with JDK 1.5 and JDK 1.6.
>
> I suppose you're using Sun's version - which OS?
>
> Sometimes there are subtile differences - often with serialization,
> therefore I'd always like to know what is used to run XStream. However,
> this exception occurs somewhere in the depths of JDK's TreeMap indicating
> that the internal tree structure of the elements is hosed. This is quite
> strange and I have no idea, how this may happen. Have a look at the code
> of
> the PrioritzedList yourself, it is not even possible to add a null value
> to
> the TreeSet (resp. TreeMap) in use.
>
>> The version of Xstream we use is 1.3.1 (the last stable one, I suppose).
>
> Yes, that's the latest.
>
>> Maybe in my previous mail I wasn't accurate... though we have a static
>> method ('loadXStream'), the latter create every time a new insance of
>> XStream object. The method is like that:
>>
>>
>> public static XStream loadXStream(){
>> xstream = new XStream();
>
> Local variable or member?
>
>> addAlias(xstream);
>> addBasicConverters(xstream);
>> addConverters(xstream);
>> return xstream;
>>
>> So, I think (I hope!) we will not have concurrency problem due to
>> threadsafety...
>
> OK. While instantiating and configuring an XStream is a rather expensive
> operation, you should definitely not run into concurrency problems in your
> case - if you deal with a local variable.
>
> The only reference I could find in Sun's bug DB
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4685305) seems to
> indicate similar, but not directly related problems.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>

Prima di stampare pensa all'ambiente

"Ai sensi e per effetti del T.U. sulla privacy (D.Lgs 196/03) questa mail � destinata unicamente alle persone sopra
indicate e le informazioni in essa contenute sono da considerarsi  strettamente riservate.
E' proibito leggere, copiare, usare o diffondere il contenuto della presente mail senza consenso.
Se avete ricevuto questo messaggio per errore, siete pregati di rispedire la stessa al mittente e di cancellare l'originale.
Grazie"


"This message is for the designated recipient only and may contain priviliged or confidential information.
If you have received it in error please notify the sender immediately and delete the original.
Any other use of the e-mail by you is prohibited"

 







---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email