June 2013 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3657) web service migration from jboss 4.2GA to Jboss-7.1.2, Wrong number of arguments exception is coming

by kalidas kk (JIRA)

kalidas kk created JBWS-3657: -------------------------------- Summary: web service migration from jboss 4.2GA to Jboss-7.1.2, Wrong number of arguments exception is coming Key: JBWS-3657 URL: https://issues.jboss.org/browse/JBWS-3657 Project: JBoss Web Services Issue Type: Enhancement Security Level: Public (Everyone can see) Environment: rhel6.3, openldap 2.4, jdk1.6 Reporter: kalidas kk while deploying the webservice in jboss 7 we are getting below exception in soap body: -------------------------------------- 12:22:51,271 INFO [org.apache.cxf.services.LoginServiceService.LoginServicePort.LoginService] (http-/192.168.10.22:8080-1) Inbound Message ---------------------------- ID: 11 Address: http://192.168.10.22:8080/was/LoginService Encoding: ISO-8859-1 Http-Method: POST Content-Type: text/xml Headers: {Accept=[text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2], connection=[Keep-Alive], Content-Length=[331], content-type=[text/xml], host=[192.168.10.22:8080], SOAPAction=[""], user-agent=[Java1.4.2_05]} Payload: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><env:Body><n1:login xmlns:n1="http://ws.was.wassystem.com/" xsi:nil="true"/></env:Body></env:Envelope> -------------------------------------- 12:22:51,276 ERROR [org.jboss.as.webservices.invocation.InvocationHandlerJAXWS] (http-/192.168.10.22:8080-1) JBAS015594: Method invocation failed with exception: wrong number of arguments: java.lang.IllegalArgumentException: wrong number of arguments at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_45] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_45] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:111) at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178) at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:66) at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [rt.jar:1.6.0_45] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_45] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_45] at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:237) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:95) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:156) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:225) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:145) at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135) at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:559) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45] 12:22:51,301 INFO [org.apache.cxf.phase.PhaseInterceptorChain] (http-/192.168.10.22:8080-1) Application {http://ws.was.wassystem.com/}LoginServiceService#{http://ws.was.wassystem.com/}login has thrown exception, unwinding now: java.lang.IllegalArgumentException: wrong number of arguments 12:22:51,306 INFO [org.apache.cxf.services.LoginServiceService.LoginServicePort.LoginService] (http-/192.168.10.22:8080-1) Outbound Message --------------------------- ID: 11 Response-Code: 500 Encoding: ISO-8859-1 Content-Type: text/xml Headers: {} Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>wrong number of arguments</faultstring><detail><ns1:Exception xmlns:ns1="http://ws.was.wassystem.com/"/></detail></soap:Fault></soap:Body></soap:Envelope> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3648) WS-Policy code-first improvements and tooling

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3648?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3648: --------------------------------------- Initial doc added at https://docs.jboss.org/author/display/JBWS/WS-Policy > WS-Policy code-first improvements and tooling > --------------------------------------------- > > Key: JBWS-3648 > URL: https://issues.jboss.org/browse/JBWS-3648 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf, productivity > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > I'd like to see some kind of ws-policy oriented tooling in JBossWS. Ideally we should provide some mechanisms for basic code-first development; currently stuff like ws-security configuration through policies is actually contract based: the user is expected to either provide a wsdl with proper policies or to use policy attachment, which is basically the same, writing the actual policy assertion is required. > An idea could be to have a group of pre-defined policy assertions' sets for known scenarios (for ws-security those could be based e.g. on the Oasis WS-Security Policy Examples [1]). Each set would be composed of 'placement points' with a policy to be attached at each of those points. We'd then possibly have a custom CXF FactoryBeanListener to be registered in the FactoryBeanListenerManager; the new listener would perform something similar to what the PolicyAnnotationListener does (based on the @Policies/@Policy in the code), that is attaching policies to the proper attach points. An additional step would be to support merging (effective policy through Neethi?) multiple sets at the same time (say, you want e.g. a specific ws-security set plus a ws-rm set). > With such thing, we could provide the initial sets and let users pick the sets they want for a given endpoint (perhaps through a custom annotation, or possibly better specifying the sets' names within a property in a selected Endpoint Config). > The initial policy sets could be stored as xml files in one of the jbossws-cxf jars and we could provide a mechanism for reading additional ones from the current classpath (to let users add additional ones). > Finally, this would open up to further tooling improvements; e.g. 1) wsprovide could be enhanced to process the @EndpointConfig annotation, get the policy sets and produce a ws-policy enabled wsdl, 2) we could even provide an 'educational' gui tool showing assertions enabled/disabled depending on the selected sets, etc. > [1] http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3613) WSConsume fails on IBM JDK6

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3613?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3613: ---------------------------------- Fix Version/s: (was: jbossws-cxf-4.1.4) > WSConsume fails on IBM JDK6 > --------------------------- > > Key: JBWS-3613 > URL: https://issues.jboss.org/browse/JBWS-3613 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, tools-jaxws > Affects Versions: jbossws-cxf-4.1.2 > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-4.2 > > > When running on IBM JDK6, following exception is thrown; the custom implementation of ForwardingJavaFileManager introduced in JBWS-3589 catches ClassNotFoundException only to detect if a class is loadable by the module classloader of the current JAXWS SPI Provider... > java.lang.NoClassDefFoundError: javax.realtime.RealtimeThread > at com.ibm.oti.vm.VM.findClassOrNull(Native Method) > at com.ibm.oti.vm.BootstrapClassLoader.loadClass(BootstrapClassLoader.java:62) > at java.lang.ClassLoader.loadClass(ClassLoader.java:643) > at java.lang.ClassLoader.loadClass(ClassLoader.java:645) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:346) > at java.lang.ClassLoader.loadClass(ClassLoader.java:619) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:371) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:131) > at java.lang.ClassLoader.loadClass(ClassLoader.java:645) > at java.lang.ClassLoader.loadClass(ClassLoader.java:619) > at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl$CustomJavaFileManager.list(CXFConsumerImpl.java:371) > at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2077) > at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1781) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) > at com.sun.tools.javac.code.Symbol$PackageSymbol.members(Symbol.java:596) > at com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:119) > at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:509) > at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:446) > at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:387) > at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:819) > at com.sun.tools.javac.code.Symbol.complete(Symbol.java:386) > at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:758) > at com.sun.tools.javac.comp.Enter.complete(Enter.java:451) > at com.sun.tools.javac.comp.Enter.main(Enter.java:429) > at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:819) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727) > at com.sun.tools.javac.main.Main.compile(Main.java:353) > at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:115) > at org.apache.cxf.common.util.Compiler.internalJava6Compile(Compiler.java:232) > at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:194) > at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:144) > at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:122) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164) > at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412) > at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103) > at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) > at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:281) > at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:279) > at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:104) > at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:600) > at org.jboss.modules.Module.run(Module.java:268) > at org.jboss.modules.Main.main(Main.java:344) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3611) Allow JBossWebservicesMetaData to be passed to EndpointPublisher.publish in SPI

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3611?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3611: ---------------------------------- Fix Version/s: (was: jbossws-cxf-4.1.4) > Allow JBossWebservicesMetaData to be passed to EndpointPublisher.publish in SPI > ------------------------------------------------------------------------------- > > Key: JBWS-3611 > URL: https://issues.jboss.org/browse/JBWS-3611 > Project: JBoss Web Services > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Reporter: Magesh Bojan > Assignee: Alessio Soldano > Priority: Critical > Fix For: jbossws-cxf-4.2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3654) Intermittent failure in EndpointPublisherImpl

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3654?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3654: --------------------------------------- https://github.com/wildfly/wildfly/pull/4688 > Intermittent failure in EndpointPublisherImpl > --------------------------------------------- > > Key: JBWS-3654 > URL: https://issues.jboss.org/browse/JBWS-3654 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.1.3 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > > junit.framework.ComparisonFailure: expected:<1[]> but was:<1[java.lang.IllegalStateException: JBWS022105: Cannot modify endpoint in state STARTED: jboss.ws:context=ep-publish-test,endpoint=pattern]> > at junit.framework.Assert.assertEquals(Assert.java:85) > at junit.framework.Assert.assertEquals(Assert.java:91) > at org.jboss.test.ws.publish.EndpointPublishTestCase.testEndpointPublish(EndpointPublishTestCase.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at junit.framework.TestSuite.run(TestSuite.java:238) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:137) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:144) > at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3656) Upgrade Apache Santuario to 1.5.5

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3656: ------------------------------------- Summary: Upgrade Apache Santuario to 1.5.5 Key: JBWS-3656 URL: https://issues.jboss.org/browse/JBWS-3656 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Fix For: jbossws-cxf-4.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3655) wsdlLocation in ejb-jar throws error for schema import

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/JBWS-3655?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated JBWS-3655: --------------------------------- Attachment: awesome.zip > wsdlLocation in ejb-jar throws error for schema import > ------------------------------------------------------ > > Key: JBWS-3655 > URL: https://issues.jboss.org/browse/JBWS-3655 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: jbossws-cxf-4.1.3 > Reporter: Mustafa Musaji > Assignee: Jim Ma > Attachments: awesome.zip > > > The use case is as follows: > EAR that contains EJB-JAR and JAR. The JAR contains wsdl in META-INF but referenced from wsdlLocation in EJB-JAR to avoid JBoss generating it's own WSDL without external schema). On deployment the error we get is: > {noformat} > Caused by: java.io.IOException: JBAS015526: Child 'META-INF/wsdl/Awesome_schema1.xsd' not found for VirtualFile: "/content/awesome.ear/awesome-ejb-0.0.1-SNAPSHOT.jar" > at org.jboss.as.webservices.util.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:61) > at org.jboss.as.webservices.util.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:71) > at org.jboss.ws.common.deployment.ResourceResolverImpl.resolve(ResourceResolverImpl.java:76) > at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:228) > at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:253) > at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:257) > at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:92) > ... 14 more > {noformat} > Removing the wsdlLocation from the ejb-jar fixes this but the use case is that JBoss should be able to load the schema from the classpath since the wsdl was loaded from the classpath. > I will attach a test case to the JIRA to replicate this behaviour. It's a maven build that use cxf-java2ws-plugin to generate the xsd imports and WSDL in the JAR file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3655) wsdlLocation in ejb-jar throws error for schema import

by Mustafa Musaji (JIRA)

Mustafa Musaji created JBWS-3655: ------------------------------------ Summary: wsdlLocation in ejb-jar throws error for schema import Key: JBWS-3655 URL: https://issues.jboss.org/browse/JBWS-3655 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-cxf-4.1.3 Reporter: Mustafa Musaji Assignee: Jim Ma Attachments: awesome.zip The use case is as follows: EAR that contains EJB-JAR and JAR. The JAR contains wsdl in META-INF but referenced from wsdlLocation in EJB-JAR to avoid JBoss generating it's own WSDL without external schema). On deployment the error we get is: {noformat} Caused by: java.io.IOException: JBAS015526: Child 'META-INF/wsdl/Awesome_schema1.xsd' not found for VirtualFile: "/content/awesome.ear/awesome-ejb-0.0.1-SNAPSHOT.jar" at org.jboss.as.webservices.util.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:61) at org.jboss.as.webservices.util.VirtualFileAdaptor.findChild(VirtualFileAdaptor.java:71) at org.jboss.ws.common.deployment.ResourceResolverImpl.resolve(ResourceResolverImpl.java:76) at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:228) at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:253) at org.jboss.ws.common.utils.AbstractWSDLFilePublisher.publishSchemaImports(AbstractWSDLFilePublisher.java:257) at org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:92) ... 14 more {noformat} Removing the wsdlLocation from the ejb-jar fixes this but the use case is that JBoss should be able to load the schema from the classpath since the wsdl was loaded from the classpath. I will attach a test case to the JIRA to replicate this behaviour. It's a maven build that use cxf-java2ws-plugin to generate the xsd imports and WSDL in the JAR file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3654) Intermittent failure in EndpointPublisherImpl

by Jim Ma (JIRA)

Jim Ma created JBWS-3654: ---------------------------- Summary: Intermittent failure in EndpointPublisherImpl Key: JBWS-3654 URL: https://issues.jboss.org/browse/JBWS-3654 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-cxf, jbossws-integration Affects Versions: jbossws-cxf-4.1.3 Reporter: Jim Ma Assignee: Jim Ma Fix For: jbossws-cxf-4.2 junit.framework.ComparisonFailure: expected:<1[]> but was:<1[java.lang.IllegalStateException: JBWS022105: Cannot modify endpoint in state STARTED: jboss.ws:context=ep-publish-test,endpoint=pattern]> at junit.framework.Assert.assertEquals(Assert.java:85) at junit.framework.Assert.assertEquals(Assert.java:91) at org.jboss.test.ws.publish.EndpointPublishTestCase.testEndpointPublish(EndpointPublishTestCase.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:137) at junit.framework.TestResult.runProtected(TestResult.java:128) at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:144) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3645) WorkQueueManager is not registered in JMX Server when cxf.management is enabled

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3645?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3645: ---------------------------------- Issue Type: Bug (was: Feature Request) > WorkQueueManager is not registered in JMX Server when cxf.management is enabled > ------------------------------------------------------------------------------- > > Key: JBWS-3645 > URL: https://issues.jboss.org/browse/JBWS-3645 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: jbossws-cxf > Affects Versions: jbossws-cxf-4.1.3 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: jbossws-cxf-4.2 > > > MBean of WorkQueueManger is not registered when If cxf.management is enabled in jboss-webservices.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 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 June 2013