[JBossWS] - JAXB error when using different derived types in the same co
by javaslag
I have what seems to be a correct piece of SOAP being sent to JBossWS 1.0.4 that causes a binding exception. This only occurs when I send 2 different sub-class/derived types in the same container type. Sending each type independently (or several instances of the same type) works fine.
In my example I have a Transaction type that contains an unbound number of Atoms, where Atom is an abstract type. There are 2 derivative of Atom, AtomType1 and AtomType2 which each extend Atom and add an additional sub-element element unique to the specialised type.
(You can assume the namespaces/jax-rpc mapping is correct as when used independently from each other, the derived types bind fine.)
My Types...
| <complexType abstract="true" name="Atom">
| <sequence>
| <element name="atom_id" type="nonNegativeInteger" />
| <element name="name" nillable="true" type="string" />
| </sequence>
| </complexType>
|
| <complexType name="Transaction">
| <sequence>
| <element maxOccurs="unbounded" name="atom" type="myns:Atom" />
| </sequence>
| </complexType>
|
|
| <complexType name="AtomType1">
| <complexContent>
| <extension base="myns:Atom">
| <sequence>
| <element name="atom_type_1_value" type="unsignedLong" />
| </sequence>
| </extension>
| </complexContent>
| </complexType>
|
| <complexType name="AtomType2">
| <complexContent>
| <extension base="myns:Atom">
| <sequence>
| <element name="atom_type_2_value" type="unsignedLong" />
| </sequence>
| </extension>
| </complexContent>
| </complexType>
First example which is processed fine, and proves the type is bound correctly. Single Atom in the Transaction
<?xml version="1.0" encoding="UTF-8"?>
| <env:Envelope
| xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
| xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
| xmlns:ns0="http://mynamespace">
|
| <env:Body>
| <ns0:update>
| <Transaction_1>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType2">
| <atom_id>1</atom_id>
| <name>myName2</name>
| <atom_type_2_value>2</atom_type_2_value>
| </atom>
|
| </Transaction_1>
| </ns0:update>
| </env:Body>
| </env:Envelope>
The next Transaction contains 2 different Atom derived types, and fails processing with this exception
Error: anonymous wrote : org.jboss.ws.binding.BindingException: org.jboss.ws.jbossxb.UnmarshalException: Failed to parse source: Requested element atom_type_2_value is not allowed in this position in the sequence. A model group with minOccurs=1 that doesn't contain this element must follow.
<?xml version="1.0" encoding="UTF-8"?>
| <env:Envelope
| xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
| xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
| xmlns:ns0="http://mynamespace">
|
| <env:Body>
| <ns0:update>
| <Transaction_1>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType1">
| <atom_id>1</atom_id>
| <name>myName</name>
| <atom_type_1_value>2</atom_type_1_value>
| </atom>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType2">
| <atom_id>2</atom_id>
| <name>myName2</name>
| <atom_type_2_value>2</atom_type_2_value>
| </atom>
|
| </Transaction_1>
| </ns0:update>
| </env:Body>
| </env:Envelope>
Just for a test, I switched the order of the Atoms in the transaction and note that the binding exception is now accredited to the other derived type
Error: anonymous wrote : org.jboss.ws.binding.BindingException: org.jboss.ws.jbossxb.UnmarshalException: Failed to parse source: Requested element atom_type_1_value is not allowed in this position in the sequence. A model group with minOccurs=1 that doesn't contain this element must follow.
<?xml version="1.0" encoding="UTF-8"?>
| <env:Envelope
| xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
| xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
| xmlns:ns0="http://mynamespace">
|
| <env:Body>
| <ns0:update>
| <Transaction_1>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType2">
| <atom_id>1</atom_id>
| <name>myName</name>
| <atom_type_1_value>2</atom_type_1_value>
| </atom>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType1">
| <atom_id>2</atom_id>
| <name>myName2</name>
| <atom_type_2_value>2</atom_type_2_value>
| </atom>
|
| </Transaction_1>
| </ns0:update>
| </env:Body>
| </env:Envelope>
The final Transaction contains 2 atoms of the same derived type - and is processed fine.
<?xml version="1.0" encoding="UTF-8"?>
| <env:Envelope
| xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
| xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
| xmlns:ns0="http://mynamespace">
|
| <env:Body>
| <ns0:update>
| <Transaction_1>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType1">
| <atom_id>1</atom_id>
| <name>myName</name>
| <atom_type_1_value>2</atom_type_1_value>
| </atom>
|
| <atom xmlns:ans1="http://mynamespace" xsi:type="ans1:AtomType1">
| <atom_id>2</atom_id>
| <name>myName2</name>
| <atom_type_2_value>2</atom_type_2_value>
| </atom>
|
| </Transaction_1>
| </ns0:update>
| </env:Body>
| </env:Envelope>
Worth raising a bug?
Regards - J
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019863#4019863
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019863
19Â years, 2Â months
[JBoss Seam] - Re: catching exceptions + stack trace
by damianharvey
Maybe my terminology is incorrect. What I see in the logs is this:
| 11:35:59,848 INFO [Lifecycle] starting up: org.jboss.seam.security.identity
| 11:36:12,167 ERROR [SeamPhaseListener] uncaught exception
| org.jboss.seam.security.NotLoggedInException: Error evaluating expression [#{identity.loggedIn}] - User not logged in
| at org.jboss.seam.security.Identity.checkRestriction(Identity.java:169)
| at org.jboss.seam.pages.Page.enter(Page.java:186)
| at org.jboss.seam.core.Pages.enterPage(Pages.java:239)
| at org.jboss.seam.jsf.AbstractSeamPhaseListener.enterPage(AbstractSeamPhaseListener.java:242)
| at org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:193)
| at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:57)
| at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
| at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:29)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:43)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:613)
|
Whereas I was hoping that this would be caught and not shown in the logs.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019862#4019862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019862
19Â years, 2Â months