Due to a vulnerability with Glassfish 3.1.2 (The host still accepts TLSv1.0 which is deprecated and has issues), I've been asked to migrate a JSF 2.2 web application to Glassfish 5.0.1.
Is there any way to stop using TLSv1.0 on GlassFish 3.1.2?
If not, what are the steps to follow for being compatible with this Glassfish 5.0.0 in terms of dependencies, JSF version, and so on, in the web app?
Many thanks in advance
To disable TLSv1.0 on GlassFish on the admin console go to Configurations->server-config->HTTP Service->HTTP Listeners->Http Listener 2->SSL then uncheck the box for TLS and click save. If versions above TLS1.0 are available then they should be listed there and checked.
Alternatively run the asadmin command set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls-enabled=false.
N.B. I do not know if GlassFish 3.1.2 supports TLS 1.1 or later, but GlassFish 4 later does.
Related
I have a small Richfaces web application hosted on a JBoss EAP 6.4 server. I want to now run the app instead on a JBoss EAP 7.0 server, and modify the app to use Primefaces v6.1 instead of Richfaces.
Can anyone tell me (or make an educated guess) as to what may be some new security concerns or implications for doing so?
Thanks
I started to read about wicket integration with liferay. I found very old information that wicket portlet is no longer supported, but wicket version 1.5.6 works fine with liferay 6.0. What about Liferay 6.2?
Just yesterday a user from the community created a Pull Request to fix the support for Liferay: https://github.com/wicketstuff/core/pull/476.
The Pull Request is for WicketStuff 7.x though. You are very welcome to port the fixes to wicket-6.x branch and we will add them for WicketStuff 6.23.0.
WicketStuff 1.5.x is not maintained anymore.
Apache Wicket version 6.x, 7.x and 8.x supports JSR286 portlets.
Please see the following wiki of how to use the apache wicket portlet bridge.
https://github.com/wicketstuff/core/wiki/Portlet
I'm using OmniFaces 1.6 currently, with an application running JSF 2.2.6, Weld 1.1.9, on a Tomcat 7.
I've tried updating OmniFaces to 2.0, but when I do, I get this error message while launching the application (and the application doesn't start):
This OmniFace version requires CDI, but none was found on this environment. OmniFaces 2.x requires a minimum of JSF 2.2
It links to this page: http://omnifaces.org/cdi/
The problem is that, as I said, the application definitely uses JSF 2.2 and CDI.
Any ideas on what could be wrong?
I had same issue with you.
Please check this
http://omnifaces.org/cdi/
here are the additional instructions:
Install CDI 1.1+ in this environment.
For Tomcat users who don't have freedom in server choice, refer this
article: How to install CDI in Tomcat? When installing Weld, make
sure that you're using a minimum of version 2.2.0! Older versions have
initialization ordering bugs.
Switch to a CDI 1.1 capable environment.
For Tomcat users who have full freedom in server choice, just replace
Tomcat by TomEE, or perhaps even by WildFly.
I am migrating a JSF application from WebSphere(WAS) 6.1 to WAS 7.0 and I am experiencing html deprecation issues now that I am using the JSP 2.1 API provided with WAS 7.0 as opposed to the JSP 2.0 API provided with WAS 6.1. Weblogic provides the ability to enable backward compatibility (http://docs.oracle.com/cd/E21764_01/web.1111/e13754/compat.htm#i1111538) in the weblogic app deployment descriptor. Is there a similar solution available in WAS 7.0? Is there a way to enable backwards compatibility in a deployment descriptor so the application can use JSF 2.0 API and not face the deprecated html issues?
There is nothing conclusive about this in the WebSphere Application Server 7.0 documentation, therefore I am led to believe that the typical IBM strategy is used here: The JSP engine you're getting with WAS 7.0 is JSP 2.1 compatible, period. You can't replace it and can't instruct WAS to use an older specification level.
Can someone please help me out with the Oracle ADF faces application which I'm trying to deploy on Websphere 7.0? Do I need to apply any fixpacks on WAS? I'm trying to migrate this project from Websphere 6.1 to Websphere 7.0.
In Websphere 6.1, after removing jsf implementation jar files and providing them as part of WEB-INF\lib and changing the classloader to PARENT_LAST, the application was working fine.
For websphere 7.0, I can't seem to get the application working. It always picks up the Sun's JSF implementation. I've also tried the shared library concept but to no success.
Regards,
Zahir
The Oracle documentation lists a certification for WAS 7.0.0.13 ND. So you need FixPack 13 or later.
As the WebSphere Application Server 7 is a full blown JEE5 server it requires/has JSF 1.2 support. You can switch between the built in Sun and MyFaces implementation if required.
You should probably make sure that the ADF version you are using is certified for WAS 7. The ADF release notes tell that ADF supports JSF 2.0. The WAS 7 only comes with JSF 1.2. Exchanging the JSF version with placing the JSF 2 libs into WEB-INF/lib works well for our projects in conjunction with the 'PARENT_LAST' classloading policy. Make sure that you set the policy either for the whole application or for both the application and the web module.
ADF Faces is a Java based framework and it will run on WebSphere but, you have to add the required libraries first. The easiest way to prepare WebSphere to run ADF Faces application is through JDeveloper. Alternatively, you can google Oracle JRF (Java Runtime Framework) and install that on your WebSphere, before running the ADF Faces application.