January 2010 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-2899) Remove WSAspectizedDeployersFactory from stack specific configs

by Richard Opalka (JIRA)

Remove WSAspectizedDeployersFactory from stack specific configs --------------------------------------------------------------- Key: JBWS-2899 URL: https://jira.jboss.org/jira/browse/JBWS-2899 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-jaxrpc, jbossws-metro, jbossws-native Reporter: Richard Opalka Assignee: Alessio Soldano The following commit breaks AS IL abstraction and since now all stacks are using it directly not via SPI: On 01/25/2010 11:21 AM, jbossws-commits(a)lists.jboss.org wrote: > Author: alessio.soldano(a)jboss.com > Date: 2010-01-25 05:21:43 -0500 (Mon, 25 Jan 2010) > New Revision: 11480 > > Modified: > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/ws/extensions/wsrm/server/RMDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/wsf/stack/jbws/EagerInitializeDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/wsf/stack/jbws/EventingDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/wsf/stack/jbws/PublishContractDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/wsf/stack/jbws/ServiceEndpointInvokerDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/java/org/jboss/wsf/stack/jbws/UnifiedMetaDataDeploymentAspect.java > stack/native/branches/jaxrpc-cxf/modules/core/src/main/resources/jbossws-native-config-as6.xml > Log: > Using new AbstractDeploymentAspect + moving WSAspectizedDeployerFactory to stack specific config file > > Modified: stack/native/branches/jaxrpc-cxf/modules/core/src/main/resources/jbossws-native-config-as6.xml > =================================================================== > --- stack/native/branches/jaxrpc-cxf/modules/core/src/main/resources/jbossws-native-config-as6.xml 2010-01-25 10:15:58 UTC (rev 11479) > +++ stack/native/branches/jaxrpc-cxf/modules/core/src/main/resources/jbossws-native-config-as6.xml 2010-01-25 10:21:43 UTC (rev 11480) > @@ -2,6 +2,17 @@ > > <deployment xmlns="urn:jboss:bean-deployer:2.0"> > > +  > + <bean name="WSAspectizedDeployersFactory" class="org.jboss.webservices.integration.deployers.WSAspectizedDeployersFactory"> > + <constructor> > + <parameter> > + <inject bean="Deployers"/> > + </parameter> > + </constructor> > + <incallback method="addDeployer"/> > + <uncallback method="removeDeployer"/> > + </bean> > + >  > <bean name="WSEndpointRegistry" class="org.jboss.wsf.framework.management.ManagedEndpointRegistry"> > <property name="mbeanServer"><inject bean="WSMBeanServerLocator" property="mbeanServer"/></property> > > _______________________________________________ > jbossws-commits mailing list > jbossws-commits(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbossws-commits I know this is just a prototype ATM but before before merging to trunks it should be fixed. AFAIR it is somehow related to the class loaders hack in WSDeploymentAspectDeployer. I suggest the following solution instead of the aforementioned one: * move WSAspectizedDeployersFactory back to stack-agnostic-jboss-beans.xml * in WSDeploymentAspectDeployer.internalUn/Deploy() methods do: final ClassLoader oldCL = Thread.currentThread().getContextClassLoader(); // TODO: protect with security actions helper class final ClassLoader newCL = this.aspect.getClass().getClassLoader(); try { Thread.currentThread().setContextClassLoader(newCL); // TODO: protect with security actions helper class this.aspect.start(dep); } finally { Thread.currentThread.setContextClassLoader(oldCL); // TODO: protect with security actions helper 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

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2896) Fix unguarded calls to Logger.debug()

by Richard Opalka (JIRA)

Fix unguarded calls to Logger.debug() ------------------------------------- Key: JBWS-2896 URL: https://jira.jboss.org/jira/browse/JBWS-2896 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-metro, jbossws-native Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-3.3.1, jbossws-metro-3.3.1, jbossws-cxf-3.3.1 Some background: http://blogs.jboss.org/blog/dimitris/2005/04/01/AC08547736BD16504BEC955AE... Consider - moving Logger.debug() to Logger.trace() - protect debug calls with if (debug) statement -- 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 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-2894) wsrunclient doesn't put jaxws-rt.jar in classpath

by Aleksandar Kostadinov (JIRA)

wsrunclient doesn't put jaxws-rt.jar in classpath ------------------------------------------------- Key: JBWS-2894 URL: https://jira.jboss.org/jira/browse/JBWS-2894 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-native-3.1.2 Environment: SOA-P 5.0 Reporter: Aleksandar Kostadinov wsrunclient.sh/bat doesn't put jaxws-rt.jar in program's classpath. I noticed this because I wanted to test the scripts shipped with SOA-P 5.0. As many samples suggest I wrote a test client that uses the com.sun.xml.ws.Closeable interface. It seems to me that since examples in the wiki like http://community.jboss.org/wiki/JBossWS-MetroWS-ReliableMessagingTutorial... suggest that to be used, it should also be in classpath as constructed by wsrunclient. I hope jbossws dev team could look at wsrunclient to check there are no other obvious mistakes. -- 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 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-2892) Conflicting operations in 2 WS within the same archive and package

by Martin Vecera (JIRA)

Conflicting operations in 2 WS within the same archive and package ------------------------------------------------------------------ Key: JBWS-2892 URL: https://jira.jboss.org/jira/browse/JBWS-2892 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.2 Reporter: Martin Vecera Priority: Critical Attachments: Quickstart_helloworld_ejb3.jar I have two web services with the sayHello() operation. The first WS requires a string parameter, the second does not have any. Both WS are in the same package (see the attached jar). The following exception is thrown when you try to deploy it. If the services are deployed as two separate archives, the problem disappears. org.jboss.ws.WSException: arg0 is not a valid property on class org.jboss.soa.esb.samples.quickstart.helloworld_ejb3.jaxws.SayHello at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getElementPropertyAccessor(JAXBContextImpl.java:936) at org.jboss.ws.metadata.accessor.JAXBAccessorFactory.create(JAXBAccessorFactory.java:49) at org.jboss.ws.metadata.umdm.EndpointMetaData.createAccessor(EndpointMetaData.java:715) at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitializeAccessors(EndpointMetaData.java:671) at org.jboss.ws.metadata.umdm.EndpointMetaData.initializeInternal(EndpointMetaData.java:543) at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitialize(EndpointMetaData.java:531) at org.jboss.ws.metadata.umdm.ServiceMetaData.eagerInitialize(ServiceMetaData.java:433) at org.jboss.ws.metadata.umdm.UnifiedMetaData.eagerInitialize(UnifiedMetaData.java:194) at org.jboss.wsf.stack.jbws.EagerInitializeDeploymentAspect.start(EagerInitializeDeploymentAspect.java:48) at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:129) at org.jboss.wsf.container.jboss50.deployer.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:76) at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:60) at org.jboss.wsf.container.jboss50.deployer.WebServiceDeployerEJB.internalDeploy(WebServiceDeployerEJB.java:113) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) ... 24 more -- 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 months

1
4
0 / 0

[JBoss JIRA] Commented: (JBWS-1566) Invalid wsdl using @XmlSchema annotations on Types

by Lucas Toledo (JIRA)

[ https://jira.jboss.org/jira/browse/JBWS-1566?page=com.atlassian.jira.plug... ] Lucas Toledo commented on JBWS-1566: ------------------------------------ Hi there, I'm using jboss-4.2.1.GA and I'm having the same problem when running jboss and trying to create a service client to send a rpc/encoded request: javax.xml.rpc.Service service = servicefactory.createService(new URL(wsdlURL), serviceQN); How do I install the patch posted above? many thanks, Lucas > Invalid wsdl using @XmlSchema annotations on Types > -------------------------------------------------- > > Key: JBWS-1566 > URL: https://jira.jboss.org/jira/browse/JBWS-1566 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-native > Affects Versions: jbossws-1.2.0 > Environment: JBossAS-4.0.5, jdk 5, jbossws 1.2.0.GA > Reporter: Robert Mlekus > Assignee: Heiko Braun > Fix For: jbossws-2.0.0 > > Attachments: JBWS-1566-JbossWS-Samples-001.patch > > > While the @javax.xml.bind.annotation.XmlSchema annotation within the package-info.java of an class not inheriting from other packages works perfectly, JBossWS generates the following error for derived datatypes: > <code> > 14:35:02,173 ERROR [ServiceEndpointPublisher] Cannot obtain waURL for: webservice-test.ear/webservic > e-test.jar > 14:35:02,283 ERROR [JBossXSErrorHandler] [domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolv > e.4.2]::Message=src-resolve.4.2: Error resolving component 'ns1:aClass'. It was detected that 'ns1:a > Class' is in namespace 'http://test.org/wsclient/a', but components from this namespace are not refe > renceable from schema document 'null'. If this is the incorrect namespace, perhaps the prefix of 'ns > 1:aClass' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag sh > ould be added to 'null'. > <code> > The Parameter classes causing this problem are a.AClass, b.Bclass defined in the packages a, and b with the following package-info.java @XmlSchema annotations: > The following examples will be attached as a patch for the jbossws-samples, too but are given here for a short summary on the problem. > file a/package-info.java: > ------ > @javax.xml.bind.annotation.XmlSchema(namespace = http://test.org/wsclient/a" ) > package a; > ------ > > file a/AClass.java: > ------ > package a; > public class AClass { > int a; > > public int getA() { > return a; > } > public void setA(int testInt) { > this.a = testInt; > } > } > ------ > file b/package-info.java: > ------ > @javax.xml.bind.annotation.XmlSchema(namespace = http://test.org/wsclient/b" ) > package b; > ------ > > file b/BClass.java > ------ > package b; > public class BClass extends a.AClass { > String b; > > public String getB() { > return b; > } > public void setB(String testString) { > this.b = testString; > } > } > ------ > > The relevant part of the generated WSDL (which is visible under jbossws/service is: > <xs:schema targetNamespace="http://test.org/wsclient/b" version="1.0"> > <xs:complexType name="bClass"> > <xs:complexContent> > <xs:extension base="ns1:aClass"> > <xs:sequence> > <xs:element minOccurs="0" name="b" type="xs:string"/> > </xs:sequence> > </xs:extension> > </xs:complexContent> > </xs:complexType> > </xs:schema> > <xs:schema targetNamespace="http://test.org/wsclient/a" version="1.0"> > <xs:complexType name="aClass"> > <xs:sequence> > <xs:element name="a" type="xs:int"/> > </xs:sequence> > </xs:complexType> > </xs:schema> > > where the declaration of bClass references the ns1 namespace without declaring it. > The same thing happens when aClass is aggreagated by bClass. -- 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 months

1
0
0 / 0

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

2
1
0 / 0

[JBoss JIRA] Updated: (JBWS-1119) Add support for fault signing and encryption

by Alessio Soldano (JIRA)

[ https://jira.jboss.org/jira/browse/JBWS-1119?page=com.atlassian.jira.plug... ] Alessio Soldano updated JBWS-1119: ---------------------------------- Fix Version/s: community contributions Assignee: (was: Alessio Soldano) > Add support for fault signing and encryption > -------------------------------------------- > > Key: JBWS-1119 > URL: https://jira.jboss.org/jira/browse/JBWS-1119 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ws-security > Affects Versions: jbossws-native-3.0.1 > Reporter: Jason T. Greene > Fix For: community contributions > > > Add the ability to sign faults. WS-Security faults, will of course be unsigned. -- 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 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues January 2010