I changed the document, the configuration change now does not refer to<br>development mode ...<br>Martin already said why it slipped in.<br><br>Btw. my personal opinion regarding all this is that this should be solved<br>in a special spec which frameworks can attach to.<br>
After all the entire configuration change aspect is not only JSF specific but goes way depper<br>into every framework. <br><br>But I guess someone has to do the first step before an umbrella jsr spanning all<br>JEE frameworks is opened :-)<br>
<br>
After all without Managed Beans and Spring and Seam we would not have CDI today.<br>But the main issue is we have to keep the door open for such a future spec to be integrateable.<br><br><br>Werner<br><br><br><br><div class="gmail_quote">
On Tue, Mar 23, 2010 at 12:48 PM, Martin Marinschek <span dir="ltr"><<a href="mailto:mmarinschek@apache.org">mmarinschek@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi guys,<br>
<br>
I totally agree with the suggested changes of Werner - a +1 from me.<br>
<br>
In the current version of the document, Werner says this should work<br>
only in development time - but I think this should work always, Werner<br>
agreed and he will adapt the document in this regard.<br>
<br>
Why did Werner first think this should work only during development<br>
time? We first agreed that basic configuration changes are easily<br>
doable, and can work both during development and production time.<br>
However, he was specifically referring to more sophisticated behaviour<br>
like if you drop a managed bean configuration, then the managed bean<br>
instance should also be dropped. Werner and me then agreed that the<br>
framework listening to such configuration changes would implement<br>
this, and that this framework would then decide if and how it wants to<br>
act in the diverse development modes.<br>
<br>
best regards,<br>
<font color="#888888"><br>
Martin<br>
</font><div><div></div><div class="h5"><br>
On 3/19/10, Werner Punz <<a href="mailto:werner.punz@gmail.com">werner.punz@gmail.com</a>> wrote:<br>
> Ok guys I posted an initial proposal in issue<br>
><br>
> <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=774" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=774</a><br>
><br>
> you also can download the proposal directly from<br>
><br>
> <a href="http://people.apache.org/%7Ewerpu/Proposal%20Configuration.pdf" target="_blank">http://people.apache.org/~werpu/Proposal%20Configuration.pdf</a><br>
><br>
> It is just a proposal for 2 extension points first an extension point which<br>
> gives read and write access to the configuration<br>
> (although it is up to the implementation whether the right access is granted<br>
> and in which state of the application)<br>
> Secondly system events all extensions and also the implementation must use<br>
> as extension point<br>
> to get configuration write and read behavior in. This notification system<br>
> uses the existing system events to perform that<br>
> but more details in the PDF.<br>
><br>
> Btw. can someone please close<br>
> <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=765since" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=765since</a><br>
> I cannot do it, it is oviously now covered by the proposal and the<br>
> unload itself is part of a connecting extension framework or the respective<br>
> implementation.<br>
><br>
> Werner<br>
><br>
><br>
> On Tue, Mar 16, 2010 at 8:49 PM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>> wrote:<br>
><br>
>> On Tue, Mar 16, 2010 at 12:07 PM, Martin Marinschek <<br>
>> <a href="mailto:mmarinschek@apache.org">mmarinschek@apache.org</a>> wrote:<br>
>><br>
>>> Hi guys,<br>
>>><br>
>>> just so that I can add my 2cents as well: I believe it would be a<br>
>>> valuable addition to JSF if we had some standardized hooks into the<br>
>>> configuration management - that was really missing from the beginning.<br>
>>><br>
>>> I believe it was also discussed from early on, but always delayed to a<br>
>>> later version.<br>
>>><br>
>><br>
>> That later version needs to be JSF 2.1. Time to make it happen :)<br>
>><br>
>> -Dan<br>
>><br>
>> --<br>
>> Dan Allen<br>
>> Senior Software Engineer, Red Hat | Author of Seam in Action<br>
>> Registered Linux User #231597<br>
>><br>
>> <a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
>> <a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
>> <a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>
>><br>
><br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
<br>
<a href="http://www.irian.at" target="_blank">http://www.irian.at</a><br>
<br>
Your JSF powerhouse -<br>
JSF Consulting, Development and<br>
Courses in English and German<br>
<br>
Professional Support for Apache MyFaces<br>
</div></div></blockquote></div><br>