Exception when using #SchemaValidation annotation on JAX-WS endpoint in Weblogic - java

I am trying to get schema validation working for a JAX-WS Web Service deployed on Weblogic 10.3.3.
According to the documentation, this should be as simple as adding the annotation
"#SchemaValidation" to the endpoint class. However when I try this the following exception is thrown when the application is deployed:
Caused by: javax.xml.ws.WebServiceException:
Annotation#com.sun.xml.internal.ws.developer.SchemaValidation
(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler)
is not recognizable,
atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature
should be marked with #FeatureConstructor
at com.sun.xml.ws.binding.WebServiceFeatureList.getWebServiceFeatureBean(WebServiceFeatureList.java:169)
at com.sun.xml.ws.binding.WebServiceFeatureList.parseAnnotations(WebServiceFeatureList.java:141)
The error message is complaining that "com.sun.xml.internal.ws.developer.SchemaValidationFeature" does not have a constructor annotated with #FeatureConstructor. When I look at that class, it sure seems to have one:
#com.sun.xml.internal.ws.api.FeatureConstructor(value={"handler"})
public SchemaValidationFeature(java.lang.Class arg0);
I have googled around but cannot find any reference to this more than this fellow unfortunate soul who did not get any answers. It would be great if someone could point me in the right direction because at this moment I am stuck.

SchemaValidation annotation is working, but make sure you're importing correct class.
com.sun.xml.ws.developer.SchemaValidation
instead of
com.sun.xml.internal.ws.developer.SchemaValidation
The second class is bundled with JDK by default. The first one (used by weblogic) comes from glassfish.jaxws.rt_XXX.jar, so you may need to add this jar to your classpath explicitly.

I have faced the same problem recently.
To overcome this, I added the tag
<validation-request>true</validation-request>
to the file weblogic-webservices.xml
This enabled SOAP request validation on the app-server.
XML Structure of weblogic-webservices.xml
Note : I have not been able to use the #SchemaValidation tag successfully, but the above way - works as expected.

Related

Java service using Jersey won't deploy to Jboss

I'm trying to build a Java service that other services could call.
This service is not a WS, but is calling a RestfulWS.
I'm really just building a wrapper around this call. This would find the correct data it needs, set up the JSON for the call. Get a response and send it back up.
Was told to use Jersey for this. Trying to set up all the pom.xml to use Jersey.
Building code works fine, it is when the deploy to the server happens that things fail.
I get the error -- "JBAS011232: Only one JAX-RS Application Class allowed. "
I don't have a web.xml, which I guess is used to skip some ResetEasy files.
I do have exclusions in pom.xml and jboss-deployment-structure.xml.
I still get the error when deploy happens. Not really sure what else to check.
It looks like you have a problem with JAX-RS dependencies. JBoss already has its own implementation of JAX-RS and probably that’s causing the issue. Some solutions are already suggested here Jboss error: Only one JAX-RS Application Class allowed

JAX-WS Validate Schema in WebLogic with #SchemaValidation

I wasn't able to find the solution and I found more people stuck in the same problem so I will post it here.
By default a JAX-WS server (at least for WebLogic) will not validate the message received with its associated schema.
This can lead to a lot of problems since any invalid value (wrong xsd:dateTime format, letters on a number field, etc) will result in a null value in the Java object, including mandatory fields.
What I need to do is a simple validation that should be provided by the server.
import com.sun.xml.internal.ws.developer.SchemaValidation;
#Stateless
#WebService(portName="ValidatedService")
#SchemaValidation
public class ValidatedService {
public void operation(#WebParam(name="request") ValidatedRequest request) {
/* do stuff */
}
}
For some reason when I was trying to use the provided schema validation I was getting the following exception:
Caused By: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.internal.ws.developer.SchemaValidation(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler) is not recognizable, atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I do not wish to implement any custom validator. The server should provided this type of service with simple and straightforward configuration.
The problem was: I was using the wrong package for #SchemaValidation.
The correct class that worked for me is com.sun.xml.ws.developer.SchemaValidation, which is provided in the file mw_home\modules\glassfish.jaxws.rt_1.3.0.0_2-1-5.jar (using WLS 10.3.6).
In the previous code segment I was referencing the wrong package: com.sun.xml.internal... but using the one provided by WebLogic worked instantly.
If you are using Maven and using the bundled JAR as dependency you might not have this library in the classpath, which led me to the problem. You need to add it to your classpath via dependency (provided scope only) and reference the correct package for that class name in your JAX-WS WebService class (an abstract class won't do it).
More information in the Enabling Schema Validation on the Server page.
This schema validation is enough for me at the moment since I do not need any custom behavior.
In my case: Maven project with many modules. I got the next error when was trying to deploy application into tomcat:
failed to parse runtime descriptor: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.ws.developer.SchemaValidation(handler=class com.sun.xml.ws.server.DraconianValidationErrorHandler) is not recognizable, at least one constructor of class com.sun.xml.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I resolved problem by don't including jaxws-rt.jar in WEB-INF/lib.
It appears that this library already exists in the tomcat/lib folder.
Just tuned up pom.xml, setted provided scope for this dependency entry.
Now all works fine.

SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message

I want to run a java application which calls a web service. Everything works fine from the netbeans ide, but fails when I run the .jar generated. What could be the problem?
How can I check the content type that the error is pointing at?
the error says: "SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message. com.sun.xml.messaging.saaj.MessageImpl identifyContentType"
EDIT
I am realizing that the problem could be originated by the fact that the web service that Im consuming uses a custom data type, but I have no idea where to look.
Please help
Your question lacks the details that would help identify your problem (like, what web container are you using, some source code, etc) but I've encountered and resolved this same problem. I'm using Tomcat with Eclipse and apparently, the problem occurs because for some reason, Tomcat can't find some JARs even though I have specified them in my build path. The resolution is to put the JARs in the actual lib directory of Tomcat instead of in some project-specific location. (See this same case with log4j.)
What happens is this missing JAR causes the servlet to produce an internal server error when called. Tomcat generates an error page---which is of type "text/html"---and sends it back to client. So, client reads "text/html" instead of the expected "text/xml".
For a test this SOAP tutorial produces the specified error due to jaxm-api.jar but can be fixed with the solution I described above. I have verified this with Tomcat 7.
How can I check the content type that the error is pointing at?
A bit difficult to answer without some code. But if you are using javax.xml.soap.SOAPPart, it has methods to check the headers of the SOAP transaction. Check the javadocs. Shame it does not override toString(). But personally, I did not arrive at this answer with Java debug methods but via looking at TCP dumps.

Apache CXF web services problems

I have a multi-module project using Maven. On one of the modules I have several web services developed using Apache CXF Framework 2.5.4. At the moment I have two "problems" or questions.
First of all, if I call to a method of one of the web services that should return a List, if the list is empty, it returns "null" instead of the empty list.
I was trying to find out what could be the problem, if it's a bug of the CXF version I'm using or if I should use some annotation to modify the definition of the method or the response, but I couldn't find anything. I've seen some people with the same problem, but no solution.
The other thing I wanted to ask is: I'm developing a web application using MVC pattern. I'm wondering which way I should call the web service from the Controller instead of using ClasspathXmlCpplicationContext and then context.getBean().
For example, the bean definition for one of the web services on the client side is:
<jaxws:client id="deviceWSClient"
serviceClass="..IDeviceWebService"
address="http://localhost:8080/../DeviceWS" />
I've already tried usin #Autowired or #WebServiceRef annotations. With these it works but not doing a HTTP request to the web service, I guess it gets the dependency from the local repository. I think what I need is the way of injecting this bean on the Controller.
To answer your questions
For your first question: If the list is empty it is correctly handled by CXF version 2.6.1 - the service returns a empty. Just to demonstrate I have a sample service where types are defined this way:
#XmlAccessorType(XmlAccessType.FIELD)
#XmlRootElement(name = "MemberSearchResponse", namespace="http://bk.org/memberservice/" )
public class MemberSearchResponse {
#XmlElementWrapper(name="memberDetails")
private List<MemberDetail> memberDetails;
If I return a empty memberDetails above, the xml that goes over the wire is this:
<ns2:searchMemberResponse xmlns:ns2="http://bk.org/memberservice/">
<ns2:MemberSearchResponse>
<memberDetails/>
</ns2:MemberSearchResponse>
</ns2:searchMemberResponse>
EDIT
It is correctly handled as part of a wrapper type like above, but DOES return null if instead of returning a wrapper type, the list is directly returned.
Consider a Webservice interface defined this way:
#WebMethod(operationName = "searchMember")
List<MemberDetail> searchMember(#WebParam(name = "MemberSearchRequest") MemberSearchRequest memberSearchRequest);
If the List returned is an Empty list, it gets serialized as null by CXF 2.6.1 also.
The workaround is to use a wrapper type
EDIT END
For your second question:
You are creating a client bean this way:
<jaxws:client id="deviceWSClient"
serviceClass="..IDeviceWebService"
address="http://localhost:8080/../DeviceWS" />
Once you have created a Spring bean this way, you can treat it just like a normal Spring bean and inject it the way you would do with any normal Spring bean, for eg, either inject it this way:
<bean id="consumerBean" class="...">
<property name="deviceWS" ref="deviceWSClient">
</bean>
or use #Autowired
#Autowired IDWebService deviceWSClient
Or user #Resource
#Resource IDWebService deviceWSClient
These are the usual ways of injecting in a bean.
I have a sample application at this github location that you can play with:
https://github.com/bijukunjummen/memberservice-codefirst.git
Just start up the server using mvn tomcat:run and run a test org.bk.memberservice.TestCxfIntegrationTest which will make a request to the CXF service.
#WebServiceRef probably works if you follow this link on Spring forum. There you use different way for jaxws configuration. See the last post on the list.
Another ways to define the client are discussed on this SO question. There is e.g a solution where you finally use #Autowired annotation after you have given some extra configuration. See the last answer on the question.
The another issue you mentioned was about this cxf List related issue where also a solution is told for a workaround to the problem. So it is a bug. Version 2.2.7 has it fixed, but again in version 2.2.9 problem is arisen again. Wierd that until your version 2.5.4 it is back on error state. You could try the work around still, if it fixes the issue for you.

RPC/Encoded Jboss problem

I'm running jboss-4.2.1.GA to generate WS requests.
I have created the WS client with the help of JWSDP-2.0/JAXRPC. I have deployed the client to Jboss and I am now trying to send requests.
When I try to initialise the client service: javax.xml.rpc.Service service = servicefactory.createService(new URL(wsdlURL), serviceQN), Jboss starts to complain.
The error that Jboss generates is:
ERROR [JBossXSErrorHandler]
JBossWS_targetnamespace1.com7796329154971783225.xsd[domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve.4.2]::Message=src-resolve.4.2:
Error resolving component
'tns2:SimpleSerialiser'. It was
detected that 'tns2:SimpleSerialiser'
is in namespace
'http://targetnamespace2.com', but
components from this namespace are not
referenceable from schema document
'file:/home/jbossPath/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
If this is the incorrect namespace,
perhaps the prefix of
'tns2:SimpleSerialiser' needs to be
changed. If this is the correct
namespace, then an appropriate
'import' tag should be added to
'file:/home/jbossPath/mobaq/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
Followed by a warning:
WARN [WSDL11Reader] Encoding style
'http://schemas.xmlsoap.org/soap/encoding/'
not supported for:
{urn:namespace}doTask
Finally, the following error is displayed:
ERROR [STDERR]
org.jboss.ws.WSException: Cannot
obtain java type mapping for:
{urn:namespace}ArrayOf_tns2_TagType
ERROR [STDERR] at
org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildInputParameter(JAXRPCMetaDataBuilder.java:266)
...
...
I know that a similar error has been posted in community.jboss.org in the past but for a different task. I am not sure if the patch provided will solve my issue and I don't know how to implement the patch provided.
In addition to this, I have found someone having similar issues: JAX-RPC in JBoss 4.2.3 but the suggested solution does not work for me.
I also know that JbossWS does not support RPC/Encoded but I use jboss for my solution.
Is there a way for me to get around this issue, can I not get Jboss to create the client service to send requests? I'm not sure requesting a RPC/Literal WSDL file is a possibility so that's why I am asking.
Any suggestions will be greatly appreciated.
http://schemas.xmlsoap.org/soap/encoding/ is a legacy style used by very old web service stacks (it's so bad, even Microsoft recommend against it). It was seriously flawed, and so was excluded from the WS-I interoperability spec, which most modern Java web service stacks implement.
The only java stack that I know of that handles these old encoding is Axis 1, which is itself seriously flawed, but may be your only option. You should be able to run Axis as a client from inside JBoss.
I finally solved the issue by implementing the solution suggested from JAX-RPC in JBoss 4.2.3 post:
To jump to the chase, I simply put the following JARs from Axis 1.4 in my EAR's lib directory:
axis.jar, axit-ant.jar, commons-discovery-0.2.jar, jaxrpc.jar, saaj.jar, wsdl4j-1.5.1.jar
What I was doing was putting the above jars with my own WS Client jar file and that's why it didn't work. The solution was there, in front of me in black and white and I didn't implement it properly. That's the problem when looking too closely to an issue for too long.
I am a numpty.

Categories