November 2011 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-3281) Create a migration guide to JBossWS 4.0 / AS 7 integration

by Alessio Soldano (JIRA)

Create a migration guide to JBossWS 4.0 / AS 7 integration ---------------------------------------------------------- Key: JBWS-3281 URL: https://issues.jboss.org/browse/JBWS-3281 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-native, productization Reporter: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 A migration guide from JBossWS 3.4.x to JBossWS 4.0 (and in particular to AS7 w/ JBossWS 4) should be included in the release documentation. At the moment the topic to be covered should be: - consequences for users due to changes in classloading (see JBossWS AS7 FAQ) - changes in API (new jbossws-api library, package refactorings, etc.) - changes in WS-* configuration - changes due to libraries upgrades (mainly due to dependencies coming from Apache CXF 2.4 upgrade) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
6
0 / 0

[JBoss JIRA] Created: (JBWS-3295) Change default folder for wsconsume generated sources

by Anders Hammar (JIRA)

Change default folder for wsconsume generated sources ----------------------------------------------------- Key: JBWS-3295 URL: https://issues.jboss.org/browse/JBWS-3295 Project: JBoss Web Services Issue Type: Enhancement Security Level: Public (Everyone can see) Components: jaxws-tools-maven-plugin Affects Versions: jbossws-jaxws-tools-maven-plugin-1.0.1.GA Environment: n/a Reporter: Anders Hammar Priority: Minor The Maven convention for generated sources is for those to be created under target/generated-sources/blabla. The AbstractWsConsumeMojo class specifies that sources be created under target/wsconsume/java (through the default-value of the sourceDirectory param). I suggest this is changed to "${project.build.directory}/generated-sources/wsconsume". (I don't see a need for adding a trailing "java".) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] (JBWS-3390) jax-ws-catalog.xml not being used with @WebServiceRef() annotation in JBoss AS 7.1.0.Beta1 "Tesla"

by Fred Welland (Created) (JIRA)

jax-ws-catalog.xml not being used with @WebServiceRef() annotation in JBoss AS 7.1.0.Beta1 "Tesla" -------------------------------------------------------------------------------------------------- Key: JBWS-3390 URL: https://issues.jboss.org/browse/JBWS-3390 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0.0.CR1 Environment: JBoss AS 7.1.0.Beta1 "Tesla" Fedora 15 (2.6.40.6-0.fc15.i686) java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) Server VM (build 20.2-b06, mixed mode) Reporter: Fred Welland Attachments: HelloWSWorld.jar, WebHello.war @WebServiceRef(wsdlLocation = "http://my.nowhereland.com/HelloWSWorld/Hello/Hello?wsdl") always try to resolve the host (my.nowhereland.com) even if there is a jax-ws-catalog.xml file that maps the location url to a path in the WAR. Here is thread detailing the issue: http://community.jboss.org/message/637964 The 2 packages detail are the parts to reproduce the problem (source code in jar/war). HelloWSWorld.jar: Exceedingly simple SLSB jar with a WS WebHello.war: JSF Web App that is simple client to the above WS ejb jar. Deployed to 'standalone' and just used the web console to deploy the modules. The same 2 products can be deployed to Glassfish 3.1.1. GF resolves the @WebServiceAnnotation() annotation and seems happy with using the mappings in the jax-ws-catalog.xml. The @PostConstruct() method can then re-assign ENDPOINT_ADDRESS_PROPERTY for WS invocation. In JBOSS as 7.1.0beta1 the following (bottom part of the stack trace) is tossed while the annotation is being processed: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://my.nowhereland.com/HelloWSWorld/Hello/Hello?wsdl'.: java.net.UnknownHostException: my.nowhereland.com at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:239) at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:186) at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:92) ... 76 more Caused by: java.net.UnknownHostException: my.nowhereland.com Of course the @PostContruct never gets the opportunity to execute and change the ENDPOINT_ADDRESS_PROPERTY. I have found that an annotation like: @WebServiceRef(wsdlLocation = "/WEB-INF/wsdl/Hello.wsdl") seems to make JBoss happy and the @PostContruct fires and things are OK. However, I don't know if this will work in GF. My objectives are: *to have our WAR work on both GF and JBOSS (and maybe others) *war code refers to our services via canonical service location *provide jax-ws-catalog mappings for local/in-war wsdl access *allow WAR code to override the canonical locations when they are in 'DEV-Mode' or detect some other run-time discriminator used to change the service location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

5
4
0 / 0

[JBoss JIRA] (JBWS-3373) port component link servlet on AS7

by Alessio Soldano (Created) (JIRA)

port component link servlet on AS7 ---------------------------------- Key: JBWS-3373 URL: https://issues.jboss.org/browse/JBWS-3373 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration, jbossws-native Reporter: Alessio Soldano Fix For: jbossws-native-4.0, jbossws-cxf-4.0 We used to have the portcomponentlink servlet deployed as part of the jbossws console war. On AS7 we're probably not going to have the jbossws console included in the application server build, so we need to properly integrate the portcomponentlink servlet. An idea might be to leverage the http api that's currently used for both the welcome page and the ws endpoint publisher the ws subsystem provides the xts ones to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

3
2
0 / 0

[JBoss JIRA] Created: (JBWS-3255) Unable to lookup AuthenticationManager

by Richard Opalka (JIRA)

Unable to lookup AuthenticationManager -------------------------------------- Key: JBWS-3255 URL: https://issues.jboss.org/browse/JBWS-3255 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Fix For: jbossws-native-4.0 12:18:01,235 ERROR [org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS] (http-nucleus%2F127.0.0.1-8080-2) SOAP request exception: org.jboss.ws.WSException: Unable to lookup AuthenticationManager at org.jboss.ws.extensions.security.operation.AuthorizeOperation.<init>(AuthorizeOperation.java:86) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.extensions.security.WSSecurityDispatcher.authorize(WSSecurityDispatcher.java:150) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.extensions.security.WSSecurityDispatcher.decodeMessage(WSSecurityDispatcher.java:101) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.extensions.security.jaxws.WSSecurityHandler.handleInboundSecurity(WSSecurityHandler.java:90) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer.handleInbound(WSSecurityHandlerServer.java:41) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.common.handler.GenericHandler.handleMessage(GenericHandler.java:53) [jbossws-common.jar:2.0.0-SNAPSHOT] at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:328) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:146) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callRequestHandlerChain(HandlerDelegateJAXWS.java:98) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.core.server.ServiceEndpointInvoker.callRequestHandlerChain(ServiceEndpointInvoker.java:129) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:176) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:527) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:316) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:222) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:147) [jbossws-native-core.jar:4.0.0-SNAPSHOT] at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:87) [jbossws-common.jar:2.0.0-SNAPSHOT] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:660) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta7.jar:7.0.0.Beta2-SNAPSHOT] at java.lang.Thread.run(Thread.java:636) [:1.6.0_20] Caused by: javax.naming.NameNotFoundException: Name 'env' not found in context '' at org.jboss.as.naming.util.NamingUtils.nameNotFoundException(NamingUtils.java:109) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.InMemoryNamingStore$NodeTraversingVisitor.visit(InMemoryNamingStore.java:355) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.InMemoryNamingStore$ContextNode.accept(InMemoryNamingStore.java:297) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.InMemoryNamingStore.lookup(InMemoryNamingStore.java:151) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:180) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:211) [jboss-as-naming-7.0.0.Beta2-SNAPSHOT.jar:7.0.0.Beta2-SNAPSHOT] at javax.naming.InitialContext.lookup(InitialContext.java:409) [:1.6.0_20] at org.jboss.ws.extensions.security.operation.AuthorizeOperation.<init>(AuthorizeOperation.java:80) [jbossws-native-core.jar:4.0.0-SNAPSHOT] ... 28 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
7
0 / 0

[JBoss JIRA] (JBWS-3391) wsprovide script fails with NoClassDefFoundError, 2x missing dependencies

by Jeremy Whiting (Created) (JIRA)

wsprovide script fails with NoClassDefFoundError, 2x missing dependencies ------------------------------------------------------------------------- Key: JBWS-3391 URL: https://issues.jboss.org/browse/JBWS-3391 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-cxf-4.0.0.CR1 Environment: Linux Reporter: Jeremy Whiting Priority: Minor The CR1 distribution is missing the log4j and getopt.jar libraries. When executing the wsprovide bash script the java command fails to execute because the files do not exist on the file system. Both are defined in the classpath. I get this error Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Priority Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Priority at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Could not find the main class: org.jboss.ws.tools.cmd.WSProvide. Program will exit. $ pwd /home/whitingjr/java/jboss/jbossws-cxf-bin-dist $ ls deploy/lib/log4j.jar ls: cannot access deploy/lib/log4j.*: No such file or directory $ cp /home/whitingjr/jboss-home/client/log4j.jar ./deploy/lib/ $ ./deploy/bin/wsprovide.sh Exception in thread "main" java.lang.NoClassDefFoundError: gnu/getopt/LongOpt at org.jboss.ws.tools.cmd.WSProvide.parseArguments(WSProvide.java:89) at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:82) Caused by: java.lang.ClassNotFoundException: gnu.getopt.LongOpt at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) ... 2 more $ cp /home/whitingjr/jboss-home/client/getopt.jar deploy/lib/ $ ./deploy/bin/wsprovide.sh Error: endpoint implementation was not specified! WSProvideTask generates portable JAX-WS artifacts for an endpoint implementation. usage: WSProvide [options] <endpoint class name> options: -h, --help Show this help message -k, --keep Keep/Generate Java source -w, --wsdl Enable WSDL file generation -c, --classpath=<path> The classpath that contains the endpoint -o, --output=<directory> The directory to put generated artifacts -r, --resource=<directory> The directory to put resource artifacts -s, --source=<directory> The directory to put Java source -e, --extension Enable SOAP 1.2 binding extension -q, --quiet Be somewhat more quiet -t, --show-traces Show full exception stack traces -l, --load-provider Load the provider and exit (debug utility) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
1
0 / 0

[JBoss JIRA] (JBWS-3389) Fix org.jboss.test.ws.jaxws.cxf.jms_http.JMSHTTPEndpointDeploymentTestCase regression

by Richard Opalka (Created) (JIRA)

Fix org.jboss.test.ws.jaxws.cxf.jms_http.JMSHTTPEndpointDeploymentTestCase regression ------------------------------------------------------------------------------------- Key: JBWS-3389 URL: https://issues.jboss.org/browse/JBWS-3389 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Reporter: Richard Opalka Assignee: Alessio Soldano 11:11:08,254 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.deployment.unit."jaxws-cxf-jms-http-deployment.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-cxf-jms-http-deployment.war".INSTALL: Failed to process phase INSTALL of deployment "jaxws-cxf-jms-http-deployment.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29] Caused by: javax.xml.ws.WebServiceException: java.lang.RuntimeException: javax.naming.NameNotFoundException: ConnectionFactory -- service jboss.naming.context.java.ConnectionFactory at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:350) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:88) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:239) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:509) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:109) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:132) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:74) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT] ... 5 more Caused by: java.lang.RuntimeException: javax.naming.NameNotFoundException: ConnectionFactory -- service jboss.naming.context.java.ConnectionFactory at org.apache.cxf.transport.jms.JMSFactory.getConnectionFactoryFromJndi(JMSFactory.java:87) at org.apache.cxf.transport.jms.JMSConfiguration.getOrCreateWrappedConnectionFactory(JMSConfiguration.java:442) at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:105) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:112) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:97) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:836) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:341) ... 13 more Caused by: javax.naming.NameNotFoundException: ConnectionFactory -- service jboss.naming.context.java.ConnectionFactory at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:88) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177) at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:82) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:213) at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_29] at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:154) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152) at org.apache.cxf.transport.jms.JMSFactory.getConnectionFactoryFromJndi(JMSFactory.java:75) ... 21 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (JBWS-3387) JAXRPC SchemaBindingBuilder can't rely on jaxws integration classloader (AS7)

by Alessio Soldano (Created) (JIRA)

JAXRPC SchemaBindingBuilder can't rely on jaxws integration classloader (AS7) ----------------------------------------------------------------------------- Key: JBWS-3387 URL: https://issues.jboss.org/browse/JBWS-3387 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-native-4.0 org.jboss.ws.core.jaxrpc.binding.jbossxb.SchemaBindingBuilder needs to provide the proper jaxrpc integration classloader when building the JBossWSEntityResolver, otherwise that's not going to be able to get jbossws-entities.properties resource when the JBossWS-CXF stack is installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-3176) JbossWS native client handler issue

by Gary Brown (JIRA)

JbossWS native client handler issue ----------------------------------- Key: JBWS-3176 URL: https://jira.jboss.org/browse/JBWS-3176 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.2.2 Environment: RiftSaw 2.2.0.CR1, JBossAS 5.1.0.GA, JBossWS 3.2.2.GA (installed as part of the RiftSaw installation), JBossESB 4.9, JDK6, Savara 1.1.0.CR1 Reporter: Gary Brown I have a BPEL process that invokes two JAX-WS services, one after the other. The first invocation does not trigger the client handler configured in the 'standard-jaxws-client-config.xml' file, however the second invocation does. In terms of the environment, when you have a clean JBossAS environment, install the ESB, install Riftsaw using "ant deploy -Ddatabase=hsql -Dws.version=3.2.2.GA" (which will install jbossws native 3.2.2.GA). For now don't worry about installing Savara, as it is only configuring the client handler. May be easier for you to use your own handler, rather than installing yet another project - although if you have problems reproducing the issue, then may need to install Savara in case that is the problem. Attached are the various artifacts that need to be deployed into the server's deploy folder. The policy-quote-queue-service.xml will need to be deployed first. SoapUI can be used to send the following messages. The instructions for running the example are: 1) Send <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pol="http://www.example.org/policyQuote"> <soapenv:Header/> <soapenv:Body> <pol:policyQuote> <pol:receivePolicyQuote> <pol:requestDate>2009-01-01</pol:requestDate> <pol:task>receivePolicyQuote</pol:task> <pol:policyQuoteInfo> <pol:policyType>AUTO</pol:policyType> <pol:vehicleYear>2004</pol:vehicleYear> <pol:driverName>Bill Smith</pol:driverName> <pol:ssn>412345678</pol:ssn> <pol:dlNumber>987654321</pol:dlNumber> <pol:age>30</pol:age> <pol:numberOfAccidents>0</pol:numberOfAccidents> <pol:numberOfTickets>0</pol:numberOfTickets> <pol:creditScore>0</pol:creditScore> <pol:price>0</pol:price> </pol:policyQuoteInfo> </pol:receivePolicyQuote> </pol:policyQuote> </soapenv:Body> </soapenv:Envelope> to this URL http://localhost:8080/PolicyQuoteProcessServiceService/PolicyQuoteProcess... 2) Then wait until you see the following on the console: Received Driving Record Request for: Bill Smith 3) Then send: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:drv="http://dmv.com/drivingRecord"> <soapenv:Header/> <soapenv:Body> <drv:drivingRecordResponse> <drv:name>Bill Smith</drv:name> <drv:ssn>412345678</drv:ssn> <drv:dlNumber>987654321</drv:dlNumber> <drv:age>30</drv:age> <drv:numberOfTickets>2</drv:numberOfTickets> <drv:numberOfAccidents>1</drv:numberOfAccidents> </drv:drivingRecordResponse> </soapenv:Body> </soapenv:Envelope> to http://localhost:8080/PolicyQuoteProcessServiceService/DrivingRecordCallb... (The example has been provided by Jeff DeLong). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

4
4
0 / 0

[JBoss JIRA] Created: (JBWS-3327) Populate MessageContext.WSDL_* props before POST handler execution

by Alessio Soldano (JIRA)

Populate MessageContext.WSDL_* props before POST handler execution ------------------------------------------------------------------ Key: JBWS-3327 URL: https://issues.jboss.org/browse/JBWS-3327 Project: JBoss Web Services Issue Type: Enhancement Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Alessio Soldano Fix For: jbossws-native-4.0 Currently POST handlers do not have access to WSDL_* props in the MessageContext as those are populated in MessageContextJAXWS::setOperationMetaData(..) which is run between POST and ENDPOINT handler execution for incoming server side messages. We should evaluate computing and setting the operationMetaData before POST handlers execution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues November 2011