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
