August 2011 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-3294) Remove ws-eventing implementation from native

by Richard Opalka (JIRA)

Remove ws-eventing implementation from native --------------------------------------------- Key: JBWS-3294 URL: https://issues.jboss.org/browse/JBWS-3294 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Assignee: Richard Opalka The jbossws-native ws-eventing implementation is not being maintained / supported. Even more the WS-Eventing spec. is considered deprecated. The upcoming WS-Eventing from WS-RA specification is it's successor. See http://www.w3.org/2002/ws/ra/snapshots/cr/wseventing.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-3276) Implement support for POJO endpoints with no web.xml in archive

by Richard Opalka (JIRA)

Implement support for POJO endpoints with no web.xml in archive --------------------------------------------------------------- Key: JBWS-3276 URL: https://issues.jboss.org/browse/JBWS-3276 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-integration Reporter: Richard Opalka Fix For: jbossws-native-4.0, jbossws-cxf-4.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-3280) Avoid building Spring Bus when deployment has no spring descriptor

by Alessio Soldano (JIRA)

Avoid building Spring Bus when deployment has no spring descriptor ------------------------------------------------------------------ Key: JBWS-3280 URL: https://issues.jboss.org/browse/JBWS-3280 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano The DescriptorDeploymentAspect currently relies on Spring availability in the classloader for deciding to generate a default jbossws-cxf.xml. Generally speaking, we should probably go the "Spring" way only when the deployment comes with a jbossws-cxf.xml (and spring is actually available ;-)), so the user explicitly asked for that. We might even evaluate changing the logic in JBossWSBusFactory to avoid using Spring when no spring descriptor is found (basically the same the CXF 2.4 SpringBusFactory does in public Bus createBus(String cfgFiles[], boolean includeDefaults) and we override in our JBossWS version of that factory). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3251) org.w3c.dom.DOMException when create dispatch with EPR

by Jim Ma (JIRA)

org.w3c.dom.DOMException when create dispatch with EPR ------------------------------------------------------- Key: JBWS-3251 URL: https://issues.jboss.org/browse/JBWS-3251 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native, ws-addressing Affects Versions: jbossws-native-3.4.1 Reporter: Jim Ma Fix For: jbossws-native-4.0 0:40:43,972 INFO [STDOUT] WS ADDR=<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/Quickstart_bpel_simple_invoke/HelloWorldWS</Address><Metadata><wsam:ServiceName EndpointName="HelloWorldPort" xmlns="http://simple_invoke/helloworld" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">HelloWorldWSService</wsam:ServiceName></Metadata></EndpointReference> 10:40:44,153 ERROR [HandlerChainExecutor] Exception during handler processing org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it. at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown Source) at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source) at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source) at org.jboss.ws.core.soap.NodeImpl.appendChild(NodeImpl.java:481) at org.jboss.ws.core.soap.SOAPHeaderImpl.appendChild(SOAPHeaderImpl.java:198) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:264) at org.jboss.ws.core.soap.SOAPHeaderImpl.addChildElement(SOAPHeaderImpl.java:70) at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:233) at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:267) at org.jboss.ws.extensions.addressing.jaxws.WSAddressingClientHandler.handleOutbound(WSAddressingClientHandler.java:139) at org.jboss.wsf.common.handler.GenericHandler.handleMessage(GenericHandler.java:53) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:328) at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:146) at org.jboss.ws.core.jaxws.client.DispatchImpl.callRequestHandlerChain(DispatchImpl.java:640) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:256) at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:180) at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:147) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable$1.call(WebServiceClient.java:355) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:289) at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:246) at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable.call(WebServiceClient.java:231) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Only thing I am doing is: org.apache.ode.bpel.iapi.EndpointReference odeepr=mex.getEndpointReference(); javax.xml.ws.EndpointReference epr=null; if (odeepr != null) { if (odeepr instanceof org.apache.ode.bpel.epr.URLEndpoint) { org.apache.ode.bpel.epr.URLEndpoint url=(org.apache.ode.bpel.epr.URLEndpoint)odeepr; javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder builder= new javax.xml.ws.wsaddressing.W3CEndpointReferenceBuilder(); epr = builder.address(url.getUrl()) .serviceName(serviceName) .endpointName(port) .build(); System.out.println("WS ADDR="+epr); Creating the EPR from the ODE endpoint reference, and then if (epr != null) { dispatcher = service.createDispatch( epr, SOAPMessage.class, Service.Mode.MESSAGE, new javax.xml.ws.soap.AddressingFeature() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWS-3233) jbossws/services web view shows wrong port

by Steve Cassidy (JIRA)

jbossws/services web view shows wrong port ------------------------------------------ Key: JBWS-3233 URL: https://issues.jboss.org/browse/JBWS-3233 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss 4.3.0 CP08 running on RHEL 5 (5.6) - kernel version 2.6.18-238.1.1.el5 Reporter: Steve Cassidy Priority: Minor We have a JBoss installation where we have disabled port 8080 for security reasons (in jboss-web.deployer/server.xml). We listen on port 8443 on SSL and 8009 for AJP. However if I look at the web view of Web services (jbossws/services context path in a web browser) this shows the WSDLs of the services but the links are still showing ":8080" as the listening port (even though JBoss is not listening on port 8080). I undersdtand that it is possible to have JBoss listeing on multiple ports so hence it would not be clear what would be put here instead but for a simple example where Jboss is listening on port 8443 and not 8080 it seems wrong that 8080 is shown and not 8443. I understand that this is not the highetst priority issue ever but to make the product consistent could you please look at this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
2
0 / 0

[JBoss JIRA] Created: (JBWS-3288) Double slash in published endpoint address

by Alessio Soldano (JIRA)

Double slash in published endpoint address ------------------------------------------ Key: JBWS-3288 URL: https://issues.jboss.org/browse/JBWS-3288 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-3.4.1 Reporter: Alessio Soldano http://community.jboss.org/message/603293 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-3259) Unbale to deploy WAR+VDB into JBoss AS 5.1.0

by Hilal Mushtaque (JIRA)

Unbale to deploy WAR+VDB into JBoss AS 5.1.0 -------------------------------------------- Key: JBWS-3259 URL: https://issues.jboss.org/browse/JBWS-3259 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Reporter: Hilal Mushtaque Attachments: TestWS.zip Hi I am getting below given exception when I tried to deploy the generated war into JbossAS 5.1.0 along with the VDB file. I am using Teiid Designer 7.3.0 to generate war, I created a project having a single table with three fields of string type and generated the input/output xsd's, view and xmi's. Then I created a vdb configured it using the translator/jndi and generated the war & deployed the war. Then I deployed the war and vdb both on to the Jboss AS. (attached the project as well) ############################## org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/TestVDB.war/ at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: Cannot publish wsdl to: D:\jboss-5.1.0.GA\server\default\data\wsdl\TestVDB.war\TestVDB.wsdl at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:104) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.publishContractToFilesystem(EndpointImpl.java:84) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:238) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:481) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:112) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:110) at org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer.internalDeploy(WSDeploymentAspectDeployer.java:107) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) ... 29 more Caused by: java.io.IOException: Could not find WEB-INF/wsdl/EPCSchema_Input.xsd in the additional metadatafiles! at org.jboss.wsf.framework.deployment.ResourceResolverImpl.resolve(ResourceResolverImpl.java:121) at org.jboss.ws.core.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:181) at org.jboss.ws.core.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:208) at org.jboss.ws.core.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:208) at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:91) ... 38 more 07:13:54,681 INFO [TomcatDeployment] deploy, ctxPath=/jbossws 07:13:54,806 INFO [TomcatDeployment] deploy, ctxPath=/jmx-console 07:13:56,869 INFO [PROCESSOR] Clearing prepared plan cache 07:13:56,869 INFO [PROCESSOR] Clearing the resultset cache for vdb EPC1372VDB.1 07:13:56,900 INFO [RUNTIME] VDB "EPC1372VDB.1[DataPersistor[], EPCSchema[EPCSchema/oracle/dcorp], GetXml[GetXML/file/epcfile]]" deployed in active state. 07:13:56,916 INFO [PROCESSOR] Clearing prepared plan cache 07:13:56,916 INFO [PROCESSOR] Clearing the resultset cache for vdb EPC1373VDB.1 07:13:56,916 INFO [RUNTIME] VDB "EPC1373VDB.1[DataPersistor[], TRUNC_MY_SCHEMA[TRUNC_MY_SCHEMA/oracle/dcorp], EPCSchema[EPCSchema/oracle/dcorp], GetXml[GetXml/file/epcfile]]" deployed in active state. 07:13:56,916 INFO [PROCESSOR] Clearing prepared plan cache 07:13:56,916 INFO [PROCESSOR] Clearing the resultset cache for vdb EPC1374VDB.1 07:13:56,916 INFO [RUNTIME] VDB "EPC1374VDB.1[DataPersistor[], TRUNC_MY_SCHEMA[TRUNC_MY_SCHEMA/oracle/dcorp], GetXml[GetXml/file/epcfile], EPCSchema[EPCSchema/oracle/dcorp]]" deployed in active state. 07:13:56,931 INFO [PROCESSOR] Clearing prepared plan cache 07:13:56,931 INFO [PROCESSOR] Clearing the resultset cache for vdb TestVDB.1 07:13:56,931 INFO [RUNTIME] VDB "TestVDB.1[EPCSchema_Output_View[], EPCSchema[EPCSchema/oracle/dcorp], EPCSchema_Input[], EPCSchema_WS[], EPCSchema_Output[]]" deployed in active state. 07:13:57,072 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): DEPLOYMENTS IN ERROR: Deployment "vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/TestVDB.war/" is in error due to the following reason(s): java.io.IOException: Could not find WEB-INF/wsdl/EPCSchema_Input.xsd in the additional metadatafiles! ############################## Kindly revert ASAP -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWS-3215) Review the way testsuite is run using Maven

by Alessio Soldano (JIRA)

Review the way testsuite is run using Maven ------------------------------------------- Key: JBWS-3215 URL: https://issues.jboss.org/browse/JBWS-3215 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-native, productization Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 Instead of requiring us/users to do what follows to run the testsuite > mvn -Ptestsuite,jbossXYZ -DjbossXYZ.home=.. test we should probably be able to support something like: > mvn -DjbossXYZ.home=.. integration-test The move of non-unit tests to integration-test phase is being done as part of JBWS-3210, the rest is probably a matter of implicitly getting the target container from the jbossXYZ.home defined in the env and removing the testsuite profile / automatically enabling the testsuite modules, which just have integration tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (JBWS-3343) Support for both EJB3 and POJO WS endpoints in war archives

by Alessio Soldano (JIRA)

Support for both EJB3 and POJO WS endpoints in war archives ----------------------------------------------------------- Key: JBWS-3343 URL: https://issues.jboss.org/browse/JBWS-3343 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-native Reporter: Alessio Soldano Assignee: Jim Ma Fix For: jbossws-native-4.0, jbossws-cxf-4.0 As a consequence of supporting JSR109 v.1.3 it's required to support mixed set of EJB3 and POJO endpoints into war archive deployments. That basically makes the assumption behind the DeploymentType enum invalid. We need to move to an EndpointType concept and review most of the deployment aspects and some metadata to properly support this usecase. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3342) Issues with "/" context-root

by Alessio Soldano (JIRA)

Issues with "/" context-root ---------------------------- Key: JBWS-3342 URL: https://issues.jboss.org/browse/JBWS-3342 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Alessio Soldano Fix For: jbossws-cxf-4.0 A user reports issues when having an EAR deployment with application.xml specifying <context-root>/</context-root> for an inner WAR with POJO WS endpoints. Besides AS7 choking on that due to EndpointService trying to compute a ServiceName out of an empty String derived from that context-root, there seems to be a general problem with the jbossws-cxf stack with multiple "/" in the obtained endpoint address. A comparison with Native stack behaviour (reported to be OK) is suggested. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 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 August 2011