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
