Working around (Weblogic) StAX issues

[James Abley]

Hi,

I'm very happy with my AtomPub server running on a Sun JVM within
Tomcat. I'm less so with it running on JRockit / Weblogic 9.2. 68108

I'm using Abdera revision 681083, so it's reasonably current.

When I try to update a Media Link Entry on Weblogic, I get the
following (by using the debugger and printing the stack trace):

org.apache.abdera.parser.ParseException:
java.lang.IllegalArgumentException: prefix cannot be "null" when
creating a QName
        at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:260)
        at org.apache.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:265)
        at org.apache.axiom.om.impl.traverse.OMChildrenIterator.next(OMChildrenIterator.java:106)
        at org.apache.abdera.parser.stax.FOMDocument.clone(FOMDocument.java:229)
        at org.apache.abdera.protocol.server.impl.AbstractCollectionAdapter.getEntryFromRequest(AbstractCollectionAdapter.java:245)
        at com.example.cms.abdera.MyCollectionAdapter.getEntryFromRequest(MyCollectionAdapter.java:399)
        at org.apache.abdera.protocol.server.impl.AbstractEntityCollectionAdapter.putEntry(AbstractEntityCollectionAdapter.java:493)
        at org.apache.abdera.protocol.server.processors.EntryRequestProcessor.processEntry(EntryRequestProcessor.java:46)
        at org.apache.abdera.protocol.server.processors.EntryRequestProcessor.process(EntryRequestProcessor.java:37)
        at org.apache.abdera.protocol.server.impl.AbstractProvider.process(AbstractProvider.java:136)
        at org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
        at com.example.cms.abdera.JCRSessionFilter.filter(JCRSessionFilter.java:44)
        at org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
        at org.apache.abdera.protocol.server.servlet.AbderaServlet.service(AbderaServlet.java:90)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:223)
        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
        at com.example.cms.abdera.JCRSessionServletFilter.doFilter(JCRSessionServletFilter.java:39)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
        at com.example.contentrepository.springmodule.http.TransactionSynchronizationFilter.doFilterInternal(TransactionSynchronizationFilter.java:98)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3243)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2003)
        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1909)
        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
Caused by: java.lang.IllegalArgumentException: prefix cannot be "null"
when creating a QName
        at javax.xml.namespace.QName.<init>(QName.java:220)
        at weblogic.xml.stax.XMLStreamReaderBase.getAttributeName(XMLStreamReaderBase.java:339)
        at org.apache.abdera.parser.stax.FOMBuilder.processAttributes(FOMBuilder.java:296)
        at org.apache.abdera.parser.stax.FOMBuilder.constructNode(FOMBuilder.java:287)
        at org.apache.abdera.parser.stax.FOMBuilder.createOMElement(FOMBuilder.java:98)
        at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:193)
        ... 32 more

It works fine on Tomcat using Sun Java 5 and Java 6 JVMs.

Setting a breakpoint at line 296 of FOMBuilder gives me a parser reference:

parser.getClass().getProtectionDomain().getCodeSource().getLocation()
= file:/opt/bea/weblogic92/server/lib/weblogic.jar

It seems to be a known issue with Weblogic's StAX implementation [1].
Tempting though it might be to crack out JAD and patch the offending
XMLStreamReaderBase class, I don't think my customers running on
Weblogic would be entirely happy with that solution.

How are others managing StAX vagaries in deployed situations? Java XML
issues are always such fun! Is it preferable to just set system
properties such as javax.xml.stream.XMLInputFactory,
javax.xml.stream.XMLOutputFactory and
javax.xml.stream.XMLEventFactory, or go some other way?

Regards,

James

[1] http://forums.bea.com/thread.jspa?threadID=400001073

[James Abley]

2008/8/12 James Abley <james.abley@...>:

> Hi,
>
> I'm very happy with my AtomPub server running on a Sun JVM within
> Tomcat. I'm less so with it running on JRockit / Weblogic 9.2. 68108
>
> I'm using Abdera revision 681083, so it's reasonably current.
>
> When I try to update a Media Link Entry on Weblogic, I get the
> following (by using the debugger and printing the stack trace):
>
> org.apache.abdera.parser.ParseException:
> java.lang.IllegalArgumentException: prefix cannot be "null" when
> creating a QName
>        at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:260)
>        at org.apache.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:265)
>        at org.apache.axiom.om.impl.traverse.OMChildrenIterator.next(OMChildrenIterator.java:106)
>        at org.apache.abdera.parser.stax.FOMDocument.clone(FOMDocument.java:229)
>        at org.apache.abdera.protocol.server.impl.AbstractCollectionAdapter.getEntryFromRequest(AbstractCollectionAdapter.java:245)
>        at com.example.cms.abdera.MyCollectionAdapter.getEntryFromRequest(MyCollectionAdapter.java:399)
>        at org.apache.abdera.protocol.server.impl.AbstractEntityCollectionAdapter.putEntry(AbstractEntityCollectionAdapter.java:493)
>        at org.apache.abdera.protocol.server.processors.EntryRequestProcessor.processEntry(EntryRequestProcessor.java:46)
>        at org.apache.abdera.protocol.server.processors.EntryRequestProcessor.process(EntryRequestProcessor.java:37)
>        at org.apache.abdera.protocol.server.impl.AbstractProvider.process(AbstractProvider.java:136)
>        at org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
>        at com.example.cms.abdera.JCRSessionFilter.filter(JCRSessionFilter.java:44)
>        at org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
>        at org.apache.abdera.protocol.server.servlet.AbderaServlet.service(AbderaServlet.java:90)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:223)
>        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
>        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
>        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>        at com.example.cms.abdera.JCRSessionServletFilter.doFilter(JCRSessionServletFilter.java:39)
>        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>        at com.example.contentrepository.springmodule.http.TransactionSynchronizationFilter.doFilterInternal(TransactionSynchronizationFilter.java:98)
>        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
>        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3243)
>        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2003)
>        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1909)
>        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
>        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>        at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> Caused by: java.lang.IllegalArgumentException: prefix cannot be "null"
> when creating a QName
>        at javax.xml.namespace.QName.<init>(QName.java:220)
>        at weblogic.xml.stax.XMLStreamReaderBase.getAttributeName(XMLStreamReaderBase.java:339)
>        at org.apache.abdera.parser.stax.FOMBuilder.processAttributes(FOMBuilder.java:296)
>        at org.apache.abdera.parser.stax.FOMBuilder.constructNode(FOMBuilder.java:287)
>        at org.apache.abdera.parser.stax.FOMBuilder.createOMElement(FOMBuilder.java:98)
>        at org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:193)
>        ... 32 more
>
> It works fine on Tomcat using Sun Java 5 and Java 6 JVMs.
>
> Setting a breakpoint at line 296 of FOMBuilder gives me a parser reference:
>
> parser.getClass().getProtectionDomain().getCodeSource().getLocation()
> = file:/opt/bea/weblogic92/server/lib/weblogic.jar
>
> It seems to be a known issue with Weblogic's StAX implementation [1].
> Tempting though it might be to crack out JAD and patch the offending
> XMLStreamReaderBase class, I don't think my customers running on
> Weblogic would be entirely happy with that solution.
>
> How are others managing StAX vagaries in deployed situations? Java XML
> issues are always such fun! Is it preferable to just set system
> properties such as javax.xml.stream.XMLInputFactory,
> javax.xml.stream.XMLOutputFactory and
> javax.xml.stream.XMLEventFactory, or go some other way?
>
> Regards,
>
> James
>
> [1] http://forums.bea.com/thread.jspa?threadID=400001073
>

In case anyone is interested, we went the following route:

1. Configure the application within Weblogic to prefer classes loaded
from the application WEB-INF/lib and WEB-INF/classes.
2. Use the Service Provider API [1].

This gives us the correct behaviour and seems the least invasive
change that we can make to get it to work. If we just set a system
property, then that might influence other people's applications
running in the same container. Whether they might be impacted by us
enforcing a less buggy version of StAX being used is debatable!

Cheers,

James

[1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider

[David Calavera]

thank you James, I'm thinking on create a troubleshooting section into the
abdera wiki and this could be a useful resource.

On Mon, Aug 18, 2008 at 12:05 PM, James Abley <james.abley@...> wrote:

> 2008/8/12 James Abley <james.abley@...>:
> > Hi,
> >
> > I'm very happy with my AtomPub server running on a Sun JVM within
> > Tomcat. I'm less so with it running on JRockit / Weblogic 9.2. 68108
> >
> > I'm using Abdera revision 681083, so it's reasonably current.
> >
> > When I try to update a Media Link Entry on Weblogic, I get the
> > following (by using the debugger and printing the stack trace):
> >
> > org.apache.abdera.parser.ParseException:
> > java.lang.IllegalArgumentException: prefix cannot be "null" when
> > creating a QName
> >        at
> org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:260)
> >        at
> org.apache.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:265)
> >        at
> org.apache.axiom.om.impl.traverse.OMChildrenIterator.next(OMChildrenIterator.java:106)
> >        at
> org.apache.abdera.parser.stax.FOMDocument.clone(FOMDocument.java:229)
> >        at
> org.apache.abdera.protocol.server.impl.AbstractCollectionAdapter.getEntryFromRequest(AbstractCollectionAdapter.java:245)
> >        at
> com.example.cms.abdera.MyCollectionAdapter.getEntryFromRequest(MyCollectionAdapter.java:399)
> >        at
> org.apache.abdera.protocol.server.impl.AbstractEntityCollectionAdapter.putEntry(AbstractEntityCollectionAdapter.java:493)
> >        at
> org.apache.abdera.protocol.server.processors.EntryRequestProcessor.processEntry(EntryRequestProcessor.java:46)
> >        at
> org.apache.abdera.protocol.server.processors.EntryRequestProcessor.process(EntryRequestProcessor.java:37)
> >        at
> org.apache.abdera.protocol.server.impl.AbstractProvider.process(AbstractProvider.java:136)
> >        at
> org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
> >        at
> com.example.cms.abdera.JCRSessionFilter.filter(JCRSessionFilter.java:44)
> >        at
> org.apache.abdera.protocol.server.FilterChain.next(FilterChain.java:42)
> >        at
> org.apache.abdera.protocol.server.servlet.AbderaServlet.service(AbderaServlet.java:90)
> >        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> >        at
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:223)
> >        at
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
> >        at
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
> >        at
> weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
> >        at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> >        at
> com.example.cms.abdera.JCRSessionServletFilter.doFilter(JCRSessionServletFilter.java:39)
> >        at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> >        at
> com.example.contentrepository.springmodule.http.TransactionSynchronizationFilter.doFilterInternal(TransactionSynchronizationFilter.java:98)
> >        at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
> >        at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> >        at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3243)
> >        at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> >        at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
> >        at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2003)
> >        at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1909)
> >        at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
> >        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
> >        at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> > Caused by: java.lang.IllegalArgumentException: prefix cannot be "null"
> > when creating a QName
> >        at javax.xml.namespace.QName.<init>(QName.java:220)
> >        at
> weblogic.xml.stax.XMLStreamReaderBase.getAttributeName(XMLStreamReaderBase.java:339)
> >        at
> org.apache.abdera.parser.stax.FOMBuilder.processAttributes(FOMBuilder.java:296)
> >        at
> org.apache.abdera.parser.stax.FOMBuilder.constructNode(FOMBuilder.java:287)
> >        at
> org.apache.abdera.parser.stax.FOMBuilder.createOMElement(FOMBuilder.java:98)
> >        at
> org.apache.abdera.parser.stax.FOMBuilder.next(FOMBuilder.java:193)
> >        ... 32 more
> >
> > It works fine on Tomcat using Sun Java 5 and Java 6 JVMs.
> >
> > Setting a breakpoint at line 296 of FOMBuilder gives me a parser
> reference:
> >
> > parser.getClass().getProtectionDomain().getCodeSource().getLocation()
> > = file:/opt/bea/weblogic92/server/lib/weblogic.jar
> >
> > It seems to be a known issue with Weblogic's StAX implementation [1].
> > Tempting though it might be to crack out JAD and patch the offending
> > XMLStreamReaderBase class, I don't think my customers running on
> > Weblogic would be entirely happy with that solution.
> >
> > How are others managing StAX vagaries in deployed situations? Java XML
> > issues are always such fun! Is it preferable to just set system
> > properties such as javax.xml.stream.XMLInputFactory,
> > javax.xml.stream.XMLOutputFactory and
> > javax.xml.stream.XMLEventFactory, or go some other way?
> >
> > Regards,
> >
> > James
> >
> > [1] http://forums.bea.com/thread.jspa?threadID=400001073
> >
>
> In case anyone is interested, we went the following route:
>
> 1. Configure the application within Weblogic to prefer classes loaded
> from the application WEB-INF/lib and WEB-INF/classes.
> 2. Use the Service Provider API [1].
>
> This gives us the correct behaviour and seems the least invasive
> change that we can make to get it to work. If we just set a system
> property, then that might influence other people's applications
> running in the same container. Whether they might be impacted by us
> enforcing a less buggy version of StAX being used is debatable!
>
> Cheers,
>
> James
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
>

--
David Calavera
http://www.thinkincode.net