I'm not sure whether it is really a bug... It was just an example to stress this point. I had a particular problem with this functionality (since one of these AddRessource implementations attempts to write directly and does not postpone it to the rendering phase!) when trying to use a component like it was suggested in the Wiki! But I updated the according Wiki page with an according hint...
I know. But there are similar problems e.g. when combining several component frameworks like ajax4j, tomahawk, jenia etc. since there is always some overlap in functionality... And then the order comes into play for the JSF standard extension points! In the end there is the common problem of component architecture: How to describe the semantics of an interface and the assumptions made about the environment needed for using it? Maybe namespaces in combination with type would improve this situation! So each framework should only handle those information uniquely identified by namespace and type within their custom implementation of a JSF standard extension point. E.g. if a variable resolver is supposed to lookup spring managed beans, it should only consider the namespaces registered with it. (Maybe there is another variable resolver doing the same job with a slightly different behaviour used by another framework!) As far as I remember, Jenia did a good job on this and was quite easy to integrate... You're right. Keeping such a matrix up to date will be challenging... CAK -- Carsten Kaiser Principal Consultant mailto:[EMAIL PROTECTED] Mobile: +49 (0)170 5270206 Valtech GmbH Werner-Heisenberg-Straße 2 63263 Neu-Isenburg Germany Phone: +49 (0)6102 88468-0 Fax: +49 (0)6102 88468-28 http://www.valtech.de Geschäftsführer: Ingo Kriescher Amtsgericht Düsseldorf HRB48672 -----Ursprüngliche Nachricht----- Von: news [mailto:[EMAIL PROTECTED] Im Auftrag von Werner Punz Gesendet: Donnerstag, 24. Mai 2007 12:56 An: [email protected] Betreff: Re: Why so many problems with MyFaces? Carsten Kaiser schrieb: > I know this one, but unfortunately it has not the right granularity for > some problems... I had some matrix in mind, wherein the used common > extension points and the required configuration scenarios are listed! > E.g. > component x requires StreamingAddRessource to be configured, component y > just works with DefaultAddRessource... etc. > Ah ok, that clears things up, anyway, if you ran into one of those issues this is clearly a bug, the StreamingAddResource is clearly a MyFaces artefact which should give speed optimizations, if some of the components do not work with either addresource filter (DefaultAddRessource is also MyFaces for serving resources) please comment the bug! This are by no means standard jsf extension points inf fact jsf does not specify how resources have to be loaded from the system, those are things which are very myfaces specific to stream resources out of the project jars into the browser. > So, from outside JSF can be considered as some kind of lego brick > system, > where you can plug together components as needed, since all have the > same > interface structure. But unfortunately this is just half of the truth > since there are dependencies under the surface established through > assumptions about common functionality like e.g. the order variables are > resolved etc. > Yes unfortunatly this is true... Maybe compatibility matrix would help along the lines of which component frameworks work together and which not, this clearly would make things easier, if some stuff does not work within a single project (myfaces + streamingaddresource + tomahawk component then this is clearly a bug not an incomptability) I am not sure if an extremely fine granularity would help particularily, because it would become another bugtracker...
