[JBoss JIRA] Created: (JBWS-3232) 10:56:49, 561 ERROR [stderr] (http-8080-1) javax.naming.NameNotFoundException: Name 'service' not found in context 'env'
by Richard Opalka (JIRA)
10:56:49,561 ERROR [stderr] (http-8080-1) javax.naming.NameNotFoundException: Name 'service' not found in context 'env'
-----------------------------------------------------------------------------------------------------------------------
Key: JBWS-3232
URL: https://issues.jboss.org/browse/JBWS-3232
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
10:56:49,560 ERROR [stderr] (http-8080-1) ServletClient:init() Exception: javax.naming.NameNotFoundException: Name 'service' not found in context 'env'
10:56:49,561 ERROR [stderr] (http-8080-1) javax.naming.NameNotFoundException: Name 'service' not found in context 'env'
10:56:49,561 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.util.NamingUtils.nameNotFoundException(NamingUtils.java:90)
10:56:49,561 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.InMemoryNamingStore$NodeTraversingVisitor.visit(InMemoryNamingStore.java:355)
10:56:49,561 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.InMemoryNamingStore$ContextNode.accept(InMemoryNamingStore.java:311)
10:56:49,561 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.InMemoryNamingStore$NodeTraversingVisitor.visit(InMemoryNamingStore.java:357)
10:56:49,561 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.InMemoryNamingStore$ContextNode.accept(InMemoryNamingStore.java:311)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.InMemoryNamingStore.lookup(InMemoryNamingStore.java:155)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:180)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:211)
10:56:49,562 ERROR [stderr] (http-8080-1) at javax.naming.InitialContext.lookup(InitialContext.java:409)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.jboss.test.ws.jaxws.jbws3140.ServletTestClient.init(ServletTestClient.java:49)
10:56:49,562 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:955)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
10:56:49,563 ERROR [stderr] (http-8080-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
10:56:49,564 ERROR [stderr] (http-8080-1) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
10:56:49,564 ERROR [stderr] (http-8080-1) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
10:56:49,564 ERROR [stderr] (http-8080-1) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
10:56:49,564 ERROR [stderr] (http-8080-1) at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3226) AS7 jboss-service.xml parsing problem
by Richard Opalka (JIRA)
AS7 jboss-service.xml parsing problem
-------------------------------------
Key: JBWS-3226
URL: https://issues.jboss.org/browse/JBWS-3226
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
12:02:04,647 ERROR [org.jboss.msc] (pool-2-thread-6) MSC-00001: Failed to start service jboss.deployment.unit.jaxws-jbws1854.sar.PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit.jaxws-jbws1854.sar.PARSE: Failed to process phase PARSE of deployment "jaxws-jbws1854.sar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:112)
at org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse service xml ["/content/jaxws-jbws1854.sar/META-INF/jboss-service.xml"]
at org.jboss.as.service.ServiceDeploymentParsingProcessor.deploy(ServiceDeploymentParsingProcessor.java:94)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108)
... 4 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,9]
Message: Unexpected element 'server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:98)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
at org.jboss.as.service.ServiceDeploymentParsingProcessor.deploy(ServiceDeploymentParsingProcessor.java:87)
... 5 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3223) Runtime ws classloader setup on AS7
by Alessio Soldano (JIRA)
Runtime ws classloader setup on AS7
-----------------------------------
Key: JBWS-3223
URL: https://issues.jboss.org/browse/JBWS-3223
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-integration, jbossws-native
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
One of the design requirements around JBoss AS 7 is hiding implementation classes from user classpath. However, we need to ensure users can use basic JAXWS functionalities (and any other feature covered by JSR specs) from any servlet and ejb3. Basically, we need to make sure client side WS functionalities are always available (whenever the WS subsystem is on), while having the API (JAXWS, JWS, SAAJ, etc.) libs only available on user classpath.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3224) Review the jbossws-spi ServiceLoader to allow for passing a classloader in
by Alessio Soldano (JIRA)
Review the jbossws-spi ServiceLoader to allow for passing a classloader in
--------------------------------------------------------------------------
Key: JBWS-3224
URL: https://issues.jboss.org/browse/JBWS-3224
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-native
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
The JBossWS-SPI ServiceLoader currently heavily relies on the TCCL for every resolution. We need to add an option for passing in the classloader to be used and to review every call points, in order for using the proper classloader (i.e. just use the TCCL for resolution implying the possibility for users to influence the result through META-INF/services/.. declarations in the deployment, otherwise directly use the classloader from the jbossws integration modules)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3218) Don't use apache logger, use jboss one
by Richard Opalka (JIRA)
Don't use apache logger, use jboss one
--------------------------------------
Key: JBWS-3218
URL: https://issues.jboss.org/browse/JBWS-3218
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-cxf-4.0
14:38:31,386 INFO [org.jboss.wsf.framework.management.DefaultEndpointRegistry] (pool-2-thread-1) remove: jboss.ws:context=jaxws-samples-wsa,endpoint=AddressingService
14:38:31,391 ERROR [org.jboss.msc] (pool-2-thread-1) MSC-00001: Failed to start service jboss.deployment.unit.jaxws-samples-wsa.war.INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit.jaxws-samples-wsa.war.INSTALL: Failed to process phase INSTALL of deployment "jaxws-samples-wsa.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:89)
at org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at org.jboss.test.ws.jaxws.samples.wsa.ServiceImpl.<init>(ServiceImpl.java:40)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_20]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [:1.6.0_20]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [:1.6.0_20]
at java.lang.reflect.Constructor.newInstance(Constructor.java:532) [:1.6.0_20]
at java.lang.Class.newInstance0(Class.java:372) [:1.6.0_20]
at java.lang.Class.newInstance(Class.java:325) [:1.6.0_20]
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.newInstance(NonSpringBusHolder.java:164)
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:98)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:102)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:119)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.internalDeploy(AspectDeploymentProcessor.java:77)
at org.jboss.as.webservices.deployers.TCCLDeploymentProcessor.deploy(TCCLDeploymentProcessor.java:41)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:85)
... 4 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3217) JBossWS SPI - NoClassDefFoundError: org/jboss/logging/Logger
by Richard Opalka (JIRA)
JBossWS SPI - NoClassDefFoundError: org/jboss/logging/Logger
------------------------------------------------------------
Key: JBWS-3217
URL: https://issues.jboss.org/browse/JBWS-3217
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Assignee: Richard Opalka
15:24:32,413 ERROR [org.jboss.msc] (pool-2-thread-4) MSC-00001: Failed to start service jboss.deployment.unit.jaxws-jbws2999.jar.PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit.jaxws-jbws2999.jar.PARSE: Failed to process phase PARSE of deployment "jaxws-jbws2999.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:89)
at org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: java.lang.NoClassDefFoundError: org/jboss/logging/Logger
at org.jboss.wsf.spi.metadata.webservices.WebserviceDescriptionMetaData.<clinit>(WebserviceDescriptionMetaData.java:42)
at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parseWebserviceDescription(WebservicesFactory.java:245)
at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parseWebservices(WebservicesFactory.java:231)
at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.parse(WebservicesFactory.java:201)
at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.load(WebservicesFactory.java:137)
at org.jboss.wsf.spi.metadata.webservices.WebservicesFactory.loadFromVFSRoot(WebservicesFactory.java:124)
at org.jboss.as.webservices.deployers.WSDescriptorDeploymentProcessor.deploy(WSDescriptorDeploymentProcessor.java:48)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:85)
... 4 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBWS-3214) MTOM attachment decoding for digest does not respect "XML Schema Part 2: Datatypes Second Edition" standard
by rouadec (JIRA)
MTOM attachment decoding for digest does not respect "XML Schema Part 2: Datatypes Second Edition" standard
-----------------------------------------------------------------------------------------------------------
Key: JBWS-3214
URL: https://issues.jboss.org/browse/JBWS-3214
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.1.2
Reporter: rouadec
While setting up a communication between a jboss 5.1.0GA using the standard web-services stack (I get "X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1" in my HTTP headers) and a datapower appliance we came to an issue regarding the MTOM messages we exchange.
The messages are transferred with binary attachements using MTOM, they are also signed.
The signature is applied on the message with the binary attachement encoded in base64.
The signatures do not match since the digest of the body do not match since the base64 encoded version of the attachement used to calculate the digest is different :
- jboss enforces a limit on line length of base 64-encoded data to 76 characters
- datapower do not and use a base64 form on one line.
After checking the documentations describing this standard I think the way datapower does it is the correct one.
http://www.w3.org/TR/soap12-mtom/#mime-serialization points to http://www.w3.org/TR/2005/REC-xop10-20050125/#introduction which in turns points to http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#base64Binary which states that :
"For compatibility with older mail gateways, [RFC 2045] suggests that base64 data should have lines limited to at most 76 characters in length. This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors."
"Note: For some values the canonical form defined above does not conform to [RFC 2045], which requires breaking with linefeeds at appropriate intervals."
Am I correct in my assumption?
Is this behaviour configurable on the Jboss side of things?
Antoine
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months