Passing JSF URL parameters to CDI Bean - jsf-2.2

I am in the process of redesigning a project and I've come across what I think is a bug but Im confused as to where the bug is originating from.
Basically all I am trying to do is pass a URL parameter to the backing bean. Nothing magic and there are loads of different ways of achieving this. The following are the ones I use regularly;
I can change the bean from #Named to #ManagedBean and then use the #ManagedProperty
I can access the param using FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap() and then get the desired param from the Map
Or I can use: <f:metadata><f:viewParam name="id" value="#{backingBean.id}"/></f:metadata>
When I'm using JSF 2.1 with Glassfish 3+ all three of these work perfectly. The problem is that my current project is using JSF 2.2 and Glassfish 4 and none of these work! No matter what I do the parameter is never set and always just ends up as null.
I'm not sure how to track this down further. The obvious changes from the last project are that I am using Glassfish 4 instead of 3, JavaEE 7 instead of 6, and JSF 2.2 instead of 2.1.
I don't get any errors or exceptions that I can post.
Is there anything else I can test or any alternative solutions I can try. Failing that is anybody aware of any reported bugs or changes that might cause this. Lastly can anybody reproduce this error?

The problem relates to the namespace!
If you declare the old namespace everything will work fine;
xmlns:f="http://java.sun.com/jsf/core"
If you declare the new namespace it won't work;
xmlns://xmlns.jcp.org/jsf/core
Be careful as netbeans will automatically populate your namespaces. I really hope this saves somebody some time!

Related

Struts 2 security vulnerability issue

We have projects using Struts 2.0 and 2.1.
We're using web-hosting with Tomcat and both projects are working fine on remote servers. Recently, we got warning message from the webhosting provider, like:
This notice is inform you that recently numerous vulnerabilities have been discovered related to Struts and Struts2 frameworks and other frameworks which use OGNL classes.
Since your application is using Struts or Struts2 framework, we HIGHLY recommend that you URGENTLY update it to the most recent version: Struts v2.3.16.1
After research, we found there're consistent upgrades:
http://struts.apache.org/announce.html
Therefore, we tried to upgrade our Struts2 to 2.3.16.3 (latest version at present). However, we found it's not a trivial task to upgrade Struts2, since everything doesn't work, including AJAX tags, AJX form submit, auto-complete, etc. In this sense, Struts 2 is not well designed for scalability.
One example is that whenever we submit our AJAX form, the result will be in a new page instead of in the targets field defined in the sx:submit or sj:submit tag. We don't want to re-write all the codes just because of the upgrade.
We want to know if we don't upgrade Struts2 to the latest version, what kind of vulnerabilities our web application will face. Could anyone give us more details or any hint for solutions based on our situation? Thanks so much.
You are probably looking for Security Bulletins. Each documents describe the summary, problem, and solution to resolve the problem. At the end of each document you can find hotfixes if they are available.
One example is that whenever we submit our ajax form, the result will
be in a new page instead of in the targets field defined in the
sx:submit or sj:submit tag.
It seems you are using struts2 and struts 2 jquery plugin, so try to update to struts 2 jquery 3.7.0 too.
I recommend to accept some reworks and upgrade as some security issues are high.
There are some key parts which has changed and may need to be considered during upgrade like acceptableParameterName. Also review your param interceptor stack and list of exclude parameters.

Migrate jsf application to Glassfish 4 and JSF 2.2

I moved a JSF application from Galssfish 3.1.2 to Glassfish 4.0 and I thought the new server release was completely back compatible.
I found out it is not.
I used an outdated library, Primefaces 2.X, and some components stopped working properly, at least <p:tabview>. Common sense suggests to pass to a newer library such as Primafaces 3.5, but that way I have to modify my xhtml pages. Cannot find a compatibility matrix anywhere, nor a migration tutorial. Can you help ?
There is at least another weird problem outside those related to the Primefaces library.
I have a quite complex page and till now I couldn't isolate the problem to a simpler scenario.
In this page I have an <ui:repeat> tag and then a form with a button.
The button is configured to send Ajax request and update (render) only a single ui component.
At the 3rd Ajax request it stops working and I get an error saying there is a duplicate ID corresponding to the <ui:repeat> tag.
Any idea ?
Is there a migration guide from Glassfish 3.1.2 to Glassfish 4.0 which gives hints on what has changed and how to modify existing applications ?
Update
I found the following post which deals about the last problem I'm talkin about
Component ID xxx has already been found in the view.
Unfortunately I cannot understand how to solve it despite it has an accepted answer !
This is one of the many bugs that were released with GF4.
I would suggest either waiting for the next release of GF (if you need a released version) or update GF to the latest JSF release (Currently 2.2.8 I think).
JSF implementation jars
JEE7 APIs
JSF current and older bugs

Example for CDI-SessionScoped LogIn with TomEE

i'm currently fighting with TomEE, JSF and CDI (i think).
Is there any example out there which has "#javax.enterprise.context.SessionScoped" annotation using TomEE 1.5.1 (or current snapshot)?
I DONT want to use #ManagedBean or something else from javax.faces, just plain CDI.
My problem is: when i change some #SessionScoped user session instance i end up in having a new sessionID (session fixation problem?!?).
My Use-Case:
I want to have a login on one page and have the possability to login from anywhere, the user comes from a JPA-layer which scope i don't know exactly if have to choose.
Is there another way to archieve this?!
I already got this pages, but didn't helped me out:
http://openejb.979440.n4.nabble.com/Guest-user-td4655258i20.html
https://issues.apache.org/jira/browse/TOMEE-734
https://issues.apache.org/jira/browse/TOMEE-745
Thanks for any help!
After a lot of time i created my own "proof-of-concept"-example working with cdi-beans:
https://github.com/FibreFoX/cdi-sessionscoped-login
I hope it will help others, like it helped me while developing that piece of awesome :)
I Use TomEE but I don't understand your problem. Do you use the web-profile?
Did you setup beans.xml correctly?
The bugs you linked are unrelated probably your setup. Impossible to say since I don't have anything to go on. Link a sample project I can try or at least paste your bean and tell were you put beans.xml

What does it means that the partial response writer is not integrated with PPRResponseWriter?

I'm trying to develop an application using JSF, primefaces, Tomcat7.
When I execute an ajax event, I get this warning:
17-ott-2012 9.26.04 org.apache.myfaces.trinidadinternal.context.PartialViewContextImpl getPartialResponseWriter
AVVERTENZA: getPartialResponseWriter() called during render_reponse. The returned writer is not integrated with PPRResponseWriter
What does it means? What do I have to do to integrate it?
In my server log, on startup, I find some messages about some web context parameters not found. May it be related to the previous warning?
Thanks for your help!!
This class is specific to MyFaces Trinidad. Apparently you're mixing Trinidad with PrimeFaces and it's not working very well. Since you didn't mention anything about Trinidad in your question, it's perhaps a leftover of previous experiments to play around with several component libraries. You might want to remove it before using PrimeFaces.

SAXParseException when running Spring 3 JUnit

I just upgraded to Spring 3, and attempted to run some JUnits to make sure everything was copacetic. It wasn't. I got a SAXParseException when loading the context... it complained:
Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans-2.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .
My suspicion is that it couldn't access the XSD due to proxy configuration. Is there a way to make it stop trying so hard to validate it and just run the darn thing? :)
In all seriousness, though, I didn't have a problem when I was running under Spring 2, so I suspect that Spring 2 didn't bother to try to validate, but Spring 3 does. I was hoping there was a way to bypass that functionality.
One further clue... Since I couldn't run the JUnits, I went ahead and fired up the server (this is a web app), and everything seemed to go swimmingly. So that makes me think that Spring is just fine with my context files as they are.
Edit The same error occurs when using instead the Spring 3.0 schemas
It could be because you are using xsd of spring 2. You could try using http://www.springframework.org/schema/beans/spring-beans-3.0.xsd.
As it turns out, my problem was a result of re-bundling the spring jars into a single jar. Just using the separate jars worked fine for me.

Resources