December 2011 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3400) jaxws-tools-maven-plugin support for JBossWS 4

by Alessio Soldano (Created) (JIRA)

jaxws-tools-maven-plugin support for JBossWS 4 ---------------------------------------------- Key: JBWS-3400 URL: https://issues.jboss.org/browse/JBWS-3400 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jaxws-tools-maven-plugin Reporter: Alessio Soldano Assignee: Alessio Soldano -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] (JBWS-3399) Add WS-* samples into JBossWS-CXF binary distribution

by Alessio Soldano (Created) (JIRA)

Add WS-* samples into JBossWS-CXF binary distribution ----------------------------------------------------- Key: JBWS-3399 URL: https://issues.jboss.org/browse/JBWS-3399 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, productivity Affects Versions: jbossws-cxf-4.0.0.CR1 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.0 We should add the WS-* samples we already have (especially those using WS-Policy) to the binary distribution, which is the most commonly downloaded for each release. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3398) MetadataBuilder does not re-use WebserviceMetadata parsed into AS integration layer

by Alessio Soldano (Created) (JIRA)

MetadataBuilder does not re-use WebserviceMetadata parsed into AS integration layer ----------------------------------------------------------------------------------- Key: JBWS-3398 URL: https://issues.jboss.org/browse/JBWS-3398 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0.0.CR1 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-4.0 MetadataBuilder::processWSDDContribution(DDEndpoint endpoint, ArchiveDeployment dep) forces additional check / parse of webservices.xml descriptor while it should re-use the metadata coming from ASIL where that descriptor is already parsed. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3397) Remove final keywords from AbstractInvocationHandlerJSE (plus InvocationHandlerJAXRPC/WS) to let users extend functionality

by Robert Stupp (Created) (JIRA)

Remove final keywords from AbstractInvocationHandlerJSE (plus InvocationHandlerJAXRPC/WS) to let users extend functionality --------------------------------------------------------------------------------------------------------------------------- Key: JBWS-3397 URL: https://issues.jboss.org/browse/JBWS-3397 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: AS7.1 (jbossws-common-2.0.0.CR1) Reporter: Robert Stupp It would be nice to remove the final keyword from the method {{org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE#invoke}} and from the classes {{org.jboss.ws.common.invocation.InvocationHandlerJAXRPC}} {{org.jboss.ws.common.invocation.InvocationHandlerJAXWS}} to allow users to extend functionality. We need to intercept the final Java method call (in {{org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE#invoke}}) {{final Object retObj = implMethod.invoke(targetBean, args);}} and replace it with a call to some other code. I had to copy {{AbstractInvocationHandlerJSE}}, {{InvocationHandlerJAXWS}} and {{InvocationHandlerJAXRPC}} just to override the function {{invoke}}. -- 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, 11 months

5
4
0 / 0

[JBoss JIRA] (JBWS-3394) Add cxf dependency to as7 integration layer to support cxf anntation

by Jim Ma (Created) (JIRA)

Add cxf dependency to as7 integration layer to support cxf anntation -------------------------------------------------------------------- Key: JBWS-3394 URL: https://issues.jboss.org/browse/JBWS-3394 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf Affects Versions: jbossws-cxf-4.0.0.CR1 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.0 The cxf dependency is missing in deployment module, thus the annotation like @SchemaValidation can not be retrieved and processed correctly. -- 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

1
0
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-3393) Remove support for AS6 as target container

by Alessio Soldano (Created) (JIRA)

Remove support for AS6 as target container ------------------------------------------ Key: JBWS-3393 URL: https://issues.jboss.org/browse/JBWS-3393 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 This task is about removing the AS600/610 support in JBWS 4. That's not required anymore for tracking regressions considering the current AS 7 status and we need to apply some final cleanup that are possible removing AS6 support only. -- 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

2
1
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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues December 2011