Won't work because the appserver/servlet-engine has complete freedom of ordering jars in classpath as it likes. Only the order of classpath's is specified (and looking at the weblogi/tomcat-confrontation on the ordering of the classpath's not even that is specified well)...
There is absolutely no garantee that an order of classpath-entries on one machine will be the same when deployed to different hardware... (there are operatins system that order numbers after characters...) regards Alexander -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 1:58 AM To: MyFaces Development Subject: Re: Require ordering of for loading META-INF/faces-config.xml files from component jar Adam Winer 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). I'm still puzzled as to why *anything* needs to be implemented..things work fine as they are. Just set the CLASSPATH order appropriately. Where the CLASSPATH is auto-determined by some tool, add a prefix to the jar filenames. I can't imagine a scenario in which this won't work. Agreed, this isn't a tidy solution long-term, but it seems to achieve everything that the proposed hack does. > > 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 Agreed. This seems an excellent solution to me. A jar might need to have multiple *alias* names, to handle things like one jar being split into two: both jars should have their own names, but should also be able to define aliases to pretend they also have the original name so dependency refs don't break. Having names could also help detect multiple jars in the same path: two jars claiming to be "javax.faces.api" should cause an error, solving the regular problem where people have both the RI and MyFaces in the classpath. > > 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. Agreed. Regards, Simon
