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