[JBoss JIRA] Created: (JBWS-1365) CTS: Header tests fail
by Jason T. Greene (JIRA)
CTS: Header tests fail
----------------------
Key: JBWS-1365
URL: http://jira.jboss.com/jira/browse/JBWS-1365
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/headertest/Client.java#GoodOrderTestWithSoapHeaderAndMUFalse_from_wsappclien
Reporter: Jason T. Greene
Fix For: jbossws-2.0.0.CR2
11-13-2006 22:12:54: ERROR: javax.xml.ws.soap.SOAPFaultException: javax.xml.ws.soap.SOAPFaultException: Cannot find child element: {http://headertestservice.org/types4}ConfigHeaderRequest
at org.jboss.ws.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:190)
at org.jboss.ws.jaxws.client.ClientImpl.invoke(ClientImpl.java:152)
at org.jboss.ws.jaxws.client.ClientProxy.invoke(ClientProxy.java:156)
at org.jboss.ws.jaxws.client.ClientProxy.invoke(ClientProxy.java:142)
at $Proxy17.submitOrder(Unknown Source)
at com.sun.ts.tests.jaxws.ee.w2j.rpc.literal.headertest.Client.GoodOrderTestWithSoapHeaderAndMUFalse(Client.java:218)
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 com.sun.ts.lib.harness.EETest.run(EETest.java:495)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:112)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Created: (JBWS-1364) CTS: UnmodifiableOperationException in handler tests
by Jason T. Greene (JIRA)
CTS: UnmodifiableOperationException in handler tests
----------------------------------------------------
Key: JBWS-1364
URL: http://jira.jboss.com/jira/browse/JBWS-1364
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jaxws
Environment: com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/handlertest/Client.java#ClientLogicalHandlerTest_from_wsappclient
Reporter: Jason T. Greene
Fix For: jbossws-2.0.0.CR2
Caused by: java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableCollection.add(Collections.java:1018)
at com.sun.ts.tests.jaxws.ee.w2j.rpc.literal.handlertest.Client$1.getHandlerChain(Client.java:362)
at org.jboss.ws.jaxws.client.ClientImpl.initBindingHandlerChain(ClientImpl.java:84)
at org.jboss.ws.jaxws.client.ClientImpl.<init>(ClientImpl.java:73)
at org.jboss.ws.jaxws.spi.ServiceDelegateImpl.createProxy(ServiceDelegateImpl.java:289)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Created: (JBWS-1361) CTS: javax.xml.ws.soap.SOAPBinding.getRoles() returns Set<URI> instead of Set<String>
by Jason T. Greene (JIRA)
CTS: javax.xml.ws.soap.SOAPBinding.getRoles() returns Set<URI> instead of Set<String>
--------------------------------------------------------------------------------------
Key: JBWS-1361
URL: http://jira.jboss.com/jira/browse/JBWS-1361
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jaxws
Environment: com/sun/ts/tests/jaxws/api/javax_xml_ws_soap/SOAPBinding/Client.java#SetGetRolesForDispatchObjTest_from_wsappclient
Reporter: Jason T. Greene
Assigned To: Jason T. Greene
Fix For: jbossws-2.0.0.CR2
11-13-2006 21:33:57: ERROR: java.lang.ClassCastException: java.net.URI
at com.sun.ts.tests.jaxws.api.javax_xml_ws_soap.SOAPBinding.Client.SetGetRolesForDispatchObjTest(Client.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Commented: (JBWS-1297) Implement JAXB Fault Marshalling
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1297?page=comments#action_12346947 ]
Alejandro Guizar commented on JBWS-1297:
----------------------------------------
Marshalling is done. The outgoing SOAP messages look good, altough the tests still fail because unmarshalling is not done yet. I modified JSR181MetaDataBuilder to populate the XML type for the fault bean.
Currently, I copy the properties using low-level reflection. Can you point me to the accessor API you are referring to?
I'll commit what I have and work on unmarshalling the rest of the evening.
> Implement JAXB Fault Marshalling
> --------------------------------
>
> Key: JBWS-1297
> URL: http://jira.jboss.com/jira/browse/JBWS-1297
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jaxws
> Reporter: Jason T. Greene
> Assigned To: Alejandro Guizar
> Fix For: jbossws-2.0.0.CR2
>
>
> Currently the marshalling layer tries to pass the exception class to JAXB. Instead it needs to pass the fault bean, and then copy the properties to/from the actual exception
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Commented: (JBWS-1297) Implement JAXB Fault Marshalling
by Jason T. Greene (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1297?page=comments#action_12346789 ]
Jason T. Greene commented on JBWS-1297:
---------------------------------------
The fault bean is already discovered or built by the JSR181MetaDataBuilder. You can get the class by just saying faultMetaData.getFaultBean(). You then only have to check if the exception you are trying to (un)marshall to/from can take a fault bean.
So here is the order of preference.
Marshalling a Exception
1. Look for getFaultInfo(), call and marshall the instance that is returned if exists
2. Otherwise, instantiate a new fault bean, and copy each property individually.
Unmarshalling an Exception
1. Look for a contsturctor that takes the fault bean, if present pass the fault bean instance to the constructor
2. Otherwise, instantiate a new Exception using the values from the fault bean instance. The order will be defined
on the propOrder attribute of the @XmlType annotation.
That said, I realize that In order to access the properties on the JAXB fault bean, we are going to need to use something similar to the accessor API
that is used for (un)marshalling wrapped request/response structures. I am going to create a separate issue for this, assign it to myself
and link it as a dependency.
> Implement JAXB Fault Marshalling
> --------------------------------
>
> Key: JBWS-1297
> URL: http://jira.jboss.com/jira/browse/JBWS-1297
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jaxws
> Reporter: Jason T. Greene
> Assigned To: Alejandro Guizar
> Fix For: jbossws-2.0.0.CR2
>
>
> Currently the marshalling layer tries to pass the exception class to JAXB. Instead it needs to pass the fault bean, and then copy the properties to/from the actual exception
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Commented: (JBWS-1297) Implement JAXB Fault Marshalling
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1297?page=comments#action_12346774 ]
Alejandro Guizar commented on JBWS-1297:
----------------------------------------
How to obtain the fault bean:
1.a If the exception class has a getFaultInfo method **and** WebFault annotation:
(note: how to interpret the "and" above? an exception having a WebFault annotation but not a getFaultInfo method does not comply with the semantics of the annotation. should we bomb?)
1.a.1 invoke getFaultInfo on the exception object; the return instance goes to JAXB
2.b Otherwise
2.b.1 retrieve the bean class from the fault metadata
2.b.2 instantiate the bean class
2.c.2 copy the non-excluded properties from the exception instance to the bean instance
> Implement JAXB Fault Marshalling
> --------------------------------
>
> Key: JBWS-1297
> URL: http://jira.jboss.com/jira/browse/JBWS-1297
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jaxws
> Reporter: Jason T. Greene
> Assigned To: Alejandro Guizar
> Fix For: jbossws-2.0.0.CR2
>
>
> Currently the marshalling layer tries to pass the exception class to JAXB. Instead it needs to pass the fault bean, and then copy the properties to/from the actual exception
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years