Commons configurators in different jar (Pre-vote discussion)

[Scott O'Bryan <da...@gmail.com>]

Hey everyone,

Many of you have heard me talk about donating a "Configurator" system to 
the commons project.  To recap, this API will allow the various 
renderkits to replace most (hopefully all) of their filter logic with a 
J2EE Services based mechanism that is compatible with both Portlet and 
Servlet environments.  One of the many possible uses that I listed in 
the intial proposal was to do cross-renderkit multi-part form handling 
(file uploads) which I think at some point we might want to add to the 
commons project so that multiple renderkits can be used at any given time.

If the configurator system is included in the commons util package, my 
suggestion would be to turn it off by default and make it only available 
if a renderkit or application enables it though the use of a 
faces-config.xml entry (ie. you have to register a 
FacesContextFactory).  The alternative is that the configurators can 
become their own package and the necessary faces-config.xml entry could 
be built as part of the jar.  The advantage of this is that any 
renderkit or application needing the configurator functionality would 
simply drop the jar into the classpath somewhere.  The disadvantage is 
that this would be yet another jar that would have to be added to 
dependent projects and it's likely that this piece will become core 
functionality for all renderkits ESPECIALLY if we add a common 
multi-part form handler.

There is a third option and that is to have the "utils" mechanism always 
set up the configurator subsystem.  The performance impact of the 
configurator system should be negligible, especially with no services, 
but it might register an unneeded FacesContextFactory whenever the 
commons utility package is used which might not be appealing to some.  
It would solve both the configuration and extra-jar issues however and 
if people think these configurators are likely to become a core piece of 
the different render kits then it might not be terrible to have the 
configurators enabled and ready to go.

Also, if we can keep the multi-part form handling or JSF 1.1 arguments 
out of this discussion, it might help expedite things.  If need be the 
configurators can be ported back to 1.1 and multipart form handling can 
be enabled/disabled regardless of whether configurators are turned on by 
default.  So both of those discussions can be talked about at a later time.

Let me know your thoughts and after I get some feedback I'll start up a 
vote.

Scott