For example, it contains code in many identical packages to myfaces-tomahawk, that needs to be fixed before this API could be considered public.
It also contains MyfacesConfig (MyFacesConfig would be a better name?) that provides access to some set of configuration parameters. Why is this in commons? Where is the code that reacts to these configuration parameter values? Tomahawk?
The ResponseWriterAdapter is a good example of something that should be included in this kind of commons API. In fact, there should be adapters for all the classes supporting the decorator pattern as well. These classes are part of the specification in JSF 1.2, emphasizing their need.
The SimpleActionMethodBinding is another good example, although I'm not crazy about the name, perhaps FixedOutcomeMethodBinding would be more descriptive.
The renderkit package really does need to be removed, as it is not a public API in any way - this is simply internal implementation details that have been promoted into a shared location to support reuse across Tomahawk and the Runtime. The main reason for doing this, is to support some protected hooks that can leverage things like UserRoleUtils.isEnabledOnUserRole(...) and UserRoleUtils.isVisibleOnUserRole(...), when EL expressions such as rendered="#{myFaces.userRoles.role}" could have been used by the page author instead of visibleOnUserRole="role" to achieve the desired effect without the need for special APIs that then force the implementation internals into a shared public API.
Similarly, the taglib package needs to be removed from myfaces-commons as well. In ADF Faces, we generate all our tag code during the build, so there is no need to promote internal implementation details into a shared public API.
This is a real issue that should be addressed *before* releasing the myfaces-commons JAR. Could we have a serious discussion about cleaning this up?
Btw, no one has yet commented on whether JavaEE 5 will solve this for us for the case where the MyFaces JSF 1.2 Runtime is on the main JavaEE Container ClassLoader, while MyFaces JSF 1.2 Tomahawk component library is on the web app ClassLoader. Any thoughts?
Kind Regards,
John Fallows.
On 1/17/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
2006/1/17, Sean Schofield <[EMAIL PROTECTED]>:
> > Hmm..good point. If myfaces-commons is deployed at the container level,
> > but a new version of tomahawk wants a later myfaces-commons that's a
> > problem. It's very bad style to require a container's libs to be
> > upgraded in order to deploy a webapp, even if the new myfaces-commons
> > jarfile is supposed to be binary-compatible with the old one.
>
> Yes but its the best solution we've come up with so far. John had
> some ideas in a thread several weeks ago. I'm going to go back an
> re-read them to see if I can't understand his proposal better.
>
> We need to get an update release out within the next few weeks and
> we're not likely to reach a better solution by then.
>
> My 2 cents,
>
Here I agree with Sean.
We should also keep in mind that the commons classes we are speaking
of really (should) have "commons" nature. That means: The same problem
apply as it does for EVERY commons library. Many containers already
use commons libraries for their own implementation. So, as a real life
example: Tomcat is shipped with a version of commons-el.jar. Now, what
if MyFaces needs a newer version for some reason? Should we as well
repackage commons-el classes for our MyFaces implementation to solve
problems before they even arise? What about all the other commons
libs: commons-collections, commons-digester, commons-fileupload,
commons-logging, commons-validator, ...
And in the end we repackage (i.e. refactor) every third-party lib that
MyFaces Impl (or Tomahawk) is using?
You might say: But all this commons stuff is stable and almost never
changes! Yes, they have stable APIs, but No, they are bugfixed and
enhanced all the time. This is the path that we should strike. Come to
a stable commons jsf API that remains compatible over the time. And if
we fix bugs or enhance this lib: What's the problem with replacing the
container shipped version with a new version?
No need to overreact in this issue, IMO.
Manfred
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
