You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Ault, Matt" <Ma...@elavon.com> on 2009/05/21 22:04:03 UTC
Possible Issue in
org.apache.cxf.jaxws.interceptors.SwAOutInterceptor
I believe I have found a possible issue in the org.apache.cxf.jaxws.interceptors.SwAOutInterceptor. The functionality appears to have changed between 2.1.3 and 2.2.1. I'm not sure which is the correct functionality so I thought I'd post here first.
This problem occurs when you have a JAXBContextImplementation that does not have a hasSwaRef method. I found this issue when moving a service from Tomcat to WebSphere. IBM uses a different implementation of JAXBContext by default and IBM's version doesn't have a hasSwaRef method on it.
In 2.2.1 this results in a NullPointerException in this block of code:
1 private boolean callSWARefMethod(JAXBContext ctx) {
2 Method m = SWA_REF_METHOD.get(ctx.getClass().getName());
3 if (m == null && !SWA_REF_METHOD.containsKey(ctx.getClass().getName())) {
4 try {
5 m = ctx.getClass().getMethod("hasSwaRef", new Class[0]);
6 } catch (Exception e) {
7 //ignore
8 }
9 SWA_REF_METHOD.put(ctx.getClass().getName(), m);
10 }
11 try {
12 return (Boolean)m.invoke(ctx);
13 } catch (Exception e) {
14 return false;
15 }
16 }
This throws the NPE at line 9 SWA_REF_METHOD.put(ctx.getClass().getName(), m); because m is null. In JDK 1.6.07 ConcurrentHashMap.put() throws a NullPointerException when the value is null. This causes a SOAPFault to be returned to the client.
I believe that this code should just return false if the hasSwaRef method doesn't exist (which is how this operates in 2.1.3). If the put() wasn't called when m is null, then this code should return true if the method exists and false if it doesn't.
Fortunately, I can work around this by setting the javax.xml.bind.JAXBContext system property to the Sun version (com.sun.xml.bind.v2.ContextFactory) which returns a JAXBContext that implements hasSwaRef().
Let me know if you need any more information from me regarding this issue, I didn't post it to JIRA since I wasn't sure if the code was performing correctly yet.
Matt Ault
Systems and Technology
Elavon
----------------------------------------- Note: The information
contained in this e-mail and in any attachments is intended only
for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities
other than the intended recipient is prohibited. The recipient
should check this e-mail and any attachments for the presence of
viruses. Sender accepts no liability for any damages caused by any
virus transmitted by this e-mail. If you have received this e-mail
in error, please notify us immediately by replying to the message
and delete the e-mail from your computer. Elavon (formerly NOVA
Information Systems)
Re: Possible Issue in org.apache.cxf.jaxws.interceptors.SwAOutInterceptor
Posted by Bharath Ganesh <bh...@gmail.com>.
Good one :-D
ConcurrentHashMap Javadoc says -
*"A hash table supporting full concurrency of retrievals and adjustable
expected concurrency for updates.
This class is fully interoperable with Hashtable in programs that rely on
its thread safety but not on its synchronization details." *
So I guess because of the HashTable relationship it doesn't permit nulls.
On Fri, May 22, 2009 at 2:00 AM, Daniel Kulp <dk...@apache.org> wrote:
>
>
> Interesting. Didn't know that ConcurrentHashMaps couldn't have null
> values.
> Definitely different than normal HashMaps. Learn something new every day.
> :-0
>
> Yea. It's an issue. Committed fix to trunk for 2.2.2.
>
> Dan
>
>
>
> On Thu May 21 2009 4:04:03 pm Ault, Matt wrote:
> > I believe I have found a possible issue in the
> > org.apache.cxf.jaxws.interceptors.SwAOutInterceptor. The functionality
> > appears to have changed between 2.1.3 and 2.2.1. I'm not sure which is
> the
> > correct functionality so I thought I'd post here first.
> >
> > This problem occurs when you have a JAXBContextImplementation that does
> not
> > have a hasSwaRef method. I found this issue when moving a service from
> > Tomcat to WebSphere. IBM uses a different implementation of JAXBContext
> by
> > default and IBM's version doesn't have a hasSwaRef method on it.
> >
> > In 2.2.1 this results in a NullPointerException in this block of code:
> >
> > 1 private boolean callSWARefMethod(JAXBContext ctx) {
> > 2 Method m = SWA_REF_METHOD.get(ctx.getClass().getName());
> > 3 if (m == null &&
> > !SWA_REF_METHOD.containsKey(ctx.getClass().getName())) { 4 try
> {
> > 5 m = ctx.getClass().getMethod("hasSwaRef", new
> Class[0]);
> > 6 } catch (Exception e) {
> > 7 //ignore
> > 8 }
> > 9 SWA_REF_METHOD.put(ctx.getClass().getName(), m);
> > 10 }
> > 11 try {
> > 12 return (Boolean)m.invoke(ctx);
> > 13 } catch (Exception e) {
> > 14 return false;
> > 15 }
> > 16 }
> >
> > This throws the NPE at line 9
> SWA_REF_METHOD.put(ctx.getClass().getName(),
> > m); because m is null. In JDK 1.6.07 ConcurrentHashMap.put() throws a
> > NullPointerException when the value is null. This causes a SOAPFault to
> be
> > returned to the client.
> >
> > I believe that this code should just return false if the hasSwaRef method
> > doesn't exist (which is how this operates in 2.1.3). If the put() wasn't
> > called when m is null, then this code should return true if the method
> > exists and false if it doesn't.
> >
> > Fortunately, I can work around this by setting the
> > javax.xml.bind.JAXBContext system property to the Sun version
> > (com.sun.xml.bind.v2.ContextFactory) which returns a JAXBContext that
> > implements hasSwaRef().
> >
> > Let me know if you need any more information from me regarding this
> issue,
> > I didn't post it to JIRA since I wasn't sure if the code was performing
> > correctly yet.
> >
> >
> > Matt Ault
> > Systems and Technology
> > Elavon
> >
> > ----------------------------------------- Note: The information
> > contained in this e-mail and in any attachments is intended only
> > for the person or entity to which it is addressed and may contain
> > confidential and/or privileged material. Any review,
> > retransmission, dissemination or other use of, or taking of any
> > action in reliance upon, this information by persons or entities
> > other than the intended recipient is prohibited. The recipient
> > should check this e-mail and any attachments for the presence of
> > viruses. Sender accepts no liability for any damages caused by any
> > virus transmitted by this e-mail. If you have received this e-mail
> > in error, please notify us immediately by replying to the message
> > and delete the e-mail from your computer. Elavon (formerly NOVA
> > Information Systems)
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Possible Issue in org.apache.cxf.jaxws.interceptors.SwAOutInterceptor
Posted by Daniel Kulp <dk...@apache.org>.
Interesting. Didn't know that ConcurrentHashMaps couldn't have null values.
Definitely different than normal HashMaps. Learn something new every day.
:-0
Yea. It's an issue. Committed fix to trunk for 2.2.2.
Dan
On Thu May 21 2009 4:04:03 pm Ault, Matt wrote:
> I believe I have found a possible issue in the
> org.apache.cxf.jaxws.interceptors.SwAOutInterceptor. The functionality
> appears to have changed between 2.1.3 and 2.2.1. I'm not sure which is the
> correct functionality so I thought I'd post here first.
>
> This problem occurs when you have a JAXBContextImplementation that does not
> have a hasSwaRef method. I found this issue when moving a service from
> Tomcat to WebSphere. IBM uses a different implementation of JAXBContext by
> default and IBM's version doesn't have a hasSwaRef method on it.
>
> In 2.2.1 this results in a NullPointerException in this block of code:
>
> 1 private boolean callSWARefMethod(JAXBContext ctx) {
> 2 Method m = SWA_REF_METHOD.get(ctx.getClass().getName());
> 3 if (m == null &&
> !SWA_REF_METHOD.containsKey(ctx.getClass().getName())) { 4 try {
> 5 m = ctx.getClass().getMethod("hasSwaRef", new Class[0]);
> 6 } catch (Exception e) {
> 7 //ignore
> 8 }
> 9 SWA_REF_METHOD.put(ctx.getClass().getName(), m);
> 10 }
> 11 try {
> 12 return (Boolean)m.invoke(ctx);
> 13 } catch (Exception e) {
> 14 return false;
> 15 }
> 16 }
>
> This throws the NPE at line 9 SWA_REF_METHOD.put(ctx.getClass().getName(),
> m); because m is null. In JDK 1.6.07 ConcurrentHashMap.put() throws a
> NullPointerException when the value is null. This causes a SOAPFault to be
> returned to the client.
>
> I believe that this code should just return false if the hasSwaRef method
> doesn't exist (which is how this operates in 2.1.3). If the put() wasn't
> called when m is null, then this code should return true if the method
> exists and false if it doesn't.
>
> Fortunately, I can work around this by setting the
> javax.xml.bind.JAXBContext system property to the Sun version
> (com.sun.xml.bind.v2.ContextFactory) which returns a JAXBContext that
> implements hasSwaRef().
>
> Let me know if you need any more information from me regarding this issue,
> I didn't post it to JIRA since I wasn't sure if the code was performing
> correctly yet.
>
>
> Matt Ault
> Systems and Technology
> Elavon
>
> ----------------------------------------- Note: The information
> contained in this e-mail and in any attachments is intended only
> for the person or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any
> action in reliance upon, this information by persons or entities
> other than the intended recipient is prohibited. The recipient
> should check this e-mail and any attachments for the presence of
> viruses. Sender accepts no liability for any damages caused by any
> virus transmitted by this e-mail. If you have received this e-mail
> in error, please notify us immediately by replying to the message
> and delete the e-mail from your computer. Elavon (formerly NOVA
> Information Systems)
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog