I'm trying to setup a project using Jetty 8 as the server (jetty-maven-plugin:8.1.11.v20130520), Weld for CDI (weld-servlet:2.0.1.Final), Hibernate for JPA (hibernate-entitymanager:4.2.2.Final, hibernate-jpa-2.0-api:1.0.1.Final) and Jersey for JAX-RS.
It seems that injections isn't working at all.
I tested whether the EntityManager is being injected, and the value was null.
The log doesn't show any errors or warnings while executing the server.
Am I missing something ?
If needed, I will post the log file to gist.
Here is the gist of all relevant files: https://gist.github.com/StalkingKillah/e986474b6885d83c7f8d
This is how I got it working for Jetty 9, and it should be basically the same for Jetty 8.
http://www.eclipse.org/jetty/documentation/current/framework-weld.html
It is easier to have the weld jar outside of the webapp as then you don't have to mess with tweaking the classes exposed to the webapp classloader like you are here (with the -org.eclipse.jetty bit for the ServletContext). I suspect there are more classes that would have to be added to that in order to make it work. You should get a note in the logging that says it is all enabled and active though.
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 ;)
Pardon if this feels a bit of "necroposting". I looked and found only one similar question with no answers here (Spring-Boot Embedded Wars).
I have a service packaged into a spring boot (1.0) container. This service uses activiti (www.activiti.org) to manage some buisiness processes. I am trying to deploy inside the same spring boot container, the war for activiti-explorer. This war has its own web.inf, spring config, et cetera, so it may conflict with the existing spring config, but nonetheless, I'd like to try to deploy that war as it is.
I haven't found any way to do that, and suspect that spring boot doesn't support the deployment of pre-package wars into the embedded container, isn't it?
Just as a warning, I think I can't put the extracted war into the spring-boot jar as I feel it needs a fully functional web container. If spring-boot doesn't offer this functionality, no big deal, we're going to deploy that war on its own tomcat, but it would be handy if it could be.
Thanks
Update
Just to clear better, I have an already running Spring Application standalone server, with its own embedded Tomcat.
Inside the embedded Tomcat I plugged some #Controllers I developed.
Then I was also able to map a third-party servlet using a ServletRegistrationBean (mapped to /servlet-path).
Now I'd like to do something similar with another war that contains a full fledged web application (it's a vaadin/spring 3.2 application with its own libraries, jsps, static resources ...) and would like to map it to (say) /war-path.
I would like to drop the war in a well known location and deploy it into tomcar with a (say) WarRegistrationBean that would let Tomcat handle all the classloading hurdles (as I mentioned, the war is using spring 3.2 while I'm using 4.0 with spring boot, ...).
I suspect that this last feature is not supported by spring-boot or - possibly - even out of scope for the project itself.
You can manually enhance a war archive by adding the stuff that the boot plugin does (classes from the loader and some META-INF information). Easiest would be to simply enhance an "empty" war, and then merge it with the target one (by exploding them both and re-jarring). The only thing you'd need to add might be a main class.
It's still a gap in the Boot tooling. If you think it needs filling please raise an issue and/or send some code.
For some reason Intellij 13.1.3 doesn't detect the spring boot beans. Spring boot version is 1.1.1-Release. When i try to inject ObjectMapper in some component i get an error in the IDE "No bean of type ObjectMapper defined", however the application compiles and runs just fine and the ObjectMapper beans is visible in the /beans json.
I have added my application-context and my Application.java files to a spring facet and the IDE recognizes all my other beans that I manually defined, it just ignores the ones that come with Spring boot #EnableAutoConfiguration. Any idea how to solve that since its kinda tedious not to have the correct linking in the IDE and get errors all over the place. I would assume thats a common issue?
Thanks!
As an update for this answer: IntelliJ now supports Spring Boot. Must be at least R14. R15 is including some more integration.
Spring Boot is not supported yet, please watch http://youtrack.jetbrains.com/issue/IDEA-119230
I'm trying to get Tomcat 7 (comes with OpenEJB) to work with Jersey 1.9. I had my Jersey RestFUL service working with Tomcat 6. But as soon as I deployed the war file to Tomcat 7(OpenEJB) I get the following error.
I created a new dynamic web project in Eclipse and added the following jars to WEB-INF/lib folder without adding any extra code but I still got the same error. It seems like Tomcat 7's OpenEJB is not liking Jersey jars.
asm-3.1.jar
jersey-core-1.9-ea04.jar
jersey-server-1.9-ea04.jar
Caused by: org.apache.openejb.OpenEJBException: Unable to instantiate Application class: com.sun.jersey.api.core.ResourceConfig: null at
org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1685)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1482)
at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:293)
at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:263)
at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:693)
at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:588)
... 23 more
Caused by: java.lang.InstantiationException
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1682)
Check out Apache TomEE Plus it is Tomcat with JAX-RS already integrated. You can skip the part where you hunt down libraries and try to get them integrated and move on to the writing code part.
Here's a video on how to set it up in Eclipse using the Tomcat web adpater and a simple Dynamic Web Project.
On the note of using EJBs as RESTful services, there are plenty of people that do that especially when JPA is involved. Aside from getting transactions for free, you also don't need a JAX-RS Application subclass or to map any REST servlets. A small perk, but nice.
As well you can expose the same class as a #Remote object and invoke it over RMI, as an JAX-WS #WebService and invoke it over HTTP/SOAP, or just annotate it #LocalBean and you can use the same object internally without the HTTP overhead. Nice to have the flexibility.
This stack trace makes me wonder if ResourceConfig has a no-argument default constructor. You'd see this if the OpenEJB deployment expects on and doesn't find it.
Since REST is an HTTP API for web services, why would you be using it with OpenEJB? I would guess that the two would be mutually exclusive. I'd write services using session EJBs or REST services, but not both.
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.