I've found the instanceof operator in JSF EL, but it throws an exception when used. It's obviously reserved but not implemented? When will it (probably) be available, if not already in a newer version than JSF 1.2, which I'm currently using?
The keyword instanceof is indeed reserved in the EL (see here), but it is still not used in the latest version of EL (2.2), used in JSF 2.x.
Related
Jsf page with myFaces trinidad 1.2.15 ver JSF 1.2-20 could not be parsed due to expression evaluation error over ELContext. here is the stack
Caused by: java.lang.NullPointerException
at com.sun.el.ValueExpressionLiteral.getValue(ValueExpressionLiteral.java:79)
at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty(UIXComponentELTag.java:135)
at org.apache.myfaces.trinidadinternal.taglib.html.HtmlHeadTag.setProperties(HtmlHeadTag.java:70)
at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperties(UIXComponentELTag.java:122)
at javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:230)
at javax.faces.webapp.UIComponentClassicTagBase.createChild(UIComponentClassicTagBase.java:513)
at javax.faces.webapp.UIComponentClassicTagBase.findComponent(UIComponentClassicTagBase.java:782)
at javax.faces.webapp.UIComponentClassicTagBase.doStartTag(UIComponentClassicTagBase.java:1354)
at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.doStartTag(UIXComponentELTag.java:71)
at jsp_servlet._jsp._btwizard.__btwizardmain._jsp__tag2(__btwizardmain.java:648) ....
The problem was that the setProperty method of UIXComponentELTag by default passes a null argument for ElContext as this:
bean.setProperty(key, expression.getValue(null));
This is not supported on the version of elcontext that weblogic12 uses. We were not allowed to change the version of trinidad being used so we had to patch the library changing all the calls of getValue with
bean.setProperty(key, expression.getValue(FacesContext.getCurrentInstance().getELContext()));
We also found this problem on some clases that were generated from XML files like Color.xml, DateTime.xml and Number.xml, so we had to prevent them from being generated and provide our own implementation.
In JSF 2.2 new <f:viewAction> component was introduced and more importantly along with it a way to protect pages, that leverage this functionality, from CSRF attacks.
The feature is mentioned in the JSF 2.2 specification:
Call ViewHandler.getProtectedViewsUnmodifiable() to determine if the view for this viewId is protected. If not,
assume the requested view is not protected and take no additional view protection steps. Obtain the value of the
value of the request parameter whose name is given by the value of
ResponseStateManager.NON_POSTBACK_VIEW_TOKEN_PARAM. If there is no value, throw
ProtectedViewException. If the value is present, compare it to the return from
ResponseStateManager.getCryptographicallyStrongTokenFromSession(). If the values do not match, throw
ProtectedViewException.
...
What got me curious is how is the token used by getCryptographicallyStrongTokenFromSession() method generated in Mojarra, since that is the JSF implementation we use for some of our applications.
I was quite surprised to find out that the implementation in versions prior 2.2.11 looks like this:
private String createCryptographicallyStrongToken() {
// PENDING: http://java.net/jira/browse/JAVASERVERFACES-2204
String result = "" + System.currentTimeMillis();
return result;
}
Since version 2.2.11 it seems to be implemented more robustly with the currentTimeMillis actually being encrypted using AES.
Since the non-encrypting versions of this implementation made their way into final releases of Wildfly 8.x server (8.0.0.Final, 8.1.0.Final, 8.2.0.Final and 8.2.1.Final) does this mean that applications deployed on these servers and relying on <protected-views> functionality are vulnerable?
How can I pass an arugument to listener method?
I have tried like this:
<p:poll interval="3" listener="#{vehicleController.onPoll('12')}"
update="vehicleDataList"/>
and
<p:poll interval="3" listener="#{vehicleController.onPoll(vehicle.vehicleLicense)}"
update="vehicleDataList"/>
But it throws the following exception:
javax.servlet.ServletException: /monitorVehicles/vehiclesList.xhtml
Failed to parse the expression [#{vehicleController.onPoll('12')}]
How can I achive this?
getting this exception "Failed to parse the expression [#{vehicleController.onPoll('12')}]"
Your environment doesn't support the new EL 2.2 feature of invoking methods with arguments.
EL 2.2 is part of Servlet 3.0, thus in order to utilize it, you need to deploy to a Servlet 3.0 compatible container (e.g. Tomcat 7, Glassfish 3, JBoss AS 6, etc) with a Servlet 3.0 compatible web.xml file. If you don't deploy to a Servlet 3.0 compatible container, or don't have a Servlet 3.0 compatible web.xml, then you aren't using EL 2.2 at all and you will get this kind of exception.
If you're actually targeting/deploying to a Servlet 2.5 compatible container (and thus using EL 2.1), then you can use JBoss EL to have the new EL 2.2-like features in EL 2.1.
See also:
How to call a method with a parameter in JSF
Invoke direct methods or methods with arguments / variables / parameters in EL
In JSF 2:
If your listener is expecting a string:
"#{vehicleController.onPoll('11')}"
public void onPOll(String s){
}
If your listener is expecting an int:
"#{vehicleController.onPoll(11)}"
public void onPoll(int i){
}
I'm trying to learn JSF and EL and I am facing the following error:
/index.xhtml #20,120 actionListener="#{contatosController.adicionar(actionEvent)}" Q
What does that mean and how can I solve it?
It means that your environment does not support the EL 2.2 feature of invoking methods with arguments. The EL syntax #{bean.method(argument)} is unsupported in EL 2.1 and older and therefore unparsable. Just get rid of that argument. JSF fills it in by itself anyway.
actionListener="#{contatosController.adicionar}"
Please note that even if you upgraded to EL 2.2, it would still end up in trouble as you're essentially passing null to it (you don't have a managed bean #{actionEvent}, right?). You should actually never need to specify the default argument of a JSF (action)listener method yourself.
See also:
How to call a method with a parameter in JSF
Differences between action and actionListener
I'm generating a jaxws client based on webservice. Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
However if I try to link the boolean (e.g. isOptional()) to a checkbox, it will throw the following exception:
value="#{property.optional}": Property 'optional' not readable on type java.lang.Boolean
My google skills have informed me that jsf works fine with:
boolean isOptional()
boolean getOptional()
Boolean getOptional()
But not with
Boolean isOptional()
However it is not feasible to update the beans manually due to the size and amount of the webservices, so is there any way to make jsf use the java.lang.Boolean isOptional() properly? Or can I somehow define a property in the jaxb bindings file at generation time which magically generates "getOptional()"?
On a sidenote, the following does work:
<h:selectBooleanCheckbox value="#{property.isOptional()}"/>
However I can't actually update the value presumably because it can't find the setter.
EDIT: I'm running the latest jdk 7, the output of "java -version":
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
The output of "wsimport -version":
JAX-WS RI 2.2.4-b01
Generated code:
public Boolean isOptional() {
return optional;
}
Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
Using the is getter prefix for java.lang.Boolean was a known major mistake of JAXB. It has been fixed in version 2.1.13 which was released April 2010 already. Keep your libraries up to date.
See also this blog article for some background.
The Great JAXB API Blunder
September 15, 2006
You've got to hand it to Sun for screwing this one up. It's one thing to write software that doesn't adhere to a specification when the documentation is as thick as a textbook. Take, for example, just about anything created by the W3C. However, it's really bad when it is your own spec that you can't follow, especially when it is the most well known part of it. That's right, Sun missed by a mile on their own spec when they created the JAXB 2.0 API. The JAXB 2.0 compiler (XJC) incorrectly uses the prefix "is" rather than "get" when generating the getter method for a java.lang.Boolean property. While the JavaBean spec states that read methods for primitive booleans can use the alternate "is" prefix, this flexibility does not extend to its boolean wrapper counterpart.
8.3.2 Boolean Properties
In addition, for boolean properties, we allow a getter method to match the pattern:
public boolean is();
This "is" method may be provided instead of a "get" method, or it may be provided in addition to a "get" method. In either case, if the "is" method is present for a boolean property then we will use the "is" method to read the property value.
An example boolean property might be:
public boolean isMarsupial();
public void setMarsupial(boolean m);
Given that JAXB is a code generation framework, and the idea behind code generation frameworks is that the code is to be used "as is" and not modified thereafter, this is a pretty big "oops". While this issue has been reported, the response from Sun is "sorry, its too late".
This behavior is governed by the spec, and unfortunately it's just too late for the spec to change now.
In terms of the user experience, thanks to auto-boxing, I don't think this will be a real issue for people. Is the problem that you are using Introspector and it's missing the property?
Too late? Not a real issue? It's BROKEN. FIX IT! I also don't like the naive statement that it probably won't affect frameworks. Um, yes it will, considering other projects did happen to adhere to the spec (hibernate, spring, myfaces, etc.)
UPDATE: Stevo Slavic informed me that this has been fixed in JAXB 2.1.13. See JAXB-131 for details. Yeah!
JSF/EL is not at fault here. It's doing its job properly conform the JavaBeans spec.
I'm not sure why the latest and greatest JAXB version still generates the wrong method but I finally fixed it by adding "-B-enableIntrospection" (as per http://jaxb.java.net/2.2.4/docs/xjc.html) to the wsimport call. This results in:
public Boolean getOptional() {
return optional;
}