[JBoss JIRA] Created: (JBWS-2637) incorrect namespace for fault messages
by Bart Vanhaute (JIRA)
incorrect namespace for fault messages
--------------------------------------
Key: JBWS-2637
URL: https://jira.jboss.org/jira/browse/JBWS-2637
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.1.1
Environment: JBossAS-4.2.3.GA
Reporter: Bart Vanhaute
There is a problem with the namespace for web faults when this namespace is not the same as the namespace of the service. The type definition of the web faults has the correct namespace, but the reference to the type from the message part elements uses the name space qualifier (tns) of the service instead.
See the jboss forum for an example.
Note: I now tested this again with the 3.1.1 version, and the problem is still the same.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBWS-3067) Investigate why jaxws/samples/wssecurity test fails
by Richard Opalka (JIRA)
Investigate why jaxws/samples/wssecurity test fails
---------------------------------------------------
Key: JBWS-3067
URL: https://jira.jboss.org/browse/JBWS-3067
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Assignee: Alessio Soldano
This will not be JBossWS issue Alessio.
Could you report this issue to appropriate team?
I created this JIRA for tracking.
16:06:34,116 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to PostClassLoader: name=vfs:///home/opalka/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/target/test-libs/jaxws-samples-wssecurity-sign.war state=ClassLoader mode=Manual requiredState=PostClassLoader: org.jboss.deployers.spi.DeploymentException: Error during deploy: vfs:///home/opalka/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/target/test-libs/jaxws-samples-wssecurity-sign.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha5]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha5]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha5]
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:370) [:6.0.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
at org.jboss.system.server.jmx.MBeanServerWrapper.invoke(MBeanServerWrapper.java:138) [:6.0.0-SNAPSHOT (Build SVNTag:JBoss_6.0.0-SNAPSHOT date: 20100611)]
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_20]
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_20]
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_20]
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_20]
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_20]
at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_20]
at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_20]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_20]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_20]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
Caused by: java.lang.Error: Error visiting "/home/opalka/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/target/test-libs/jaxws-samples-wssecurity-sign.war/WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wssecurity/Hello.class"
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268) [jboss-classloading-vfs.jar:2.2.0.Alpha5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.Alpha5]
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.Alpha5]
at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.Alpha2]
at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.Alpha2]
at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90) [:1.0.0.Alpha2]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha5]
... 44 more
Caused by: java.lang.RuntimeException: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at org.jboss.scanning.plugins.visitor.IgnoreSetErrorHandler.handleError(IgnoreSetErrorHandler.java:57) [:1.0.0.Alpha2]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:91) [:1.0.0.Alpha2]
at org.jboss.scanning.annotations.plugins.AnnotationsScanningPlugin.visit(AnnotationsScanningPlugin.java:89) [:1.0.0.Alpha2]
at org.jboss.scanning.spi.helpers.ScanningPluginWrapper.visit(ScanningPluginWrapper.java:112) [:1.0.0.Alpha2]
at org.jboss.classloading.plugins.visitor.FederatedResourceVisitor.visit(FederatedResourceVisitor.java:101) [jboss-classloading.jar:2.2.0.Alpha5]
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264) [jboss-classloading-vfs.jar:2.2.0.Alpha5]
... 59 more
Caused by: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) [:1.6.0_20]
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) [:1.6.0_20]
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) [:1.6.0_20]
at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) [:1.6.0_20]
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) [:1.6.0_20]
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) [:1.6.0_20]
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) [:1.6.0_20]
at java.lang.Class.getAnnotations(Class.java:3050) [:1.6.0_20]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.readAnnotations(IntrospectionTypeInfoFactoryImpl.java:618) [jboss-reflect.jar:2.2.0.Alpha6]
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getAnnotations(IntrospectionTypeInfoFactoryImpl.java:126) [jboss-reflect.jar:2.2.0.Alpha6]
at org.jboss.reflect.plugins.InheritableAnnotationHolder.getDeclaredAnnotations(InheritableAnnotationHolder.java:95) [jboss-reflect.jar:2.2.0.Alpha6]
at org.jboss.reflect.plugins.ClassInfoImpl.getAnnotations(ClassInfoImpl.java:181) [jboss-reflect.jar:2.2.0.Alpha6]
at org.jboss.reflect.plugins.AbstractAnnotatedInfo.getUnderlyingAnnotations(AbstractAnnotatedInfo.java:63) [jboss-reflect.jar:2.2.0.Alpha6]
at org.jboss.scanning.plugins.visitor.ClassHierarchyResourceVisitor.handleClass(ClassHierarchyResourceVisitor.java:74) [:1.0.0.Alpha2]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.doVisit(ReflectResourceVisitor.java:108) [:1.0.0.Alpha2]
at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:86) [:1.0.0.Alpha2]
... 63 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBWS-3092) CXF Depends on SAAJ RI depends on JAXP RI
by Richard Opalka (JIRA)
CXF Depends on SAAJ RI depends on JAXP RI
-----------------------------------------
Key: JBWS-3092
URL: https://jira.jboss.org/browse/JBWS-3092
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Assignee: Alessio Soldano
Priority: Critical
Fix For: jbossws-cxf-4.0
Yet another argument against integrating CXF into JBoss.
We have xercesImpl.jar and xalan.jar in JBoss distro we don't like
and would like to remove it from there (unfortunately we don't have resources).
But with CXF another JAXP implementation comes to JBoss (in order to support IBM JDK).
Since now we will have two different JAXP implementations bundled with JBoss
although Java comes with JAXP inside.
We should use JAXP implementation comming with JDK using JAXP API not JAXP IMPL classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBWS-1716) Erroneous UTF-8 character encoding when marshalling on machines with non-UTF-8 default encoding
by floe fliep (JIRA)
Erroneous UTF-8 character encoding when marshalling on machines with non-UTF-8 default encoding
-----------------------------------------------------------------------------------------------
Key: JBWS-1716
URL: http://jira.jboss.com/jira/browse/JBWS-1716
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jbossws-1.2.1
Reporter: floe fliep
When sending a client request which includes a non-ASCII UTF-8 character such as the "ç" in "Français" on a machine which has the default character encoding set to something different than UTF-8, the encoding is erroneous. For example, the "ç" in the example above is marshalled on the network stream as 0xC3 0x83 0xC2 0xA7 instead of the legal UTF-8 sequence being 0xC3 0xA7, when the machine's default character set is set to MS1252 in this case (Windows).
A fix for this is setting the system property file.encoding=utf-8, but this causes as many problems elsewhere as it fixes (especially in the case of legacy platform-specific file reading) ... .
A forum post is highly likely to expose the same phenomenon: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030510#4030510
After some good hours of stepping through the JBossWS code, I discovered what I guess must be the culprit in the method XMLFragment.writeSourceInternal(Writer writer):
....
if (reader == null)
reader = new InputStreamReader(streamSource.getInputStream());
Here streamSource.getInputStream() is an already UTF-8 encoded stream. However, when a new instance of InputStreamReader is created around it, it will be set to the machine's default character encoding, thus effectively interpreting bytes from the UTF-8 stream in a different encoding scheme, resulting in corrupted data.
Each time data passes through the marschalling corruption is added, effectively worsening wrong character count when data is passed back and forth.
I would suggest attaching a reader to the StreamSource source instance var so that it keeps track of its encoding, but that might break things elsewhere ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBWS-3090) Deploy script does not remove jbossws-native-jaxws-ext.jar
by Magesh Kumar B (JIRA)
Deploy script does not remove jbossws-native-jaxws-ext.jar
----------------------------------------------------------
Key: JBWS-3090
URL: https://jira.jboss.org/browse/JBWS-3090
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-3.3.1
Environment: JBoss AS 5.1 + JBoss ESB + JDK 6.0
Reporter: Magesh Kumar B
Priority: Minor
When investigating JBoss ESB CXF integration JBESB-3046, the behavior is inconsistent from that of 3.2.1 release.
Instead of throwing java.lang.NoClassDefFoundError: javax/xml/ws/addressing/AddressingBuilder, 3.3.1 throws java.lang.ClassNotFoundException: org.jboss.ws.extensions.addressing.soap.SOAPAddressingBuilderImpl.
A closer look revealed that jbossws-native-jaxws-ext.jar is not removed from common and client directories.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBWS-3083) Avoid double Maven lifecycle run for building src and bin distributions
by Alessio Soldano (JIRA)
Avoid double Maven lifecycle run for building src and bin distributions
-----------------------------------------------------------------------
Key: JBWS-3083
URL: https://jira.jboss.org/browse/JBWS-3083
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-3.4.0, jbossws-metro-3.4.0, jbossws-native-3.4.0
Currently the build goes through two invocations of mvn package assembly:directory, one for building the deploy-artifacts structure and the other for creating the actual distribution. While it's currently not possible yet with our maven project structure to have multiple executions of the assembly plugin in the same run, we can in any case have the plugin run multiple assembly descriptors.
This should basically save some time while building src and bin distributions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months