[JBoss JIRA] Created: (JBWS-2157) Child nodes truncated when using jaxb to marshall data into a SOAP header
by Andrew Dinn (JIRA)
Child nodes truncated when using jaxb to marshall data into a SOAP header
--------------------------------------------------------------------------
Key: JBWS-2157
URL: http://jira.jboss.com/jira/browse/JBWS-2157
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.1
Reporter: Andrew Dinn
I wish to serialise a CoordinationContext type (a complex type defined in the OASIS WS-COOR 1.1 spec) into a SOAP message header as follows:
<code>
final JAXBContext jaxbCtx = getJaxbContext();
final SOAPMessage soapMessage = context.getMessage();
final SOAPEnvelope soapEnvelope = soapMessage.getSOAPPart().getEnvelope();
SOAPHeader soapHeader = soapEnvelope.getHeader() ;
if (soapHeader == null)
{
soapHeader = soapEnvelope.addHeader() ;
}
Marshaller marshaller = jaxbCtx.createMarshaller();
marshaller.marshal(coordinationContext, soapHeader);
</code>
The problem is that the header gets inserted without any children.
What happens is that the marshaller creates a SOAP tree top down consisting of SOAPElementImpl instances. It inserts these nodes into the tree below the SOAPHeader as it creates them. So, when the first node is created a call to SOAPHeader.addchild() is made. This call deteccts that the supplied node is of the wrong type so it substitutes a SOAPHeaderElementImpl. It attempts to copy the supplied node's substructure but the marshaller has not created the children at this point.
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBWS-2317) $JAXBAccessorF_ and $JAXBAccessorM_ cache loosing classes and failing to re-create classes.
by Darran Lofthouse (JIRA)
$JAXBAccessorF_ and $JAXBAccessorM_ cache loosing classes and failing to re-create classes.
-------------------------------------------------------------------------------------------
Key: JBWS-2317
URL: https://jira.jboss.org/jira/browse/JBWS-2317
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro, jbossws-native
Affects Versions: jbossws-metro-3.0.3, jbossws-native-3.0.3
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: jbossws-native-3.0.4, jbossws-metro-3.0.4
The JAXB implementation contains a package of classes to optimise field and method access by dynamically generating classes to avoid reflection, this has a start-up performance hit but then leads to an optimised runtime.
The package is: -
'com.sun.xml.bind.v2.runtime.reflect.opt'
Within the Injector class is a HashMap to maintain a cache of these classes against the classloader they were created for: -
private static final Map<ClassLoader,WeakReference<Injector>> injectors =
Collections.synchronizedMap(new WeakHashMap<ClassLoader,WeakReference<Injector>>());
A WeakReference has been used to wrap the value to prevent the value retaining a reference to the ClassLoader and then preventing garbage collection and leading to a leak.
The problem is that nothing retains a reference to the Injector so as this is wrapped with a WeakReference it is garbage collected.
I will attach to this case a new version of Injector.java.
The fix switches to using a Strong reference to the Injector so it is not garbage collected.
To maintain the original requirements the Injector will no longer hold a reference to the ClassLoader and will instead make use of the one passed in.
Within the Injector the HashMap of classes will reference the Class with a WeakReference. If we get a WeakReference with no class it means the class was previously loaded but garbage collected, in this case try to load the class by name from the classloader - if this fails then redefine the class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (JBWS-2192) Asynchronous calls not thread safe
by Thomas Diesler (JIRA)
Asynchronous calls not thread safe
----------------------------------
Key: JBWS-2192
URL: http://jira.jboss.com/jira/browse/JBWS-2192
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Reporter: Thomas Diesler
Fix For: jbossws-native-3.0.3
Darran sais:
I am currently looking at a support case where the customer is getting a number of errors with asynchronous JAX-WS invocations using a AsyncHandler.
I am running a couple of test cases against the two EAP releases and I am able to reproduce the behaviour that the customer is seeing but I just quickly wanted to double check what should be thread safe.
I have an async method on the SEI that returns a Future instance and takes an AsyncHandler as a parameter: -
@WebMethod(operationName = "lookup")
public Future<?> lookupAsync(final Person person,
AsyncHandler<TelephoneNumber> handler);
This pattern seems to suggest that after the call has been made any further interaction will be with the Future instance or the handler which then makes it look as though the Port is free to service other requests.
However if I submit multiple requests using the same Port then the outgoing requests start to get mixed up.
Should it be possible to re-use the same Port / SEI Proxy for multiple calls without worries of messages being mixed up?
I would have thought if the Port was not supposed to be re-used the get methods for the response would be on the Port instance and not need to use this returned interface.
I have attached the client I am using to reproduce the errors.
Creating a new Port for each request does overcome this issue but they are trying to avoid this especially as the existing Port should have passed the last request off to another thread for processing.
--
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
13 years, 5 months
[JBoss JIRA] Created: (JBWS-2329) Failed to deploy service with multiple bindings
by Alessio Soldano (JIRA)
Failed to deploy service with multiple bindings
-----------------------------------------------
Key: JBWS-2329
URL: https://jira.jboss.org/jira/browse/JBWS-2329
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro
Affects Versions: jbossws-metro-3.0.3
Reporter: Alessio Soldano
When deploying an archive containing two endpoint corresponding to two wsdl binding of the same wsdl service, we get this exception:
javax.xml.ws.WebServiceException: Not a primary WSDL=file:/home/alessio/dati/jboss-4.2-src/build/output/jboss-4.2.4.GA/server/default/tmp/deploy/tmp50323jaxws-jbws2278-exp.war/WEB-INF/wsdl/Test.wsdl since it doesn't have Service {http://org.jboss.test.ws/jbws2278}TestEndpointImplSoap12Service
at com.sun.xml.ws.server.EndpointFactory.verifyPrimaryWSDL(EndpointFactory.java:455)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:155)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parseAdapters(DeploymentDescriptorParserExt.java:301)
at org.jboss.wsf.stack.metro.DeploymentDescriptorParserExt.parse(DeploymentDescriptorParserExt.java:178)
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.start(RuntimeModelDeploymentAspect.java:110)
... 66 more
See the testcase for JBWS-2278.
This could be related to a missing configuration in the generate sun-jaxws.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBWS-2131) WebServiceException: Failed to build METRO runtime model
by Thomas Diesler (JIRA)
WebServiceException: Failed to build METRO runtime model
--------------------------------------------------------
Key: JBWS-2131
URL: http://jira.jboss.com/jira/browse/JBWS-2131
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-metro
Affects Versions: jbossws-metro-1.0.1
Reporter: Thomas Diesler
[tdiesler@tdvaio trunk]$ ant -Dtest=jaxws/jbws1702 test
19:24:24,883 ERROR [MainDeployer] Could not start deployment: file:/home/tdiesler/svn/jbossws/stack/metro/trunk/output/tests/libs/jaxws-jbws1702.war
javax.xml.ws.WebServiceException: Failed to build METRO runtime model
at org.jboss.wsf.stack.metro.metadata.RuntimeModelDeploymentAspect.create(RuntimeModelDeploymentAspect.java:136)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:118)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
--
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
13 years, 8 months