Hi,
I struck this problem when I had to override the renderer for tomahawk's
JSCookMenu component. My jar's faces-config.xml needs to be processed
after the tomahawk one in order for my renderer to override the tomahawk
one.
I believe that MyFaces processes files in the order returned by
ClassLoader.findResources, and that this is controlled by the order in
which jars occur in the classpath.
So isn't it just a matter of ensuring that jars that need to be
processed later occur later in the classpath?
In the case of jars in a WEB-INF/lib dir, there isn't explicit control
over the order of them in the classpath. But there is *implicit*
control; it's reasonable to expect that these will be added to the
classpath in the natural order of the underlying filesystem - and this
is certainly working fine for me. I control the order of processing of
faces-config.xml files in jars in my WEB-INF/lib dir just by using the
filename:
11-myfaces-api.jar
12-myfaces-impl.jar
13-tomahawk.jar
14-mystuff.jar
It might be nice to be able to specify the ordering in some config file,
but for now using jarfile names seems quite satisfactory.
Regards,
Simon
Jesse Alexander (KBSA 21) wrote:
So you prefer to keep a rather UGLY behaviour, th eone where you never
can be
sure in which sequence the jar-files are processed?
It just makes it almost impossible to use a set of custom-components
from external
companies, if you need to override a renderer for example...
I'd rather have the akward solution than chaos as it is right now...
regards
Alexander
PS: I prefer the solution because i already have hit that wall. It was
impossible to override
a tomahawk renderer, because of this erronous (because not
deterministic) behaviour...
-----Original Message-----
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 9:18 PM
To: MyFaces Development
Subject: Re: Require ordering of for loading META-INF/faces-config.xml
files from component jar
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
