It basically states that it is possible in JSF 2 to perform ValueExpression injection when includeViewParams is set to true on a navigation case.

To illustrate this in a better way, I created an example project at apache-extras, which shows the vulnerability: http://code.google.com/a/apache-extras.org/p/jsf-includeviewparams-security-hole-example/

Use the following steps to run the example:

1. svn checkout http://svn.codespot.com/a/apache-extras.org/jsf-includeviewparams-security-hole-example/trunk/
2. mvn clean jetty:run-exploded -PjettyConfig
3. go to http://localhost:8080/include-view-params-security and follow the instructions

This vulnerability exists, because JSF treats the value of a view parameter as a ValueExpression when performing a navigation case with includeViewParams=true. For further details, see the issues at Mojarra and MyFaces: http://java.net/jira/browse/JAVASERVERFACES-2247 and https://issues.apache.org/jira/browse/MYFACES-3405

Until this is fixed you should avoid using includeViewParams=true!

Together with Marcus Büttner and Mark Struberg I will adapt the relative resource handler for the administration software of the Vienna University of Technology, TISS [2]. For this task the relative resource handler will include some new features apart from supporting relative paths between resources, like e.g. supporting external resource locations. Check out the issue tracker for all enhancements [3]. Also, we already created a wiki page [4] for a list of all requirements.

Stay tuned!

[1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/
[2] https://tiss.tuwien.ac.at/
[3] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/issues/list
[4] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/wiki/Requirements

MyFaces core 2.1.x is now here:

https://svn.apache.org/repos/asf/myfaces/core/trunk/
https://svn.apache.org/repos/asf/myfaces/shared/trunk/
or
https://svn.apache.org/repos/asf/myfaces/current21/

MyFaces core 2.0.x is now here:

https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/
https://svn.apache.org/repos/asf/myfaces/shared/trunk_4.0.x/
or
https://svn.apache.org/repos/asf/myfaces/current20/

I joined the EG, because some issues which were chosen for JSF 2.2, were originated by myself, like JAVASERVERFACES_SPEC_PUBLIC-976 or JAVASERVERFACES_SPEC_PUBLIC-947 (see other blog post). In addition, I will certainly contribute code for some issues, e.g. for JAVASERVERFACES_SPEC_PUBLIC-947 (because this spec issue is the result of my AdvancedResourceHandler in MyFaces commons).

I am really looking forward to working with Ed Burns and the other EG members and to creating a kick-ass new version of JSF!

Created via JIRA’s custom search query api.

There are currently about 330 open issues in the specification issues tracker and the number is slightly growing, since Ed told everyone to file their issues, because otherwise the problem “does not exist”.

Working through the open issues, I found out that there are some parts which do not have a spec issue yet, for example the question of integrating JSF’s managed bean mechanism with CDI (JSR-299) or the concept of CODI’s type-safe view config. Thus I created about 5 new issues in the tracker.

And here they are – my TOP 5 JSF 2.2 issues:

• JAVASERVERFACES_SPEC_PUBLIC-901 – Deprecate “targets” concept
• JAVASERVERFACES_SPEC_PUBLIC-907 – Improve Ajax Http.Get support to (re)render parts of the page
• JAVASERVERFACES_SPEC_PUBLIC-947 – Relative Resources
• JAVASERVERFACES_SPEC_PUBLIC-949 – Window-id
• JAVASERVERFACES_SPEC_PUBLIC-972 – [JSR-303 integration] @Valid support for custom types

The first one comes from a discussion on the jsr-314-open list I had with Ed, Andy Schwartz and some other guys about (how I call it) “the epic fail targets attribute”. The second one is from Matthias Wessendorf and improves the Websocket support for JSF. The third one originates from my Advanced JSF 2 ResourceHandler implementation in MyFaces Commons. The fourth one comes from MyFaces CODI and the fifth one comes from Gerhard Petracek, a colleague of mine from IRIAN who is Bean Validation expert group member.

However, there are some other open issues, which I created, that I cannot vote for (simply because you cannot vote for the issues you created):

• JAVASERVERFACES_SPEC_PUBLIC-977 – Type-safe view config and navigation
• JAVASERVERFACES_SPEC_PUBLIC-976 – Future of JSF Managed Beans and CDI
• JAVASERVERFACES_SPEC_PUBLIC-974 – Add support for conditional comments to h:outputStylesheet and h:outputScript (add condition attribute)
• JAVASERVERFACES_SPEC_PUBLIC-953 – Provide a way to find out if content was defined for a
• JAVASERVERFACES_SPEC_PUBLIC-946 – Provide internal server path of resources from Resource API via EL
• JAVASERVERFACES_SPEC_PUBLIC-796 – Use the model value for a UIViewParameter only on a postbacks
• JAVASERVERFACES_SPEC_PUBLIC-795 – UIViewParameter state saving algorithm
• JAVASERVERFACES_SPEC_PUBLIC-755 – passing through of actionListener, action,.. not possible between composite components
• JAVASERVERFACES_SPEC_PUBLIC-745 – Type of #{cc.attrs.test} cannot be obtained if test resolves to null

I you have some time, check them out and if you find them important enough, please vote! Deadline is Tuesday, April 19th, in the evening.

A new Class was introduced in the EL API 2.2: javax.el.ValueReference. In addition javax.el.ValueExpression now provides the following method:

public ValueReference getValueReference(ELContext context)
{
    return null;
}

This makes wrapping of a javax.el.ValueExpression (which is actually a very common thing in projects like MyFaces or OpenWebBeans) not really an easy task if you have to support both EL versions in one project, because there are a lot of unanswered questions:

• Which EL version should I use to compile the code?
• Should the ValueExpression wrapper implement getValueReference()?
• Do I need one wrapper or two?
• How can I even determine the EL version at runtime?
• …

To find a solution for this problem we have to take a closer look at the Java classloading mechanism:

What does the ClassLoader do?

After a lot of experimenting with different classpath configurations, I found out some pretty interesting things. For the experiments I used the following custom ValueExpression implementation:

import javax.el.ELContext;
import javax.el.ValueExpression;
import javax.el.ValueReference;

/**
 * @author Jakob Korherr
 */
public class MyValueExpression extends ValueExpression
{

    @Override
    public ValueReference getValueReference(ELContext context)
    {
        return new ValueReference("base", "property");
    }

    @Override
    public String toString()
    {
        return "toString() of MyValueExpression";
    }

    @Override
    public Object getValue(ELContext context)
    {
        return null;
    }

    @Override
    public void setValue(ELContext context, Object value)
    {
    }

    // ... other methods cut for clarity ...

}

Of course, you must compile this class using EL 2.2, because otherwise javax.el.ValueReference will not be present and you will get a compile error.

Now if you use this custom ValueExpression in any scenario in an EL 2.2 environment, everything will work just fine. However, the interesting part is using this class in an EL 1.0 environment, because here javax.el.ValueReference is NOT available.

At first I thought I will get a NoClassDefFoundError as soon as I use a MyValueExpression instance with EL 1.0. Thus I created the following test:

public static void main(String... args)
{
    ValueExpression m = new MyValueExpression();
    System.out.println(m);
}

However, it went well and I got “toString() of MyValueExpression” although my class references javax.el.ValueReference, which was not on the classpath.

Then I added private ValueReference valueReference; to MyValueExpression and ran the test again. To my surprise, it worked well again!

After a lot of tests, I found out just 2 scenarios which did not work with EL 1.0:

1) Calling a method on MyValueExpression which creates a new ValueReference or tries to call methods of it. OK, this can obviously not work with EL 1.0. You will get a java.lang.NoClassDefFoundError: javax/el/ValueReference

2) Calling m.getValueReference(). Here you will get the following error, because obviously this method is not available in EL 1.0: java.lang.NoSuchMethodError: javax.el.ValueExpression.getValueReference(Ljavax/el/ELContext;)Ljavax/el/ValueReference;

Solution

Because of the above findings you can just use EL 2.2 as compile dependency in your project and everything will work just fine also with EL 1.0, as long as you:

1) do not call ValueExpression.getValueReference()
2) do not call any method on ValueReference
3) do not create an instance of ValueReference

…outside of the getValueReference() method of your javax.el.ValueExpression implementation. Inside this method, you can do all of the above, because you will only get into this method if you’re using EL 2.2 at runtime!

Thus you can use this wrapper without any problems on EL 1.0:

import javax.el.ELContext;
import javax.el.ValueExpression;
import javax.el.ValueReference;

/**
 * @author Jakob Korherr
 */
public class ValueExpressionWrapper extends ValueExpression
{

    private ValueExpression wrapped;

    public ValueExpressionWrapper(ValueExpression wrapped)
    {
        this.wrapped = wrapped;
    }

    @Override
    public ValueReference getValueReference(ELContext context)
    {
        // You will only get here if EL 2.2 is available at runtime.
        // Thus you can use ValueReference without any problems!
        return wrapped.getValueReference(context);
    }

    @Override
    public Object getValue(ELContext context)
    {
        return wrapped.getValue(context);
    }

    @Override
    public void setValue(ELContext context, Object value)
    {
        wrapped.setValue(context, value);
    }

    // ... other methods cut for clarity ...

}

Using this wrapper in a pure EL 2.2 environment will not cause any problems when calling getValueReference() on the wrapper, because javax.el.ValueReference is provided by EL 2.2 at runtime.

Using this wrapper in a pure EL 1.0 environment will have the effect that getValueReference() is not visible at runtime and thus it will never get called and not cause any problems.

Running a Swing application on Mac OS X Java, you normally use the Mac look-and-feel com.apple.laf.AquaLookAndFeel out of the box. The UI classes of this look-and-feel support various client properties, which can be set via putClientProperty(Object key, Object value) on every JComponent. Now, to get a search-style for your JTextField you just have to set the following property:

jTextField.putClientProperty("JTextField.variant", "search");

And now your plain old JTextField looks like this:

In addition, there are a lot of other client properties, which can help you in building Mac OS X-style applications in Swing: http://developer.apple.com/library/mac/#technotes/tn2007/tn2196.html

Unfortunately this will only work when running the aforementioned Apple look-and-feel on a Mac OS X Java runtime environment (which will most likely be not available for > Java 6).

I already started a thread about the targets attribute of composite components. I kinda consider it an epic fail, and I already got consent of other EG members. Check it out: http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000604.html

This util class from CDI (JSR-299) implements all standard methods (toString(), equals(), hashCode(), annotationType()) just like an annotation instance created by Java would. Thus there is no real difference between subclasses from this class and the annotations created by the JRE.

Here you can find the source code of AnnotationLiteral from Apache Geronimo Specs: AnnotationLiteral.java

Example

For example you have the following annotation (which is also a CDI qualifier):

@Target({PARAMETER, FIELD, METHOD, CONSTRUCTOR, TYPE})
@Retention(RUNTIME)
@Documented

@Qualifier
public @interface ConversationQualifier1
{
    String value();
}

If you want to create an instance of it with a certain value at runtime, just create the following class:

public class MyConversationQualifier1
    extends AnnotationLiteral<ConversationQualifier1>
    implements ConversationQualifier1
{

    public String value()
    {
        return "my assigned value";
    }
}

Now you just need to create an instance of it and you can use it like any other annotation instance created by Java.

Annotation a = new MyConversationQualifier1();