[JBossWS] - Re: Exception while deploying the webservice using jax-ws
by tpawankumar
Hi All,
I have resolved ClassCastException issue.
Now i am getting this exception
org.jboss.deployment.DeploymentException: Cannot create service endpoint; - nested throwable: (java.lang.annotation.AnnotationTypeMismatchException: Incorrectly
typed data found for annotation element public abstract javax.xml.bind.annotati
on.XmlAccessType javax.xml.bind.annotation.XmlAccessorType.value() (Found data o
f type Ljavax/xml/bind/annotation/AccessType;.FIELD))
at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException
(DeploymentException.java:53)
at org.jboss.ws.integration.jboss42.DeployerInterceptor.create(DeployerI
nterceptor.java:83)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.
create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterce
ptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy46.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
I have created Schema classes by using JAXB 2.0 and i have deployed on JBoss 4.2.1.
Please any one suggest on this.
Thanks in Advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098115#4098115
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098115
16 years, 8 months
[JBossWS] - Re: Raw Style webservices
by happyspace
I had the same problem with the web service provider style of web service. I am using jbossas 5 beta two with jbossws 1.2.1. It appears that jboss beta two uses xerces-2.7.1. After assembling all of the sources I found the ?real? cause of the NAMESPACE_ERR exception to be of mixing DOM 1 vs DOM 2 APIs.
When a document is set for the SOAP body the dom tree for that document is copied into the soap body. If that document is made up of ElementImpl nodes rather than ElementNSImpl the call into Xerces fails with the now familiar NAMESPACE_ERR. To work around this issue change your code to use ?createElementNS?.
I happen to be using Castor, which creates documents composed of ElementImpl nodes. I have a work around using the TransformerFactory of Xalan to create a new doc tree but would rather not have to copy the document twice.
The details:
SOAPBodyImpl
SOAPBodyElement addDocument(Document doc)
creates a soapFactory and begins the copy of elements from the document into the soapBody with the default as deep through soapFactory.createElement(rootElement). In SOAPFactoryImpl createElement(Element domElement, boolean deep) an assumption is made that the element passed in is an ElementNSImpl (has a localName).
SOAPFactoryImpl
?
| public SOAPElement createElement(Element domElement, boolean deep) throws SOAPException
| {
| if (domElement == null)
| throw new IllegalArgumentException("Source node cannot be null");
|
| if (domElement instanceof SOAPElement)
| return (SOAPElement)domElement;
|
| String localName = domElement.getLocalName();
| String prefix = domElement.getPrefix() != null ? domElement.getPrefix() : "";
| String nsURI = domElement.getNamespaceURI() != null ? domElement.getNamespaceURI() : "";
| ?
In the case of an ElementImpl the localName is null as well as the prefix, ElementImpl will have the field name set. Thus when DOMUtils createElement(String localPart, String prefix, String url) is called the localPart == null but the prefix is an empty string.
DOMUtils
public static Element createElement(String localPart, String prefix, String uri)
| {
| Document doc = getOwnerDocument();
| if (prefix == null || prefix.length() == 0)
| {
| log.trace("createElement {" + uri + "}" + localPart);
| return doc.createElementNS(uri, localPart);
| }
| else
| {
| log.trace("createElement {" + uri + "}" + prefix + ":" + localPart);
| return doc.createElementNS(uri, prefix + ":" + localPart);
| }
| }
?
So the call into Xerces for createElementNS fails on setName(String namespaceURI, String qname) in ElementNSImpl as noted in the comment in the Xerces code:
anonymous wrote : //NAMESPACE_ERR:
| //1. if the qualified name is 'null' it is malformed.
| //2. or if the qualifiedName is null and the namespaceURI is different from null,
| // We dont need to check for namespaceURI != null, if qualified name is null throw DOMException.
ElementNSImpl.java
private void setName(String namespaceURI, String qname) {
|
| String prefix;
| // DOM Level 3: namespace URI is never empty string.
| this.namespaceURI = namespaceURI;
| if (namespaceURI != null) {
| //convert the empty string to 'null'
| this.namespaceURI = (namespaceURI.length() == 0) ? null : namespaceURI;
| }
|
| int colon1, colon2 ;
|
| //NAMESPACE_ERR:
| //1. if the qualified name is 'null' it is malformed.
| //2. or if the qualifiedName is null and the namespaceURI is different from null,
| // We dont need to check for namespaceURI != null, if qualified name is null throw DOMException.
| if(qname == null){
| String msg =
| DOMMessageFormatter.formatMessage(
| DOMMessageFormatter.DOM_DOMAIN,
| "NAMESPACE_ERR",
| null);
| throw new DOMException(DOMException.NAMESPACE_ERR, msg);
| }
Test Code:
The following snippet shows the exception.
boolean createNS = false;
| DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
| documentBuilderFactory.setNamespaceAware(true);
| DocumentBuilder builder = documentBuilderFactory.newDocumentBuilder();
| document = builder.newDocument();
|
| if(createNS){
| Element element = document.createElementNS(null, "Moo");
| document.appendChild(element);
| }
| else
| {
| // Causes the NAMESPACE_ERR to be thrown
| Element element = document.createElement("Moo");
| element.appendChild(document.createTextNode(messageType));
| }
|
|
| MessageFactory messageFactory = MessageFactory.newInstance(SOAPConstants.SOAP_1_1_PROTOCOL);
| message = messageFactory.createMessage();
|
| SOAPEnvelope envelope = message.getSOAPPart().getEnvelope();
| SOAPBody body = envelope.getBody();
|
| body.addDocument(document);
Documentation:
http://xerces.apache.org/xerces-j/apiDocs/org/apache/xerces/dom/ElementNS...
vs
http://xerces.apache.org/xerces-j/apiDocs/org/apache/xerces/dom/ElementIm...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098072#4098072
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098072
16 years, 8 months
[JBossWS] - Concurrency issue in request handler chain
by bcowan
I have entered bug report JBWS-1859 to describe a bug we experienced when JBoss is restarted. If client applications are still actively making web service requests during the restart, the handler chain was usually populated with too many copies of the handlers. This doesn't seem to cause a major problem unless WS Security is active. In this case, the first WS Security handler removes the wsse header, so any subsequent WS Security handler throws an exception. As a result, the client receives the message "This service requires <wsse:Security>, which is missing" even though the header was included. Once this error starts to happen, the server will not recover until it's restarted.
Sample client and server code is attached to the bug report, and I've also included patch information on how to fix it.
Bruce
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097960#4097960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097960
16 years, 8 months