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.
Related
Still getting in my raw project (established only for #Pattern exercises in #Entity without any Spring framework and servlets):
Exception in thread "main" javax.validation.NoProviderFoundException: Unable to create a Configuration, because no Bean Validation provider could be found ...
I've decided to try it with Jakarta libraries and found in hibernate operate manual point 1.1.3. "Running with a security manager" such an additional, suggested configuration lines to put in the java policy file
vide: https://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-getting-started-security-manager
but before I will begin configuration tests with my $JAVA_HOME/lib/security/default.policy file I would like to gather information: how to refer to libraries that I would like to authorize in this file for the appropriate accesses?
Should I give this direct path to the jar files or point only to the fully-qualified class name? and what is the correct syntax in default.policy?
I don't know what you think you are doing, but the error clearly says that there is no bean validation implementation available on the class-/module-path. The reason why it can't find the provider depends on your project. Maybe you didn't specify it as dependency? Anyway, if you need further help, you will have to post more information about your project and runtime setup.
I work on a web application that calls multiple web service clients from within its code.
Each web service has some common namespaces, however I am currently mapping these namespaces to different packages when I generate each client
e.g.
Web Service 1's namespace1 -> com.company.webservice.client1.service
Web Service 2's namespace1 -> com.company.webservice.client2.service
Where namespace1 refers to the same namespace URL.
Using Wsdl2Java's namespace2package option:
// Web Service Client 1's namespace parameter
--namespace2package http://www.multispeak.org/Version_3.0=com.company.webservice.client1.service
// Web Service Client 2's namespace parameter
--namespace2package http://www.multispeak.org/Version_3.0=com.company.webservice.client2.service
I can generate web service client code for these services without issue and I can call each client fine on their own, so long as only one of the generated client jars is on the classpath for the given web service call. However, if I place both web service client jars on the classpath, only one of the web service clients will work (the one where its respective client jar is first on the class path).
The other web service client fails when trying to call it, with the following exception:
java.lang.ClassCastException: com.company.webservice.client1.service.impl.GetAllMetersResponseDocumentImpl cannot be cast to com.company.webservice.client2.service.GetAllMetersResponseDocument
I've obfuscated some of the actual values above.
So, the issue seems to be regarding how Axis2/XMLBeans looks up the appropriate class to match the given XML to parse from.
I can change the namespace mappings so that they match each other and it works fine after that. However, the downside to that is that I have multiple web service client jars containing the same generated code in the same package structure, whereby these classes will only be instantiated from the models from the first client jar it finds on the classpath.
Is there a way of doing this so that I can keep the different namespaces for each web service client jar?
Or am I simply going to be forced to have each namespace mapped to the same package for every client that uses that namespace?
Hopefully the issue makes sense, but if I need to provide anything else that would assist, please let me know and I will expand this question with further details, but hopefully someone with knowledge of Axis2/XMLBeans/web service client generation using Wsdl2Java should be able to answer this without much further info.
UPDATE 1:
I finally gave in and just made all of the namespace mappings point to the same package rather than bespoke per web service client and took the hit of having multiple copies of the same class in various JARs on the classpath. Not as elegant as I would have liked, but at least it works.
If anyone can come up with a better solution that allows me to use bespoke copies in each client instead, please do let me know.
UPDATE 2:
This approach equally does not work as the two web services, despite using the same namespace, produce different versions of the namespace's models which now causes compile time errors dependent on classpath order. So... Back to square one...
I have the feeling you have two versions of the GetAllMetersResponseDocument in each jar. What is happening is that it is loading the interface from the opposite jar file which ends up in Class cast exception. I may be wrong.
This is the reason why it works when you have one of the jars loaded.
There is also this option where you can have Classloader isolation, resulting in two different classloaders for the two jars you can again end up with two objects of the same type that can not be casted to each other.
UDATE
I actualy just checked if axis2 has classloader isolation defined by default and it does. https://axis.apache.org/axis2/java/core/faq.html read Class Loading
Issues
I believe also reading service and module isolation from this article will help you.
https://www.developer.com/open/article.php/10930_3589126_2/Avoiding-Mistakes-Made-Using-Axis2.htm
I'm trying to create a portlet with liferay 6.2 and using spring. If I create a bean without using constructor-arg or factory-method then everything works fine. But if I use either of these then I get exceptions when the portlet is deployed.
an example:
the exception I'm getting is:
01:28:21,884 ERROR [ContextLoader:323] Context initialization failed
java.lang.IncompatibleClassChangeError: class org.springframework.core.LocalVariableTableParameterNameDiscoverer$ParameterNameDiscoveringVisitor has interface org.springframework.asm.ClassVisitor as super class
I realize that this can be caused by having 2 versions of ams, but im using the spring jars that come with liferay.
You give an option yourself - duplicate classes. But without knowing how you build and what you're doing, there's hardly anything to do apart from asking you to make extra extra extra sure that you don't have duplicate resources on the classpath:
Check your deployed web application (once it's deployed to your application server) and its WEB-INF/lib folder for such duplicates. They might come in only during the buildprocess, e.g. they might not be in your IDE's workspace. Or Liferay might inject them (due to declared dependencies) during deployment.
You'll have to figure out how (and in which phase) those resources get there, then eliminate that option (e.g. through proper maven scope, e.g. "provided")
I am having some classpath issue. I have a Web Application which is a web service. It uses JaxB and CXF. The web service has a dependecy of another JAR which is a Web Service Client. Now both the client and the service codes are generated by using wsdl2java plugin. The problem looks like this:
Parent WebService WAR
--PackageA
--ClassB
Dependency Jar
--PackageA
--ClassB
So both of them have the same package and the same class name and since these are generated by the plugin, it makes difficult to refactor one of the package so that they would not be identical.
The WebService calls the client and in client code initializes the parent classB from web service instead of the classB from web service client Jar. The only problem in this ClassB is that they have one method which takes differnet parameter, in one class B it takes, Date whereas in another classB it takes XmlGregorianCalendar. So while calling the client i am getting nosuchmethodexception.
Here is what i tried so far without luck:
1: In the Client jar i tried giving the full package and class name to initialize the ClassB
2: In the Client jar i tried wiring the classes using Spring bean and surprisingly it is still wiring the class from the webService instead of the client
3: In the web service ClassB, i tried adding the same method that takes the right parameter. This works partially but result in another exception which is not good.
Looking forward for your help. Thanks!
Solved the issue by passing extra args to wsdl2java plugin while generating classes from the wsdl as per user2880879 suggestion like this:
<extraarg>-p</extraarg>
<extraarg>http://www.example.com=mypackagename</extraarg>
I believe you are creating webservice using top down approach, means write java class first using jaxws annotations and then create wsdl using cxf maven plugin or ant, and use this wsdl to create client ?
If you are following this approach then you can provide binding file when you generate web service client code. click here to know what is binding file and how to write.
In this binding file you can specify package name you want to change for client code.
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.