Now and this is what Ed's suggestion originally was - enforcing this alphabetic parsing on the JSF level.
regards, Martin On 12/6/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > 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 > >> > >> > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
