December 2009 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-2199) Injection abstraction

by Thomas Diesler (JIRA)

Injection abstraction --------------------- Key: JBWS-2199 URL: http://jira.jboss.com/jira/browse/JBWS-2199 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- 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, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (JBWS-2694) Enable simpler approach to disable chunked encoding

by Darran Lofthouse (JIRA)

Enable simpler approach to disable chunked encoding --------------------------------------------------- Key: JBWS-2694 URL: https://jira.jboss.org/jira/browse/JBWS-2694 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jbossws-native-3.2.0 By default JBossWS will send messages using chunked encoding, however a number of servers, proxy servers and load balancers do not support chunked encoding. The setting to disable this is not simple as it is in the configuration, this should be made simpler by also allowing it to be disabled on the request context as well. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-2400) Rewrite large attachment testcase

by Alessio Soldano (JIRA)

Rewrite large attachment testcase --------------------------------- Key: JBWS-2400 URL: https://jira.jboss.org/jira/browse/JBWS-2400 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-metro Reporter: Alessio Soldano The JBWS2000 testcase lives in framework but currently fails with JBossWS-Metro because of a java.lang.OutOfMemoryError on client side. This can be prevented enabling the chunked transfer which seems to be off by default with Metro: ((BindingProvider)port).getRequestContext().put("com.sun.xml.ws.transport.http.client.streaming.chunk.size", 8192); Unfortunately we still get a OOME on server side so, more generally, we should split this test and rewrite the Metro one using the available feature for large attachments (StreamingAttachment). See https://metro.dev.java.net/guide/Large_Attachments.html . -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBWS-2369) WS client uses WSSE settings from the WSDL file, ignoring client side settings

by Alan Feng (JIRA)

WS client uses WSSE settings from the WSDL file, ignoring client side settings ------------------------------------------------------------------------------ Key: JBWS-2369 URL: https://jira.jboss.org/jira/browse/JBWS-2369 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: ws-security Affects Versions: jbossws-native-3.0.4 Environment: JBoss AS 4.2.3.GA + JBoss WS 3.0.4 Native Reporter: Alan Feng When a SOAP service specifies its WSSE requirements, they are published in the WSDL, including the location and the passwords of the keystore and truststore files. These settings are usually specific to that SOAP server. On the client side, according to the wiki, the location and the password of the keystore and truststore files are specified in via JVM system properties. However, the dynamic WS client is using the WS-Security settings from the WSDL file, ignoring the client side system properties. -- 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, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2410) Implement @PostConstruct and @Predestroy annotations support for POJO based endpoints (JSR 109 conformance)

by Richard Opalka (JIRA)

Implement @PostConstruct and @Predestroy annotations support for POJO based endpoints (JSR 109 conformance) ----------------------------------------------------------------------------------------------------------- Key: JBWS-2410 URL: https://jira.jboss.org/jira/browse/JBWS-2410 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-metro Affects Versions: jbossws-metro-3.0.4, jbossws-metro-3.0.3, jbossws-metro-3.0.2, jbossws-metro-3.0.1, jbossws-metro-3.0.0 Reporter: Richard Opalka Priority: Optional For inspiration see SVN commits related to JBWS-2256 for native -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2209) Username Token JAAS integration

by Alessio Soldano (JIRA)

Username Token JAAS integration ------------------------------- Key: JBWS-2209 URL: http://jira.jboss.com/jira/browse/JBWS-2209 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ws-security Reporter: Alessio Soldano Assigned To: Alessio Soldano Ideally we would need the Metro stack to have the same degree of JAAS integration the native stack has (i.e. authentication and authorization delegated to JBoss Security). -- 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, 10 months

1
7
0 / 0

[JBoss JIRA] Created: (JBWS-2879) Multiple threads: getPort Hangs on 100% CPU with fast infoset on asynchronous invocation

by Hajo Krabbenhöft (JIRA)

Multiple threads: getPort Hangs on 100% CPU with fast infoset on asynchronous invocation ---------------------------------------------------------------------------------------- Key: JBWS-2879 URL: https://jira.jboss.org/jira/browse/JBWS-2879 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.1 Environment: jboss-5.1.0 GA debian 64 bit Reporter: Hajo Krabbenhöft Hi, i'm caching an instance of javax.xml.ws.Service. I cache the results of getPort in a ThreadLocal. When i use multiple parallel asynchronous invocations, this approach does not seem to work, so i invoke getPort for each asynchronous invocation. I have 8 threads using a web service running in parallel on a i7. After about 20h of work, all my worker threads are hanging on: "pool-41-thread-7" prio=10 tid=0x00007f8cc469d400 nid=0x156a runnable [0x000000004691a000..0x0000000046921ba0] java.lang.Thread.State: RUNNABLE at java.util.HashMap.put(HashMap.java:374) at java.util.HashSet.add(HashSet.java:200) at org.jboss.ws.metadata.umdm.FeatureSet.addFeature(FeatureSet.java:63) at org.jboss.ws.metadata.umdm.EndpointMetaData.addFeature(EndpointMetaData.java:375) at org.jboss.ws.core.jaxws.client.ClientFeatureProcessor.processFeature(ClientFeatureProcessor.java:84) at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.initWebserviceFeatures(ServiceDelegateImpl.java:537) at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:526) at javax.xml.ws.Service.getPort(Service.java:607) at com.spratpix.subdomains.ThreadLocalWebserviceProxy.getAsyncPort(ThreadLocalWebserviceProxy.java:47) Here is how i use getPort protected T getAsyncPort() { long t0 = System.nanoTime(); try { return service.getPort(portClass, new FastInfosetFeature()); } finally { long dt = System.nanoTime() - t0; TimingInterceptor.callChain.addInvocationWithMethod(method, dt); } } And the problematic web service call seems to be public Future<Boolean> PutFileAsync(String domain, String type, String filename, S3Object file, AsyncHandler<Boolean> asyncHandler); -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Gerald Turner (JIRA)

Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" ------------------------------------------------------------------------- Key: JBWS-2680 URL: https://jira.jboss.org/jira/browse/JBWS-2680 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.0.5 Environment: JBossAS 4.2.3 with JBossWS 3.0.5 Reporter: Gerald Turner Priority: Optional An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: <login-config> <auth-method>BASIC</auth-method> <realm-name>EJBServiceEndpointServlet Realm</realm-name> </login-config> On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-2793) Support of SOAP header code generation for implicit headers

by Gopi Chand Uppala (JIRA)

Support of SOAP header code generation for implicit headers ------------------------------------------------------------ Key: JBWS-2793 URL: https://jira.jboss.org/jira/browse/JBWS-2793 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Gopi Chand Uppala AT&T needs a feature in wsconsume tool, which should provide an option to generate code for implicit headers in WSDL. Sun's metro supports this option as a parameter (-XadditionalHeaders) on their wsimport tool and we are looking for a similar option in wsconsume tool. We do have a requirement to generate these implicit headers as operational parameters in the code. Here is the Sun's metro reference: https://jax-ws.dev.java.net/guide/SOAP_headers.html#Mapping_additional_WS... -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1444) Adding Java 5 Generics for Webservices

by Olivier PEPIN (JIRA)

Adding Java 5 Generics for Webservices -------------------------------------- Key: JBWS-1444 URL: http://jira.jboss.com/jira/browse/JBWS-1444 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jbossws-1.0.3 Environment: All Reporter: Olivier PEPIN It would be really convinient to make jboss WS and jsr-181 support Generics in a Webservice interface. ie: @WebMethod public ContentSet getContent() { ... } with: public class ContentSet<T> { T[] items; .... .... } On Jboss 4.0.5 (jboss-ws 1.0.3), the generated wsdl does not generate the correct types and the webservice dos not work. Comment from Thomas Diesler: his is not yet supported. You could create a feature request in jira. -- 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, 10 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues December 2009