spring-struts JAR is using struts version 1.x which is deprecated. Isn't this posing a security risk.
Related
I am currently using Struts 2.0 version in my project. Now I want to move the Struts 2.5 version for the same. Can I directly move from 2.0 to 2.5?
If yes what things we need to change?
If no how can we achieve it? want detailed steps.
I'm planning to convert a web app from using JSF managed bean to using CDI managed beans. I know I'll need to do below:
Add a empty beans.xml file in WEB-INF.
Replace all JSF #ManagedBean to CDI #Named annotations.
Replace all JSF scope annotations with CDI or OmniFaces scope annotations.
Replace all JSF #ManagedProperty with CDI #Inject annotations.
Is that all that needs to be done? Are there any gotchas that I need to be aware of?
Basically, that's indeed all you need to do provided that you're on a Java EE server already. When on Tomcat, you'd need to manually install CDI first. Instructions for both Weld and OpenWebBeans are detailed in the blog How to install CDI in Tomcat?
The below gotchas need to be taken care of:
While OmniFaces 2.x "officially" requires JSF 2.2, OmniFaces 2.0/2.1 is technically backwards compatible with JSF 2.1 and should in TomEE's case work on TomEE 1.x with JSF 2.1 as well, but OmniFaces 2.2 has a hard JSF 2.2 dependency (due to the new <o:viewAction> tag) and won't deploy on TomEE 1.x without upgrading its MyFaces JSF implementation to a 2.2 compatible version, or itself being upgraded to TomEE 7.x. See also OmniFaces Compatibility Matrix.
When you deploy an EAR with multiple WARs with each its own OmniFaces library, then generally all CDI functionality will work in only one WAR as the CDI context of a WAR-provided library is incorrectly interpreted as EAR-wide. This is an oversight in CDI spec and yet to be fixed in a future CDI version. See also OmniFaces Known Issues (CDI).
When you want to use OmniFaces-provided CDI injection support in #FacesConverter or #FacesValidator, and you're going to create/use a CDI 1.1 compatible beans.xml (and thus not a CDI 1.0 compatible one or an empty one), then you need to make sure that you have explicitly set bean-discovery-mode="all" in beans.xml. See also #FacesConverter showcase.
When replacing #ManagedBean(eager=true), be aware that standard CDI has no direct equivalent for this. You would use #Observes for this. OmniFaces offers #Eager annotation for the purpose. See also How to configure a start up managed bean?
When replacing #ManagedProperty in JSF 2.0/2.1/2.2, be aware that you can't inject #{param.xxx}, #{cookie.xxx} and #{initParam.xxx} directly via #Inject alone, while that was just possible via #ManagedProperty. OmniFaces offers respectively #Param, #Cookie and #ContextParam for the purpose. Only in JSF 2.3 there's a new #javax.faces.annotation.ManagedProperty annotation which can be used exactly the same way as original #javax.faces.bean.ManagedProperty which got deprecated since JSF 2.3.
Is Spring Security compatible with Java 8 (Oracle)?
I presume that v4 is, since it requires Spring v4 which does support jdk8. However I couldn't find any explicit information on this.
I did check the Spring Security Bug Tracker and found one minor open issue with OpenJdk8 - however it was written before Spring Security v4 was released.
I couldn't find anything on Spring Security v3.x with jdk8. Does anyone know if that works/is supported?
There is a section in the Spring Security Reference that states:
Spring Security 2.0.x requires a minimum JDK version of 1.4 [...]
Spring Security 3.0 and 3.1 require at least JDK 1.5 [...]
However, as noted in the question, this is not very explicit! Despite being a reference for Spring Security 4.2.0, the section quoted above has no details at all about Spring Security 4. I suspect that portion of the documentation is simply out of date.
A different portion of the documentation has this information (emphasis added):
There are a number of ways in which Spring Security can resolve the method arguments. [...] By default, the following options are tried for a method as a whole.
[...]
If JDK 8 was used to compile the source with the -parameters argument and Spring 4+ is being used, then the standard JDK reflection API is used to discover the parameter names. This works on both classes and interfaces.
Though not explicit, it seems illogical to document how Spring Security handles code compiled using JDK 8 if it does not work using JDK 8.
Spring Framework 4.1.6 is also the first release to be formally compatible with the recently released JDK 8 update 40
it's from Spring blog
this should be helpful:
spring-core 3.2.9 + java 8
Spring 3.2.x will only support Java 8 runtimes compiled against Java 7
I have a JSF 2.0 application. Can we use acegi-jsf of version 1.1.3. Can we use this tag library for JSF 2.0.
Acegi does not exist anymore. It was taken over by Spring in April 2008 and continued under the brand "Spring Security". That Acegi tag library is likely JSP targeted and not Facelets targeted. JSF 2.0 was namely introduced in December 2009, which is a long time after the Acegi takeover by Spring.
You should be looking for Spring Security JSF 2.0 tag library instead. However, a "JSF 2.0 tag library" can better be rephrased to "Facelets tag library" in order to end up with a more correct term and thus get better Google hits. You ultimately want to use this on Facelets (XHTML) files, right?
I don't do Spring, but Googling on "Spring Security Facelets tag library" yields among others this link which describes how to manually declare Facelets tag libraries and EL functions. There does thus not seem to be a full integration (i.e. just dropping JAR in webapp without the need to manually create .taglib.xml files), they seem to be working on that for future releases.
I have an application, full application that made on JSF 1.2. Now we are adding module in it. Can i replace JSF 1.2 with JSF 2.0 ? Means only new module use JSF 2.0 and the remaining application become unaffected by the change? Means is JSF 2.0 is fully compatible with JSF 1.2. Like i open the project in netbeans and add JSF 2.0 jar in the project and remove the JSF 1.2 jar? Can i do that ? or i should have use JSF 1.2 for new module because application is made on JSF 1.2 ?
Thanks
There's a pretty good thread for that where they explain basic settings to more advanced settings to migrate from JSF 1.2 to JSF 2.0