For a good article on integrating Struts, JSF, and Tiles see the following: 

[From a DEV list posting by Craig { { { McClanahan } } }, 06 Jun 2003]

From watching a wide variety of conversations floating arount the 'net, it seems [many people don't understand a few things about Java software and licensing.] Here's a few thoughts that should help illuminate the situation. This is a pretty short summary -- more detailed information can be gathered from the Java Community Process web site: 

The most important thing to understand is the difference between the licenses for Java specifications (i.e. the functionality that any product claiming to be complaint must provide) and implementations of those specifications.

Java Specifications are created under the auspices of the Java Community Process (JCP), and you can keep track of progress at at . { { { JavaServer } } } Faces, in particular, is being developed under JSR-127. When a JSR is originally proposed, the proposer (Sun, in the case of JSR-127) must also provide the proposed business terms that they anticipate the specification will be licensed under, once it is complete. It is, and has always been Sun's intention, that the terms for JSR-127 would be substantially similar to the terms that resulted from the discussions with Apache last year -- indeed, you will probably remember substantial discussions last year between Apache (and others) and Sun to address the licensing issues for Java technology, particular with respect to open source implementations.

Jakarta Web Site Info About The Agreement: 

Sun's Letter Of Intent: 

The upshot of this is that, over a year ago, Sun agreed to modify the license terms for many JSRs, and included funding scholarships for non profit open source organizations that wish to prove their implementations are compatible with the specification. { { { JavaServer } } } Faces (JSR-127) is specifically listed as one of the Sun-led JSRs which would have business terms that support the ability for open source organizations to create an implementation that is compatible.

Now, remember -- a specification is not software -- it is a bunch of requirements that any software wanting to say that it "implements { { { JavaServer } } } Faces" must adhere to. So, how does anyone know that a Java specification can actually, in fact, be implemented in a way that meets all the specification requirements? And, how can you tell if any specific implementation does, in fact, meet the requirements?

The JCP process requires that the specification lead (again, Sun, in this particular case) must also supply a Reference Implementation (RI), to prove that one can actually create a compliant implementation, and a Technology Compatibility Kit (TCK) that can be used to test the compliance of any implementation. Currently, the RI that Sun offers for { { { JavaServer } } } Faces is available under an "early access" license (since the spec isn't final, no redistribution is allowed -- did you notice that the struts-faces distribution doesn't include the jsf-api.jar and jsf-ri.jar classes? this is why -- I don't get to break the rules even though I'm co-spec lead, and am heavily involved in the RI implementation and testing :-). How the RI is licensed is pretty much up to the spec lead and the expert group.

Note, however, that the RI is very unlikely to be the only implementation of { { { JavaServer } } } Faces that ever exists. In fact, because of the Apache agreement, it's perfectly feasible for any open source group to decide that they want to create an open source implementation of { { { JavaServer } } } Faces, and pass the TCKs so that you can prove it. Sun will even offer assistance to qualified non-profit organizations that wish to attempt this. I know of at least one open source implementation effort that was started over at { { { SourceForge } } }; there's no restriction on how many implementations there are in the world.

This is exactly analogous to the way that the world is with servlet and JSP. For example, the Servlet 2.3 (and JSP 1.2) specifications were created under JSR-53 in the JCP process. (For the next round, Servlet 2.4 is being developed in JSR-154, and JSP 2.0 is being developed in JSR-152). Sun was and is the spec lead of these specs, and provides a reference implementation -- the J2EE RI -- which (for the servlet and JSP specs) happens to incorporate code that comes from Tomcat.

But, is Tomcat the only implementation of the Servlet and JSP specs in the world? Not by any stretch of the imagination. There are multiple open source and closed source implementations -- in fact, every J2EE app server needs to provide an implementation of these APIs in order to meet the overall J2EE requirements. Some incorporate pieces of Tomcat; some write their own; some incorporate third party code from other suppliers). But all of those implementations need to pass the TCKs in order to claim that they are actually implementations of the corresponding specs.

In short, there is no such thing as "open sourcing" the { { { JavaServer } } } Faces specification itself, because it's not software. There is absolutely an ability for multiple implementations to be created (open source or not doesn't matter -- compliance matters). Or, if you don't believe that { { { JavaServer } } } Faces is the right answer to the "web application user interface components" technology problem, then you can go implement your own APIs and your own framework -- that's fine, and in that case nothing about { { { JavaServer } } } Faces need concern you (except for the fact that more than a few software producers do seem to care about it, so your cool widget library is going to have some serious competition :-).

A couple of points about the Struts-Faces interface library in particular might also be of interest.

As for whether { { { JavaServer } } } Faces is good or bad technology ... I'm willing to let the market answer that question. :-). But I can guarantee you that there are already millions and millions of client devices that can already utilize { { { JavaServer } } } Faces based applications, versus hundreds? thousands? that can use cool things like XForms or XUL today.

Of course, even that comment oversimplifies things a little too much, because it leaves the impression that { { { JavaServer } } } Faces is just for HTML based browsers. That's not the case at all -- if you're at { { { JavaOne } } }, you'll enjoy seeing an SVG based rendering of the same application (with zero changes to the back end logic). Creating renderkits for wireless devices (or even rendering XUL and XForms if you like -- there's a small sample XUL renderkit in the "demos" directory).

I can tell you one thing, though ... working on { { { JavaServer } } } Faces has already had very positive impacts on my professional career. :-)

[From a USER list posting by Craig { { { McClanahan } } }, 16 Sep 2003]

{{{ >> Reading through Sun's Web Services Tutorial section on JSF, things are

Yep ... there's quite a bit of overlap, and { { { JavaServer } } } Faces is FAR more than "a component tag library".

{{{ >> .: Anyone know of a resource that summarizes/contrasts solutions provided by

I'll throw in a few short comments below, but caution you that this is based on the EA4 release of { { { JavaServer } } } Faces. Things are still evolving rapidly. (My comments ought to have at least a little relevance, because I'm both the original author of Struts and the co-spec-lead for { { { JavaServer } } } Faces .

  >>     -UI Components 

Struts doesn't really have any notion of components at all (the closest thing is properties of a form bean), while { { { JavaServer } } } Faces has a fairly rich component model that is accessible at both the Java and JSP levels (JSP is not required), supports a separate rendering model (so you can render something like a "select one" control as either a set of radio buttons or a <select> element with one simple change) and is not tied to HTML -- although the default render kit included will be HTML specific. Out of the box, you'll get complex components like a grid and an editable table, and there are already demonstration components for things like trees and menus that (in a Struts world) require additional add-on tag libraries.

For people who have existing Struts expertise and/or applications, this is the key value add of integrating { { { JavaServer } } } Faces -- you can use the fancy UI component model without having to change your back-end form beans or actions.

  >>     -controller components 

This is where Struts shines, and I assume you're familiar with that. { { { JavaServer } } } Faces uses a somewhat different abstraction for navigation, and defers the decision of what page to display next to a { { { NavigationHandler } } } that is configured with a set of rules -- the next page is determined by matching rules for:

{ { { JavaServer } } } Faces is more flexible in how you organize your processing logic -- you can maintain a Struts-like model of separate "form beans" and "action classes", or you can combine them together (somewhat like how code-behind pages work in ASP.Net).

Struts has a couple of framework features (Tiles and the Validator Framework) that are beyond the current scope of { { { JavaServer } } } Faces -- but one advantage of the integration library is that you'll be able to use these sorts of technologies together.

>> -model components

Being presentation frameworks, both technologies are mostly focused on the view and controller. The important part becomes how the presentation tier and model tier object communicate values:

  <bean:write name="customer" property=""/> 

  <h:output_text valueRef=""/>: 

  >>     -Page Flow 

Neither technology has direct support for page flows. There are add-ons for Struts already; I have no doubt that such things will emerge for { { { JavaServer } } } Faces as well.

  >>     -etc. 

Because Struts is a fairly popular technology, you'll find quite a lot of support for it in development tools. I expect to see the same sort of thing happen for { { { JavaServer } } } Faces; indeed, at { { { JavaOne } } } this year both Sun and Oracle did keynote previews of their upcoming development tools that will be based on { { { JavaServer } } } Faces, and lots of other providers have promised support for it as well.

[From a Struts USER list posting, 17 Sep 2003]

{{{ >> I remember a while ago in one of these architecture- theme emails you

{ { { JavaServer } } } Faces is designed to give you options to organize things either way. Here's one example of a logon form (and associated back-end logic) that combines the Struts notions of { { { ActionForm } } } and Action into a single class (corresponds to the syntax in the EA4 release):

JSP PAGE (/logon.jsp)

{{{ ...


{{{ ...


{{{ package mypackage;

In this scenario, you can see that the form field values are stored in the same bean as the processing logic. Therefore, the processing logic can just use the field values directly (they are in the instance variables). However, it's only in the same class because the page author used "logonForm" at the beginning of the valueRef and actionRef expressions -- they could just as easily have been stored in separate files.

A couple of things not real obvious from this simple example, but interesting nevertheless:

If no rule matches, the current page is redisplayed. I've adopted the convention in my code to return null as the logical outcome if this is what I want (i.e. the logon failure case here).

The above example is likely to be typical if you're writing a new applicaton from scratch based on { { { JavaServer } } } Faces. But what if you've got an existing application based on Struts, and you just want to use { { { JavaServer } } } Faces to get the fancy UI widgets? That's where you would use the struts-faces integration library, because it lets you change just the JSP pages, and keep all your back end actions and form beans from before.

{{{ >> The reason I ask is that I just had a hard time redesigning a page

In Struts, I would tend to model this sort of thing as a single form rather than two different forms.

In { { { JavaServer } } } Faces, there will be a nice "editable table" or "data grid" type component that supports this type of use case.

{{{ >> Fortunately I solved it nicely by nesting the child objects in the

Makes sense.

  >> Adam 


To unsubscribe, e-mail: For additional commands, e-mail:

StrutsMoreAboutJSF (last edited 2009-09-20 23:12:29 by localhost)