[jsr-314-open-mirror] [jsr-314-open] Enabling easier hotplugging

[Werner Punz]

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 at 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 at 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://people.apache.org/%7Ewerpu/Proposal%20Configuration.pdf>
> >
> > 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=765since
> > 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 at gmail.com>
> wrote:
> >
> >> On Tue, Mar 16, 2010 at 12:07 PM, Martin Marinschek <
> >> mmarinschek at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100323/4d184c77/attachment-0003.html