I have been trying to set up Spring 3 annotation-based validation, guided by http://static.springsource.org/spring/docs/3.0.0.RC3/spring-framework-reference/html/ch05s07.html. I am using JBOSS 5.0.1 server; however, upon invoking the #Valid annotation from the Controller. I received errors and found out it will require javax.validation.*;
Upon adding the validation-api-1.0.0.GA.jar (for javax.validation.*), I received complaints about it requiring Hibernate Validator 4+, which in turn requires Hibernate 3.5+. Finally, I discovered that JBOSS 5 does not support Hibernate 3.5+ because it uses JPA-2 and JBOSS 5 is tightly coupled to JPA-1.
At this point, my brain hurts.
Does anyone have a successful example of using Spring 3 annotation-based validation under JBOSS 5?
I finally figured out the answer to this. I basically reverted to using Hibernate Validator 3.1 using this example:
http://wheelersoftware.com/articles/hibernate-validator-3.html
Hope this helps anybody else.
I just wanted to add one more thing. I managed to wire Hibernate Validator 4.01 to JBOSS 5.01. The steps were as follows:
Remove hibernate-validator.jar from the JBOSS common/lib directory
Insert the validation-api-1.0.0.GA.jar, hibernate-validator-4.1.0.Final.jar into your project's WEB-INF/lib directory.
Related
I've come to the conclusion that the Spring Web MVC is not compatible with Payara 5 and 6. I have an application that uses Glassfish 3, Spring Web MVC, and EclipseLink JPA. I intend to upgrade the code to Java 17 and Jakarta EE. In the sake of kindness, it hasn't gone well. In all my efforts, it's been Spring's Web MVC that is causing the problems. Spring charges for support and that's not a viable option for me. Before I scrap it's use, let's pick your brain.
If anyone has implemented Spring Web MVC successfully with Payara 5 and/or 6, please share how you made it work.
My first step was to try Payara 6 for Jakarta EE. After creating a VERY small Hello World web app, I included Spring Web MVC jar and did the minimum to activate it's Dispatcher Servlet. I was never able to overcome the error CDI is not available.
Secondly, I backed off to Payara 5. In that attempt, it tries to instantiate a JPA EAO Bean that the app will use in all it's controllers to access the app's DB. The error here appears to be when it attempts to use FasterXML to read the persistence.xml file. That part of the app works fine when I create the EAO object with JUnit.
Rather than providing all the gory details, reviewing the artifacts from a successfully implemented app with help me tremendously.
Thank you for your help!
So after weeks of beating my head against a wall trying all kinds of things to get it working, I wrote to one of the SpringFramework developers, Juergen Hoeller. Here's his response....
Sorry to hear that there is so much trouble on Payara still. We also
have corresponding reports on GitHub:
https://github.com/spring-projects/spring-framework/issues/29718
https://github.com/spring-projects/spring-framework/issues/29743
Unfortunately neither of the two is an actual problem to be solved on
Spring's own side, as far as I can see.
With the CDI issue, it's Payara's CDI implementation not being able to
parse Java 17's new record types. Also, I wonder why Payara needs to
parse every single deployed class file if you are not actually using
CDI. It might be possible to turn that off, but at the very least,
Payara should defensively handle "unknown" types.
With the Hibernate issue, it's a problem with Hibernate 6 initializing
its Jackson configuration on Payara. There does not seem to be a StAX
provider available, and Hibernate insists on one being present for
Jackson.
Overall, this needs to be taken to Payara and Hibernate, we are not
aware of anything Spring can do better. Feel free to add further
comments to the GitHub issues in case there is anything we can do from
our side! Even if our focus is on Tomcat/Jetty these days, we of
course want Spring 6 to work fine on Payara as well.
Thanks for your efforts to try to make this work,
Juergen
So now, how do we get the attention of Oracle's Glassfish developers and Payara's developers to get this resolved???? In the meantime, I think I'll have to install Tomcat or some other free webserver. Thanks, Oracle.
This was reported against Hibernate before, but Glassfish/Payara simply have a broken classpath config. Also see https://hibernate.atlassian.net/browse/HHH-15556
Maybe try using Wildfly, which is also free ;)
I'm working on application which uses Spring Core in version 4.3.14 and Spring Web in version 4.2.13. We don't use Spring MVC. Also, from Spring Web we use just very limited set of classes:
XmlWebApplicationContext (so classes from org.springframework.web.context)
RestTemplate (so classes from org.springframework.web.client, here i expect some problems)
some util classes which probably can be refactored to use something else
My question is:
We want to migrate to Spring 5.x. Is such a migration really possible? Or should i expect some severe problems with application startup (class incompatibilites etc). This source for example: https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x#whats-new-in-version-50 says that Servlet 3.1 is required
From the other side, here https://spring.io/blog/2015/06/10/feedback-welcome-spring-5-system-requirements JUERGEN HOELLER wrote that migration to Spring 5 will be a soft one. So i assume that if Application uses only features from JEE6 + Servlet 3.0, then it can be that it will also work on Spring 5.x with JEE6-compatible appserver
Does anyone have an experience in that?
As always, Spring Framework upgrades its baseline with new major versions. In this case, we're requiring JDK8+ and Java EE7+.
In practice, this means that the compiled code depends on those APIs and doesn't use reflection anymore to adapt to them. In your case, this is not only about Servlet, but also JPA, JMS, bean validation and other specs.
Your application might work fine with the arrangement you're mentioning, but the Spring team will not guarantee support for this setup.
According to you what are the risks of using Spring 4 with the jersey-spring3 integration module?
I have tried to use Spring 4.0 with the jersey spring example and the example still works but i'm unable to identify risks linked to this usage.
I have started using Jersey 2.7 and Spring 4.0.x recently in a project. I have setup a context hierarchy to inject beans, so far, I have discovered only one limitiation but that does not seem relate to Spring 4 but rather to the module itself or the HK2 Spring Bridge.
To give more insight about my use. I have a XJC/JAXB-backed which is consumed by a common service, repository and exposed through JAX-WS, and now hopefully through JAX-RS.
The multi-context stuff works now with #Autowiredwith 2.8-SNAPSHOT. I have applied my changes and the 2.8-SNAPSHOT to 2.7. Here is the diff.
Edit (Michael-O; 2014-10-17): Here is a modified Spring module based off 2.11 with multi-context support.
Not an answer to original question, just related information
This may be a little premature, but the new Major 3.0 version of Jersey will be using Spring 4, in the new jersey-spring4 module. The new Major version will be built with Java 8. Though a new Major version will be released, the 2.x line will still be actively developed to keep support for Java 7
I'll update this post once 3.0 has been release.
For anyone interested, you can see this mailing list to see what the Jersey team has to say about the new 3.x line.
Not sure if you came across any issues but I currently face one. It is described in other thread.
Simply, using jersey-spring3 2.12 and spring 4.1.0.RELEASE in one maven project leads to following class incompatibility:
2014-09-14 01:15:44.175:WARN:oejuc.AbstractLifeCycle:main: FAILED org.eclipse.jetty.server.handler.HandlerCollection#696
db620[org.eclipse.jetty.server.handler.ContextHandlerCollection#27abb6ca[o.e.j.m.p.JettyWebAppContext#737d100a{/,file:/C
:/Users/Josef/Workspace/TransitCenter/src/main/webapp/,STARTING}{file:/C:/Users/Josef/Workspace/TransitCenter/src/main/w
ebapp/}], org.eclipse.jetty.server.handler.DefaultHandler#6968c1d6, org.eclipse.jetty.server.handler.RequestLogHandler#7
d986d83]: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependenc
yComparator()Ljava/util/Comparator;
java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparato
r()Ljava/util/Comparator;
at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationCon
figUtils.java:136)
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.
I am working on an application using Spring 3 and Hibernate 3.5 with Java 1.6.
So far I've been using JBoss 4.2.1 and everything was fine.
Now while migrating to JBoss 5.1, I encountered lot of issues. One of them is that JBoss is ignoring the Spring #Resource annotation. I get the following exception:
java.lang.RuntimeException: mapped-name is required for serviceManager of deployment pol-1.0.war
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlResourceEnvRefs(WebResourceHandler.java:287)
at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(WebResourceHandler.java:325)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:550)
at org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:158)
It expects mapped-name for each #Resource like some ejb.
I've seen similar questions but they are without any answer e.g.:
#Resource annotation not working properly with JBoss5.0.1
Please advise.
Adi
Actually your problem is that JBoss doesn't ignore #Resource annotations - it tries to handle them according to EJB rules instead of leaving them to Spring.
Perhaps this feature can be disabled somewhere in JBoss configuration, but the simpliest solution would be to replace #Resource with #Autowired or #Inject.
Sounds like java annotations need namespace support.
Then it would be #Spring:Resource or #EJB:Resource.
Oracle, are you listening?
Short of namespace for Annotations, you could possibly try changing the order of the libraries in your classpath so java would see the Spring annotations first (or last), whichever ends up providing the desired outcome.