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.
Related
Scenario:
I'm supporting an Enterprise application that runs in Wildfly10. The application (.war) uses J2EE technologies (EJBs, JPA, JAX-RS) and SpringBoot features (like, SpringMVC, SpringRest, SpringData, SpringRestData) ... Both stacks co-exists "happily" because they don't interact between them; however, they do share common classes, like utility or Entity Classes (the stacks map to the same database model). Why the application uses those stacks is out the scope of the question.
Currently, I'm trying to improve the performance of a #RestController that pulls some data from the database using a JPA Spring Repository. I found that we're suffering the N + 1 queries problem when calling the #RestController. In past projects (where there were only J2EE technologies), I have used the #BatchSize hibernate annotation to mitigate this problem with total success.
But, in this project, Spring seems to be skipping such annotation. How do I know that? Because I turned on the hibernate SQL logging (hibernate.show_sql) and I can see the N + 1 queries is still happening ...
Key Points:
Here are some insights about the application that you must know before providing (or trying to guess) any answer:
The application has many sub-modules encapsulated as libraries inside WAR file (/WEB-INF/lib) ... Some of these libraries are the jars that encapsulate the entity classes; others are the jars that encapsulate the REST Services (that could be JAX-RS services or Spring Controllers).
The Spring configuration is done in the classes defined in the WAR artifact: in there, we have a class (that extends from SpringBootServletInitializer) annotated with #SpringBootApplication and another class (that extends from RepositoryRestConfigurerAdapter) annotated with #Configuration. Spring customization is done is such class.
The application works with multiple datasources, which are defined in the Wildly server. Spring DATA JPA must address any query pointing to the right datasource. To accomplish this requirement, the application (Spring) was configured like this:
#Bean(destroyMethod="")
#ConfigurationProperties(prefix="app.datasource")
public DataSource dataSource() {
// the following class extends from AbstractRoutingDataSource
// and resolve datasources using JNDI names (the wildfly mode!)
return new DataSourceRouter();
}
#Bean("entityManagerFactory")
public LocalContainerEntityManagerFactoryBean getEntityManagerFactoryBean() {
LocalContainerEntityManagerFactoryBean lemfb;
lemfb = new LocalContainerEntityManagerFactoryBean();
lemfb.setPersistenceUnitName("abcd-pu");
lemfb.setDataSource(dataSource());
return lemfb;
}
The last #Bean declaration favors the use of a persistence.xml file, which we do have in the route /WEB-INF/classes/META-INF/ (i.e. Spring does find this file!) ... In such file, we define our domain classes, so that Spring JPA can see such entities. Also, we can define special JPA properties like: hibernate.show_sql and hibernate.use_sql_comments without issues (this is how I detected the N + 1 queries problem in the first place) ...
What I have done so far?
I tried to add the #BatchSize annotation to the problematic collection. No luck!
I created a new JAX-RS Service whose purpose was to mimic the behavior of the #RestController. I confirmed that the #BatchSize annotation does work in the application's deployment, at least, in JAX-RS Services! (NOTE: the service uses it own persistence.xml) ...
Test details (Updated 2020/07/30): What I did here was to create a new JAX-RS Service and deployed it inside the WAR application, next to the #RestController that presents the problem (I mean, it is the same WAR and the same physical JVM). Both services pull from database the same entity (same class - same classloader), which has a lazy Collection annotated with #BatchSize! ... If I invoke both services, the JAX-RS honors the #BatchSize and pulls the collection using the expected strategy, the #RestController does not ... So, what it is happening here? The only thing different between the services is that each one has a different persistence.xml: the persistence.xml for the JAX-RS is picked by Wildfly directly, the other one is picked by Spring and delegated to Wildfly (I guess) ...
I tried to add the properties: hibernate.batch_fetch_style (=dynamic) and hibernate.default_batch_fetch_size (=10), to the persistence.xml read by Spring ... No luck. I debug the Spring startup process and I saw that such properties are passed to the Spring Engine, but Spring does not care about them. The weird thing here is that properties like: hibernate.show_sql, Spring does honor them ... For those who are asking: "What does these properties do?" Well, they are global equivalent to apply #BatchSize to any JPA lazy collection or proxy without declaring such annotation in any entity.
I setup a small SpringBoot Project using the same Spring version as enterprise application (which is 1.5.8.RELEASE, by the way) and both the annotation and properties approach worked as supposed to.
I've been stuck with this issue for two days, any help to fix this will be appreciated ... thanks!
There are 2-3 possible issues that I can think off.
For some reason, whatever you modify isnt picked up by wildfly - Wildfly classpath resolution is a separate Topic and some missing configuration can cause you a nightmare. This you can identify if you have access to debug the query, and in if you put a breakpoint in the constructor of your Entity class, you will get a chance to evaluate the entity configuration being used, somewhere in the execution conetxt.
BatchSize doesnt work on OneToOne, It only works on OneToMany relationships.
A typical way to define BatchSize is to do along with Lazy load as mentioned in the example here. If you are not using Lazy fetch, hibernate assumes that you are willing to make an eager load and makes another select query to fetch all the details.Please confirm you are using the same syntax as given in the example above.
New Addition:
Put Conditional Breakpoints in PropertyBinder#setLazy() function, and may be backtrace it and put relavent breakpoints in CollectionBinder and AnnotationBinder. then restart/redeploy the server and see what data you are getting for the relavent properties. That will give you fair idea where it is failing..
Why conditional breakpoint? Its because you will have thousands of properties and if you do not add condition to the breakpoint, you will take 1 hour to reach your actual breakpoint
What should be the condition - If its property binder, the condition shoud be like `this.name == . For other classes also you can use the same approach.
Sorry for too detailed description on conditional breakpoints, you might find it redundent.
Looks like the only way to debug your problem is to debug hibernate framework from server startup, then only we will be able to find out the rootcause
I'm working on a system's back end that uses Spring Boot, REST, HATEOAS, Hibernate and PostgreSQL. For validation, I started using classes that extend org.springframework.validation.Validator. It works well, but only for calls made by the front end. For calls made in the back end, such as by using EntityManager, they don't fire. I've managed to have another validator being called in this situation by using #Constraint for ElementType.TYPE, but it only gets called for create and save methods.
Is it possible to use this validator to validate on delete methods too? There's a project here that's a non operational subset of the project I'm working on, containing the validators I mentioned.
Thanks in advance.
P.S.: I'd rather avoid manually calling the validators whenever I call a repository method in the back end.
P.P.S.: This answer makes me believe it's possible, but I couldn't translate the XML configuration to JavaConfig.
I finally found the answer. In application.properties, add:
spring.jpa.properties.javax.persistence.validation.group.pre-remove=javax.validation.groups.Default
The linked question told me which property I needed, but I didn't know where to place it. I tried to use custom Java configuration and even persistence.xml configuration, but several other things failed.
Here, I learned that "[...] all properties in spring.jpa.properties.* are passed through as normal JPA properties (with the prefix stripped) when the local EntityManagerFactory is created." So I just added that prefix and it worked.
When I publish a web service created from a WSDL, the WSDL which is created after publishing is different than the original one. The difference is that WSDL/XSD created after publishing had additional element(ARG0) which wraps all root elements.
Because of the reason above, I could not share original WSDL/XSD to client developers since original WSDL and the one created after publishing is not same.
I am using Java as a programming language and JAX-WS.
using API javax.xml.ws.Endpoint to publish the web service without needing any Application server.
Endpoint.publish(url,webserviceinstance)
Thanks in advance.
Since the problem is unneccesary wrapping issue, I focused on wrapping annotations. Eventually I have found out that there is a related annotation for this issue. After adding following annotation statement at the beginning of Class ,problem has been solved.
#SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE)
public class WebServiceHandler implements WebService {
//....
}
From now on, I can make succesfull request created from original WSDL to deployed machine.
If you post the wsdl, a better assessment can be made. Given that you are seeing an unexpected wrapper, my guess is that jax-ws is interpreting your original wsdl differently than you intend. The page here (http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/) discusses different wsdl configurations. My suggestion is that you follow the instructions for using the document/literal/wrapped convention as it is more or less in the mainstream for soap-based services.
The resulting published wsdl will still likely be a little different in terms of service name, port name or namespace unless you use the #Webservice annotation attributes to force these to particular values, but they will be consistent such that you can provide the published wsdl to your clients and expect success.
The most common reason for this type of issue is that the class implementing the Web service doesn't have an #WebService annotation with the correct endpointInterface attribute. In fact, it is not sufficient to implement the endpoint interface generated from the WSDL.
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.
I have been trying to get Resteasy to work (and not it dose). However I now have another headache with accessing the EJB:s. I have tried injecting them, looking them up with jndi and most other solutions but none of them works.
I get massages like: java.lang.RuntimeException: Class is not a root resource.
Or: java.lang.IllegalArgumentException: Wrong target.
Or just: NullPointer
Using JBoss 5.1.0.GA and Resteasy 1.2.1.GA... Can't find any documentation on how this could be done. Do anybody know?
Have you seen this: EJB Integration?
Resteasy currently only has simple integration with EJBs. To make an EJB a JAX-RS resource, you must annotate an SLSB's #Remote or #Local interface with JAX-RS annotations:
Next, in RESTeasy's web.xml file you must manually register the EJB with RESTeasy using the resteasy.jndi.resources