I've been developing Spring 3 + JSF 2.0 applications for some time. They run on simple Tomcat or Jetty container. Looking ad CDI I envy a conversation scope.
Are you aware of simple conversation scope implementation for Spring? I don't want to use full-blown SpringMVC + WebFlow + SpringFaces stack. I just need a web filter that enables conversation scope and lets me inject conversation object and start or stop it. Like in CDI.
Not exactly on your question, but since you're asking for a solution in order to avoid using Spring Webflow, Spring Faces, etc ... it looks like you're using Spring just for DI (i mean you're not so dependent on the Spring ecosystem). Well, maybe in this case it would worth the effort to think about migrating to a Java EE 6 stack. I don't think the migration would be that difficult, since you're using not that much from Spring, and in case you have beans in spring you still need, you could write some CDI producers for them. You can google for some migration paths from Spring to Java EE 6.
And if you're afraid of the "heavy Java EE containers", well jboss 7.1, Glassfish 3.1.2 and TomEE all start on my notebook in under 2 seconds, and I bet your tomcat + spring container don't start much faster.
Just my opinion.
you should give a look to Apache TomEE + CODI project (subject of Apache MyFaces) and/or Apache Deltaspike (not sure the doc is up to date because it is pretty young)
TomEE gives you the strength of CDI and CODI adds a small integration layer between cdi and jsf to make it very powerful (it will be integrated in deltaspike but that's still a bit in progress)
MyFaces Orchestra (also works with Mojarra) is currently the best conversation scope implementation for JSF 2.0 on top of Spring.
Use the JSF #ViewScoped annotation on your managed bean that gives you the same conversation-like semantics as the CDI conversation scope. One difference between CDI's conversation scope and JSF's view scope is that CDI gives you explicit and straightforward control over the conversation while the JSF viewscope is pretty much canned for use. But with JSF's ViewScope, you know exactly where the boundaries of a conversation are: A conversation starts when you load a page backed with a #ViewScoped bean and ends when the page is closed. This is convenient for many use cases
Cagatay of primefaces also has this hack to simulate the CDI scope in Spring.
This tutorial by Max Katz from the the Richfaces team also gives a good intro the JSF ViewScope
Related
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.
I would implement a Spring aspect in a j2ee application, can someone post some tutorials?
I've just used Spring in web application but I've not idea how to invoke a cross cutting concern in CDI container.
Thanks in advance
Is there a special need for combining Spring and CDI? If not, I'd suggest to stick to standard Java EE as long as you can solve your problem with it and only if not, look for external components (and even then, you should first check the "sort-of-standard" CDI extensionf from the Apache Deltaspike project.
Cross-cutting concerns can be solved via pure CDI - check our for example the Java EE 7 tutorial about the topic.
Small note: Don't use J2EE anymore if not maintaining an ancient application.
I would like to migrate an application from Spring 3 to Weld. In order not to rewrite the whole bean configuration at once, it would be cool if I could inject part of the application that is still written in Spring in the new CDI part.
Is that possible?
This should be possible. CDI has an extension system where you can hook into the injection mechanism. From there you can manually bootstrap your Spring beans and then return those.
I wouldn't be surprised if there's already an extension for this, so before looking into writing one yourself check if there's not one already.
There have been a few attempts at making CDI and Spring work together. Take a look at CDI Advocate for one.
It comes down to how much of your app is spring. If you're running something like Spring MVC, it'll be very difficult since it manages essentially your whole app.
This text is from the book called Core Java Server Faces:
It is a historical accident that there are two separate mechanisms,
CDI beans and JSF managed beans, for beans that can be used in JSF
pages. We suggest that you use CDI beans unless your application must
work on a plain servlet runner such as Tomcat. The source code for the
book comes in two versions, one with CDI beans (for Java EE 6
application servers) and one with JSF managed beans (for servlet
runners without CDI support).
My question is:
If I use the Spring Framework, and a Tomcat Server, will I need to use one of the beans mentioned above, or does Spring Framework come with its own bean implementations?
As far as I know, Spring Framework supports Dependency Injection. Does it support it if I run the application on Tomcat? Does it mean that I will be using neither the CDI beans nor the JSF Managed means mentioned in this book?
Thank you.
talking about container is more correct than bean implementation. Yes Spring comes with its own container. In fact you can see spring frameworks as a kind of alternative to the full Java EE stack.
Using Spring DI and CDI together has about no interest but you still can use JSF with spring on tomcat although if i would advise you to switch to a Java EE 6 web profile server instead of spring in this case.
Spring comes with is own view framework implementation named spring mvc.
All of this can run perfectly on any servlet container (jetty tomcat etc...) on condition that you provide associated dependencies ofc.
I understand that Spring has really nice features, such as dependency injection. I am new to Spring. I have understood that I can use Spring alongside with struts and other frameworks too, in order to use its capabilities.
In my project I am going to use Seam 2.0, I am using JNDI to lookup for the EJBs. I am wondering if I can integrate Spring with Seam and use its ApplicationContext in order to get beans from that directly and not use JNDI lookup anymore?
There is a whole chapter in the Seam reference dedicated to this:
27. Spring Framework integration