myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Proposal: Modest Restructuring of MyFaces Project
Date Mon, 11 Apr 2005 19:21:23 GMT
On Apr 11, 2005 12:12 PM, Sean Schofield <sean.schofield@gmail.com> wrote:
> [snip]
> 
> > This follows an architectural principle that has been done with all
> > the recent Java APIs, especially the ones that are going in to J2EE at
> > some point.  Indeed, that's going to become an issue for MyFaces with
> > JSF 1.2, which becomes part of the J2EE platform.  It will be
> > necessary to verify that either:
> >
> > * Can load the MyFaces API and IMPL classes from WEB-INF/lib
> >
> > * Can load just the MyFaces IMPL classes and use the built-in API classes
> >
> > (or both) will work in a 1.2 time frame.  Not an issue now, but will be later.
> 
> I've definitely noticed the trend.  So once JSF 1.2 is part of J2EE
> the API will ship with the J2EE server?

Yes.

>  I guess I can see the
> reasoning there.  But wouldn't most J2EE containers also support an
> implementation or is that optional?

No, an implementation will be required as well (just as an
implementation of the servlet API is required).

The challenge will be to support the ability to use an alternative
implementation (to the one built in to the server) -- JSF's
configuration capabilities make that fairly straightforward for the
IMPL classes (you get to configure your own ApplicationFactory,
LifecycleFactory, and so on).  It's more problematic to replace the
API classes, though ... containers have different rules over whether
apps are actually allowed to override "javax.xxx" classes in a webapp.

If you wanted to experiment with this right now, a simple test would
be to install the JSF RI into Tomcat's common/lib or shared/lib
directory, then try to deploy an app with MyFaces JARs in WEB-INF.

Craig


> 
> > Craig
> 
> sean
>

Mime
View raw message