Sounds good to me!

especially a solution where we don't need a new type of configuration
file would be great ;)

regards,

Martin

On 12/6/05, Adam Winer <[EMAIL PROTECTED]> wrote:
> Yes, the desire for a real solution and the permanence of anything
> that does get into the spec was the reason why we deep-sixed
> any hacky fix.  A lot of times - in the world of long-living specs -
> doing nothing is by far the best solution.
>
> I do think that Ed has a point that MyFaces would do well to
> mimic the JSF 1.2 solution;   it will do no harm (other than
> time spent implementing it).
>
> My preferred complete solution is something along the lines of
> giving a particular faces-config.xml file an ID (e.g., MyFaces tomahawk
> might be "org.apache.myfaces.tomhawk"), and then stating
> in each file what dependencies it has;  so you could explicitly
> say in a faces-config.xml file "I come *after* Tomahawk";  then you leave
> it up to the implementation to come up with a legit ordering of all the
> identified files
>
> Other solutions I've seen are just lousy.  Numbers (like servlet loading
> orders) are a pain in the arse, especially with these faces-config.xml
> files distributed around JARs built by multiple people.  And specifying
> explicit orders in a web.xml file is rather poor too - we should not
> be making end users configure even *more*.  (The goal of J2EE should
> be eliminating required configuration.  It bugs me, for instance, that in
> J2EE 5.0, a user still has to explicitly register FacesServlet.  Why?)
>
> Of course, I'm open to any brilliant ideas out there. ;)
>
> -- Adam
>
>
> On 12/5/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > Ed, I understand that you needed a short-term workaround, and I'm
> > overjoyed to hear you confirm to others that it's not in the spec this
> > way.
> >
> > I still think our time (the Myfaces committers' time) would be better
> > spent creating a full solution rather than implementing the
> > workaround.   The workaround is only in JSF 1.2 anyway, and not JSF
> > 1.1, so any solution we create under MyFaces is going to be different
> > (or "incompatible") with JSF RI 1.1's loading scheme.
> >
> > However, it's open source, so whoever's doing the work is going to
> > determine the initial behavior. :)
> >
> > On 12/5/05, Ed Burns <[EMAIL PROTECTED]> wrote:
> > > > > At the time of the original discussion, we
> > > > proposed better ways of
> > > > > handling this which should be archived in the
> > > > mailing list.  (I think
> > > > > Martin and Craig were also involved at the time,
> > > > and we hammered out a
> > > > > reasonable dependency-handling approach).  I'm not
> > > > really sure why Ed
> > > > > went with it the way he did because no one else
> > > > was happy with that
> > > > > approach.
> > >
> > > As I said previously, I just put this in the Sun impl
> > > because we had a short term need for a deterministic
> > > approach to loadine META-INF/faces-config.xml files.
> > > I agree it's not the best approach but you must agree
> > > that it is unobtrusive.  I only intend it to be used
> > > in a pinch, anyway.
> > >
> > > Ed
> > >
> > >
> > >
> > > __________________________________________
> > > Yahoo! DSL – Something to write home about.
> > > Just $16.99/mo. or less.
> > > dsl.yahoo.com
> > >
> > >
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Reply via email to