Category Archives: jsf

16 Jun

ThoughtWorks on JSF

On their technology radar, ThoughtWorks describes JSF as a framework with which many people have problems. Moreover, they actually recommend to avoid this technology.

Although I cannot completely agree with ThoughtWorks, their summary is true to some extend. The JSF EG really must address this, or else JSF will cease to exist.

06 Jun

Bachelor thesis finalized at last: introducing Clean REST URLs

I am really very, very happy to announce that my bachelor thesis about the relative-resource-handler is now finally completed. In the end, I must admit that it took me quite a while to get the thesis to an official end, however, I am now even more excited about it.

Here is the final version of my thesis: Evaluation of State-of-the-Art resource handling in JavaServer Faces based web applications and development of an enhanced resource handler for JSF 2.

The thesis describes general problems in resource management of JSF based web applications, it presents common solutions and frameworks for resource handling (like Weblets), and finally, it introduces the relative-resource-handler. In addition, the thesis introduces the term “Clean REST URLs“, describing URLs, which are purely structural, which do not contain a query string, which instead contain only the path of the resource, and which are used to identify a resource the REST way. Clean REST URLs are used by the relative-resource-handler to deal with many problems that arise in the context of resource handling. More details about it can be found in the thesis PDF.

Some personal notes: I first started to work on my thesis in November, 2011, as announced in this blog post. After an initial burst of enthusiasm, I soon reduced my efforts, because of various other commitments (mostly my job at IRIAN, and other courses at university). Eventually, I continued work on the thesis in the fall of 2013, and now, after many hours of work, and many discussions with my scientific advisors (mostly Marcus Büttner), the thesis finally got accepted and graded (receiving the best possible grade, yay!). I can now officially end my bachelor studies at Vienna University of Technology, and enroll in the master programme. By the end of June, 2012, I was actually finished with my bachelor studies, however, I needed to complete my bachelor thesis to formally switch to the master programme. I therefore took the courses needed for my master programme in the context of yet another bachelor programme, which, fortunately, is possible at the Vienna University of Technology. This way I was able to complete most of my master courses, without being formally enrolled in the masters programme. Actually, as of today I am already very close to finishing my master studies, I have almost finished all required courses. I still need to write my master thesis though, which will most likely take another year.

22 Nov

JSF value expression injection vulnerability

A few days ago this issue was reported to Mojarra: http://java.net/jira/browse/JAVASERVERFACES-2247.

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!

08 Nov

Bachelor thesis about relative resource handler

I am very happy to announce that I will write my bachelor thesis at the research group for industrial software (INSO) at Vienna University of Technology. The thesis will be about my work on the relative resource handler for JSF 2 [1].

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

02 Mai

MyFaces 2.1 is now trunk

After a discussion about keeping our 2.0.x and 2.1.x branches in sync last week on the MyFaces dev mailing list, we decided to promote the 2.1.x branch to trunk. In addition, we created a 2.0.x maintenance branch.

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/

29 Apr

JSF 2.2 Expert Group

I just joined the JSF 2.2 (JSR 344) Expert Group. However, my request is not 100% done, I need to sign and fax the JSPA first (will do so next week).

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!

17 Apr

JSF 2.2 – Vote for your top 5 issues

In the JSR-344 (= JSF 2.2) expert group kick-off meeting last wednesday in Vienna, Austria (which I was very glad to attend), the expert group agreed on letting everyone involved in JSF vote for their top 5 specification issues in the issue tracker. Ed Burns also announced this in this blog post.

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:

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):

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.

15 Dez

How to wrap a ValueExpression in EL 1.0 and 2.2

The problem

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.

31 Okt

JSR-314 extended expert group

Since this week I am allowed to post to the jsr-314-open mailing list and thus considered a member of the JSR-314 extended expert group. I am very happy with this, because I can finally raise my concerns with JSF 2.0 and 2.1 and also join some interesting discussions.

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