May 2009 - jbossws-issues - Jboss List Archives

[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

13 years, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (JBWS-2627) Provide more CXF WS-RM integration tests to verify QoS

by Richard Opalka (JIRA)

Provide more CXF WS-RM integration tests to verify QoS ------------------------------------------------------ Key: JBWS-2627 URL: https://jira.jboss.org/jira/browse/JBWS-2627 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-cxf-3.2.0 -- 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, 6 months

2
9
0 / 0

[JBoss JIRA] Created: (JBWS-2235) Support for multiple schemas validation

by Alessio Soldano (JIRA)

Support for multiple schemas validation --------------------------------------- Key: JBWS-2235 URL: http://jira.jboss.com/jira/browse/JBWS-2235 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jbossws-native-3.0.1 Reporter: Alessio Soldano The schema validation feature currently support one imported schema only. We should support multiple schemas instead. -- 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, 7 months

2
5
0 / 0

[JBoss JIRA] Created: (JBWS-2576) Verify dependencies on outstanding CXF issues

by Alessio Soldano (JIRA)

Verify dependencies on outstanding CXF issues --------------------------------------------- Key: JBWS-2576 URL: https://jira.jboss.org/jira/browse/JBWS-2576 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-3.1.1 Before releasing we should check if some of the CXF issue we created have been solved and their fix released, so that the corresponding JBossWS issue can be solved. -- 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, 11 months

1
13
0 / 0

[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, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-2436) Look for eventual optimizations when scanning classes

by Alessio Soldano (JIRA)

Look for eventual optimizations when scanning classes ----------------------------------------------------- Key: JBWS-2436 URL: https://jira.jboss.org/jira/browse/JBWS-2436 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Alessio Soldano http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146807 -- 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

14 years

2
11
0 / 0

[JBoss JIRA] Created: (JBWS-2510) Error messages internationalization

by Alessio Soldano (JIRA)

Error messages internationalization ----------------------------------- Key: JBWS-2510 URL: https://jira.jboss.org/jira/browse/JBWS-2510 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Alessio Soldano Fix For: jbossws-native-3.1.1, jbossws-metro-3.1.1, jbossws-cxf-3.1.1 -- 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

14 years

2
11
0 / 0

[JBoss JIRA] Created: (JBWS-2461) Request / Response Resource Optimisation

by Darran Lofthouse (JIRA)

Request / Response Resource Optimisation ---------------------------------------- Key: JBWS-2461 URL: https://jira.jboss.org/jira/browse/JBWS-2461 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.0.5 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.0.6 There are a few points where the management of resources can be optimised, in these places we are relying on a few techniques that are leading to potential leaks. The first area to optimise is the use of ThreadLocals for DocumentBuilders etc - these should be optimised to be better related to the request / response. A second area relates to SwapableMemoryDataSource - something is needed to clean up files not automatically deleted from killed / crashed JVMs. Secondly relying on finalize to delete the files can lead to a large number of files on disk before GC especially with large heaps. Ideally these will be better associated with the current request to be cleaned up at the end of processing. Although these are two different problems I have grouped them together as the common problem is tracking resources with the request they really belong to. -- 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

14 years

3
7
0 / 0

[JBoss JIRA] Created: (JBWS-2379) Using a custom HandlerResolver on client while using WS-Security does not add ws-security header to soap envelope

by Yousuf Haider (JIRA)

Using a custom HandlerResolver on client while using WS-Security does not add ws-security header to soap envelope ----------------------------------------------------------------------------------------------------------------- Key: JBWS-2379 URL: https://jira.jboss.org/jira/browse/JBWS-2379 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-2.0.1.SP2 Environment: JBoss4.3 JDK1.5 Reporter: Yousuf Haider I have a webservice deployed as an EJB endpoint with the correct WS-Security Configuration (using UsernameToken) My standalone java client code looks like this: ReflectorEjbWsseApi port = null; Service service = (Service) Service.create(wsdlURL, serviceQName); service.setHandlerResolver(new CustomHandlerResolver); port = service.getPort(ReflectorEjbWsseApi.class); HandlerResolver hr = new HandlerResolver(); ((BindingProvider)port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, WebServiceConstants.USERNAME); ((BindingProvider)port).getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, WebServiceConstants.PASSWORD); URL securityURL = new File("jboss-wsse-client.xml").toURL(); ((StubExt)port).setSecurityConfig(securityURL.toExternalForm()); ((StubExt) port).setConfigName("Standard WSSecurity Client"); ((BindingProvider)port).getRequestContext().put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE); As you can see I am setting my own custom HandlerResolver. However by doing this I am somehow overriding the default HandlerChain which would have used the USERNAME_PROPERTY and PASSWORD_PROPERTY values and added the ws-security header to the soap message. When executing this code I get a SOAPFault from the server saying that the soap message does not contain a required header. javax.xml.ws.soap.SOAPFaultException: org.jboss.ws.core.CommonSOAPFaultException: This service requires <wsse:Security>, which is missing. If I don't set the handlerResolver by removing this line from my client: service.setHandlerResolver(new CustomHandlerResolver); the request goes through fine and I get a valid response. My own customhandlers do nothing but some logging activity. I should be able to use my own custom handlers with WS-Security. -- 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

14 years

3
6
0 / 0

[JBoss JIRA] Created: (JBWS-2215) Produce distributable docs from wiki

by Thomas Diesler (JIRA)

Produce distributable docs from wiki ------------------------------------ Key: JBWS-2215 URL: http://jira.jboss.com/jira/browse/JBWS-2215 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Thomas Diesler Assigned To: Heiko Braun Please automate the docs export and make it part of the SVN tag. -- 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

14 years, 1 month

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues May 2009