[jira] Commented: (MUSE-142) Deserialization of properties with XStream causes NPE

["Dan Jemiolo (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/MUSE-142?page=comments#action_12447799 ] 
            
Dan Jemiolo commented on MUSE-142:
----------------------------------

>From muse-user:

I did a code comparison on my local copy and the remote copy of 
XStreamSerializer.java (first with diff, then by reading every line with 
my own two eyes). They are identical in every way. 

When I build the muse-util-xstream module using our build system, Maven 
compiles the code with JDK 1.4.2_05 and creates a JAR file from it. 
Maven's verbose mode and the manifest file in the JAR confirm that it used 
JDK 1.4.2_05. This JAR does not work - it causes the error you've all seen 
on the client side. I also notice that the line that the stack trace 
points to is line 211, which is not capable of producing an NPE (it says 
'return getSerializableType();'). Odd.

When I build the muse-util-xstream module with javac and jar - no Maven 
involved - it also does not work. Again, JDK 1.4.2_05 versions of javac 
and jar. Client fails.

HOWEVER, when I go into Eclipse and select XStreamSerializer.java, 
right-click, and select Export -> JAR file, the JAR that I get DOES work. 
It's also much smaller than the other JARs. My Eclipse project settings 
show that I am using JDK 1.4.2_05 for build tasks.

So, the XStream module, when built with Maven or manually with javac/jar, 
does not deserialize XML properly. When I allow Eclipse to do the work 
(presumably with javac/jar...), everything is fine. I am continuing to 
look for differences so that we can solve this.

---------------------

Follow up:

Andrew and I narrowed this down to a problem with inner class references back to the outer class 'this' reference. Depending on the compiler options used, the 'this' reference is null, so our inner class, which is used to add DOM Level 2 support to XStream, gets an NPE. Making the inner class a 'normal' class results in the same behavior. Making it an anonymous class and providing a link to a final variable does not work either, even though the final variable is initialized properly and we do this at least once in our sample projects (involving threads).

To complicate matters, the XStream class in the XStream library is very hard to extend. We need to modify the MapperWrapper object used by XStream in order to provide the namespace/prefixes during serialization and remove them before deserialization. WIthout this, XStream only supports DOM Level 1, and we wouldn't be able to produce XSD-compliant XML fragments (or parse them).

The only way to modify what MapperWrapper is used is to override the wrapMapper() method, which is protected in the XStream class. Unfortunately, wrapMapper() is called during super() (the parent class constructor), so we cannot set any private fields in our subclass and then use them for the MapperWrapper creation. Our idea is to provide the java.lang.Class variable that represents the type being serialized so that we can properly add/remove prefixes from the element/class names. Our attempt to return a sub-class of MapperWrapper with the data we need fails because it is created before we can get the additional data to it.

We will give this one more day to look - if we can't figure it out, we'll have to replace the serializer in the httpd sample and remove the muse-util-xstream module.


> Deserialization of properties with XStream causes NPE
> -----------------------------------------------------
>
>                 Key: MUSE-142
>                 URL: http://issues.apache.org/jira/browse/MUSE-142
>             Project: Muse
>          Issue Type: Bug
>          Components: Utilities - XStream, Core Engine - Routing and Serialization
>    Affects Versions: 2.0.0
>            Reporter: Dan Jemiolo
>         Assigned To: Dan Jemiolo
>            Priority: Critical
>             Fix For: 2.1.0
>
>
> When trying to call the GetResourceProperty method on complex types that are deserialized with XStream, there is an NPE. This was solved at some point because it works on my machine, but others using both the 2.0 release and the current nightly build have the error. I have to find what the diff is in my configuration so we can re-fix the bug. This bug must be solved for the httpd sample to work.
> Documented here: http://marc.theaimsgroup.com/?t=116249919400002&r=1&w=2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org