Liferay Portal 6.2 CE struts.jar (version1) to struts2.*.jar (upgrade issue) - liferay-6

I am trying to upgrade Liferay Portal 6.2 ce struts 1 to struts2.*.jar, please advise on how this can be done as it is not direct replace of struts.jar with struts latest version, thanks.

It is not as simple as just swapping jars.
Struts 1 to Struts 2 represents a fundamental change of the library.
You can pursue changing your own code to use Struts 2 instead of Struts 1, but if you're asking how to change Liferay's use of Struts 1 to use Struts 2 instead, that is a much harder task as it would require making fundamental changes to the Liferay core.
If your concern is simply removing Struts 1 because of published vulnerabilities, they are false positives with respect to Liferay. Liferay uses Struts 1 internally for request dispatching, but it does not expose or use Struts 1 components (such as Struts 1 forms) which have demonstrated vulnerabilities. So while Liferay uses Struts 1, it does not suffer from the vulnerabilities that Struts 1 has.

Related

Is it possible to have Web & JPA & EJB in 1 project in Eclipse?

I just finished a tutorial which was done in NetBeans. The tutorial created only 1 project which was a Web Application Project under Java Web category. The tutorial has 1 entity using JPA annotations, 1 Stateless Session EJB using JPA annotations, 1 Servlet calling the EJB, and 1 JSP calling the Servlet. So basically this 1 project has all 3 items: Web & JPA & EJB.
How can I have such a project in Eclipse?
When I work on Eclipse I get confused about how many projects I would need for a web application which uses JPA and EJB.
Should I create 3 projects 1 each for Web & JPA & EJB? OR
Should I create 2 projects 1 each for Web & EJB and include JPA in both?
Just create the "Dynamic Web Project" right away with a minimum version of 3.0.
Since Java EE 6 ("Web Profile") you indeed don't necessarily need to create a separate project for EJBs. You can then use a subset of the EJB API in the WAR, also known as "EJB Lite". You can then easily create a single no-interface EJB class with just a state annotation (Stateless, #Stateful or #Singleton) and you're already there.
You don't need the EJB facet for a "Dynamic Web Project". EJB Lite is basically already covered by the "Dynamic Web Project". There's not much IDE magic (wizards, code generators, etc) needed for EJBs anyway. You only need to make sure that the version is set to a minimum of 3.0 (from Servlet 3.0; part of Java EE 6), and that you set the target runtime to a real Java EE application server (even if it's only "Web Profile"), such as WildFly, TomEE, GlassFish, Liberty, etc and thus not a barebones servlet container like Tomcat or Jetty. This way the EJB annotations will be readily available in the project.
You don't even necessarily need to enable the JPA facet. You'll only miss the JPA-related wizards and code-generators under the project options. But you can just write all JPA-related code all by yourself and still get it to deploy. After all, an IDE is just like notepad, but then with millions of features trying to make you more comfortable while writing code. The project facets basically enable/disable the available project options/wizards/code-generators.

Can not find the tag library descriptor for "http://richfaces.ajax4jsf.org/rich"

I've been trying migrating my project from JSF 1.0 and RichFaces 3.1.4 to JSF 2.2 and RichFaces 4.5.2.
I want to keep the pages JSP formatted (is it even possible?)
While replacing the jars of RichFaces I get the following error:
Can not find the tag library descriptor for "http://richfaces.ajax4jsf.org/rich"
What is the cause to this error?
JSP is deprecated since JSF 2.0. It's succeeded by Facelets (XHTML). Therefore, JSF 2.0 compatible component libraries like RichFaces 4+ and PrimeFaces 2+ do not support JSP anymore. Those component libraries do not contain JSP taglibs anymore. Hence this error.
Migrate JSP to its successor Facelets.
See also:
Migrating from JSF 1.2 to JSF 2.0
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?

Validator id is not registered

i am getting this warning in eclipse:
Validator id is not registered
on the line:
<f:validator validatorId="confirmPasswordValidator" />
i am using JSF 2, and tomcat 6
and my el-impl library is org.glassfish.web
any ideas why ?
and how to solve it ?
Ignore and run it. Eclipse is relying on it being present as <validator> declaration in faces-config.xml the JSF 1.x way. It does by default not recognize #FacesValidator and likes yet and therefore don't see it already being registered by new JSF 2.x annotations. The upcoming newer Eclipse versions will.
You could consider to turn off JSF validation in Eclipse preferences, it will only lead to more confusion and annoyances. The upcoming JBoss Tools plugin 3.3 (currently still in beta) will support JSF annotations like #FacesValidator, #ManagedBean, etc.
Note that this is in no way related to EL. You aren't using #{} anywhere.

GWT/Grails Project Structure

Does somebody already have some experience embedding gwt in other
client pages except the standard html file?
I want to use gwt as front end and grails as backend. Communication
should be handled over rest json interface so that is loosely coupled.
How do i structure my project at best? Should I create 2 independend
projects or should I stick them together?
At the beginning I had some problems with debugging my gwt application
as it was part of the grails project. Now I copied the compiled js
script to my webapp folder and included it in a grails page. Debugging
gwt in noserver mode worked ok. The problem is , how do I solve my
deployment later at best as I dont want to copy my js everytime by
hand? Already tried the grails gwt plugin but its difficult to debug the gwt application and I even do not want to use the service stuff provided with the plugin.
I thought its a good idea to have 2 maven modules on for grails and one for gwt. Later 2 war files(one grails, one gwt) will deployed on Tomcat, so I also can change gwt client stuff without deploying grails again. How do i manage the brige from grails to gwt best? Just call the standard html in a div from grails page?
I am using maven for building my project.
Thanks for all your help
I have written 2 posts about this topic. In the first one I show Grails+GWT in the same application, using the Grails Gwt Plugin. It appears you already tried that approach. In the second post, I show how to do it with 2 seperate applications, talking JSON between each other using RequestBuilder to request the grails app (that serves JSON responses).
For The deployment in production, you should have Maven doing this job for you.

Can Jetty be used as a Java EE lightweight application server?

In the scope of deploying small Java EE web applications at various client sites, I am searching for an easy application server solution.
I think I remember hearing that it was possible to use Jetty as a JavaEE 6 lightweight application server but I can't seem to find more evidence on this right now on the web.
Knowing that my development environment is JSF2 + RichFaces, CDI (Weld) and JPA 2 => NO EJBs at this point), is Jetty a possible solution for me?
If yes, could you point me to some docmentation or specific keywords helping me?
If no, what other lightweight Java EE 6 application server should I use?
Jetty is a servlet container, just like Tomcat. At the moment it's utterly unsuited as a Java EE 6 application server since the core requirement for a servlet container in that stack is being a Servlet 3.0 container.
Jetty 7, the latest stable version, is still at Servlet 2.5. At the moment nobody knows when Jetty 8, which will support Servlet 3.0 will be released, but experimental releases can already be downloaded. See http://www.eclipse.org/projects/project-plan.php?projectid=rt.jetty
Even when Jetty 8 will eventually be available, you'll of course still need to add JSF2 (Mojarra), CDI (Weld) and JPA2 (Hibernate).
Currently lightweight alternatives are Glassfish V3 (especially the Web Profile version). This weighs in at a 47MB download and gives you the full web profile. Glassfish starts up in approximately one second on modern systems and something like 2 or 3 on older ones. Memory overhead is minimal.
Yet another alternative is Caucho Resin. It's an inch away from being Java EE 6 Web Profile certified (see http://caucho.com/resin-4.0/changes/resin-4.0.14.xtp), and for all practical purposes is already fully useable as a Java EE 6 application server. Although I haven't personally used Resin, being lightweight seems to be their top priorities.
(do note that 'lightweight' is a vague and much disputed term)
Finally, you could give JBoss AS 6 a spin. Few people would call JBoss AS 'lightweight' (startup time on fast hardware is at least 12 seconds, and its download size is 181MB), but its free and open source and depending on your definition of lightweight those numbers may be 'good enough'.
I was very happy with a solution very similar to yours but using Spring 3 instead of CDI. It's almost the same. Everything was bundled inside WAR and for development mvn jetty:run was enough. No local app server needed.
However I'm sure you can embed Weld CDI implementation inside WAR. Still I'd prefer either "real" CDI JEE 6 stack or Spring.