Am 02.03.2012 17:46, schrieb Edward Burns:
>>>>>> On Fri, 02 Mar 2012 11:33:56 +0100, Bernd Müller <bernd.mueller_at_ostfalia.de> said:
>
> BM> Am 01.03.2012 20:38, schrieb Edward Burns:
>>>>>>>> On Tue, 28 Feb 2012 16:03:18 -0800, Alexander Smirnov <alsmirnnov_at_gmail.com> said:
>>>
> AS> One more context param attribute, with addition to dozens of others...
> AS> You recall me my old idea to put all configuration options into single
> AS> class, where each option has its own getter, with appropriate validation
> AS> and defaults.
> AS> It should read all options from context parameters in default
> AS> implementation, or can be replaced in faces config by custom class.
> AS> RichFaces has such class, and I saw similar in Mijarra implementation. Why
> AS> do not move it into public ?
>
> BM> which are the relevant RichFaces and Mojarra classes?
> BM> for me, to look into
>
> In Mojarra, it is
> jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java.
>
> EB> Is this idea a way to provided a java-based analog for context-param
> EB> entries?
>
> BM> yes, it should be
>
> EB> How would the runtime identify the class?
>
> BM> by Annotation, of course.
>
> BM> And, probably, JSF runtime is sufficient and the Annotation should
> BM> not be used more than once in an archive.
> BM> IDE support is mandatory to work with efficiently
>
> But this needs to map to the web.xml fragment feature, right? In that
> feature a "logical" web.xml is assembled from all the fragments found.
> This implies that it is valid to have more than one class with our
> proposed annotation. Right?
yes, you are right. Sorry, I overlooked that.
With that in mind, many "global" configurations with Java classes
are dangerous because of the distribution of central information
into different places. One place (web.xml) isn't that bad.
No other opinions/ideas out there?
>
> EB> How would the various specifications that want to define
> EB> context-param-like properties for this system declare the mapping
> EB> between context-param names and getter names?
>
> BM> The other EGs don't have to be convinced. In my judgment it can
> BM> be done in JSF alone.
> BM> Over the time, maybe, the other EGs will join.
>
> It's ok to define it here, but it must be defined in a way that has
> little or no JSF specific syntax or names.
>
> EB> We need to support the "fragment" concept introduced in Servlet 3.0,
> EB> does this idea support that concept?
>
> This question stands unanswered.
>
> EB> What value does this provide over context-params in the web.xml?
> BM> less XML
>
> BM> to fulfill the promise " ... without XML..."
>
> I believe at has to be more than that. Just trading in a human readable
> xml file for something output by the Java compiler from a human readable
> Java file isn't enough.
>
> Ed
>
Bernd