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.
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 have just started learning spring boot . In its official page I found out this term and I did not understand that what actually it meant in Spring boot context.
Spring Boot just decides on a set of default configured beans which you can override if you want.
For example if you include the spring boot starter pom for jpa, you'll get autoconfigured for you an in memory database, a hibernate entity manager, and a simple datasource. This is an example of an opinionated (Spring's opinion that it's a good starting point) default configuration that you can override.
See https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-replacing-auto-configuration
Spring Boot, is Spring on steroids if you will. It's a great way to get started very quickly with almost the entire Spring stack. I'll try to summarize as what "Opinionated Defaults Configuration" would mean in practice from a programmer's perspective below:
Helps you to setup a fully working application(web app or otherwise) very quickly by providing you intelligent default configurations that you are most likely to be satisfied to start with.
It does so by something called "AutoConfiguration", where capabilities from the Spring ecosystem of products are "auto-magically" enabled in your application by adding certain dependencies to your classpath; adding such dependencies via maven or gradle is super easy.
Most auto-configuration respects your own configuration, and backs off silently if you have provided your own configuration via your own beans.
You would benefit most if you take the java config approach of configuring your Spring application.
Super silky integration of new capabilities in your application by developing your own auto-configuration components (via annotations!).
Tons of auto-configaration components available ranging from Databases(h2, derby etc.), servlet containers(tomact, jetty etc.) to email and websockets are available. It is easy to develop your own. The important thing is that others can use those technology enablements in their own components. Please feel free to contribute.
Helps write very clean code with all the heavy lifting taken care of you, so that you can focus more on your business logic.
Hope you have fun with Spring Boot; its absolutely among the very best of frameworks to have hit the market in the last decade or so.
It follows opinionated default configuration so it reduces the developer efforts. Spring boot always uses sensible opinions, mostly based on the class path contents. So it overrides the default configuration.
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
Ive been working now with the Spring Framework 3.0.5 and Spring Security 3.0.5 for several time. I know that Spring Framework uses DI and AOP. I also know that Spring Security uses DI, for example when writing custom handlers or filters. Im not sure whether Spring Security also uses AOP - so my first question is: does it?
Well, Id also like to know how Spring Security can be used for non-spring-based applications. Its written in their documentation that this is possible. Well, I wonder how - it seems like it uses DI, so how should it work in a simple java web application? I guess at least a web container which supports dependency injection is needed, correct? (Which one could that be?)
Thank you for answering :-)
[EDIT]
documentation says:
"documentation says: "Spring Security provides comprehensive security services for J2EE-based enterprise software applications. There is a particular emphasis on supporting projects built using The Spring Framework, which is the leading J2EE solution for enterprise software development. If you're not using Spring for developing enterprise applications, we warmly encourage you to take a closer look at it. Some familiarity with Spring - and in particular dependency injection principles - will help you get up to speed with Spring Security more easily.""
j2ee-based enterprise software applications......... emphasis on supporting projects using spring framework...... well this means it should be possible to work with it without Spring Framework itself!
?
AND:
Even though we use Spring to configure Spring Seurity, your application doesn't have to be Spring-based. Many people use Spring Security with web frameworks such as Struts, for example.
This is from the spring security homepage. well....
Does it use AOP ?
Yes spring-security uses AOP for its method security (you'd have to search the page to find it).
Can you use spring-security without spring ?
Generally no.
As you need to define spring beans for several spring-security elements.
But! You can use Acegi security without spring as far as I know. Which should give you close to the same functionality.
Can you secure a non-J2EE application
Definitely.
Anything that can run in a servlet container can be secured with spring-security. You just need Spring's IoC/DI.
This answer can help you on the minimal spring-security dependencies.
EJB 3.0 comes with the concept of Interceptors, but then again they are applicable to EJBs only. My project requires developing Interceptors for POJO classes. One option for this is to use Spring AOP. I want to know if it's worth the overhead of including the libraries such as commons-logging, spring-aop, cglib that are required for Spring AOP.
Spring is much more than Spring AOP, and you can not use Spring AOP without Spring, and I am talking not only to the Spring libs, but to the Spring programming model too!
So if you think Spring is useful for your application (believe me, it is very useful to many application), then you can use it. - But it is a complete programming model, like EJB, not only a lib or a simple framework.
But I think every modern not trivial application should have a ICO container, so Spring is one of the choices you have.
Sure, it's worth, but be aware it won't be enough if you need to have interceptors for you POJOs : You will also need a "spring agent" to be passed as an argument to your jvm ("Load-Time Weaving"), or you won't be able to intercept your pojos methods, or you will have to use "Compile-Time Weaving".
In short : POJOs have to be created via Spring for them to be "interceptable".
CTW (or LTW) makes compilation (or startup) quite slower.