October 2010 - jsr-314-open-mirror

[jsr-314-open-mirror] [jsr-314-open] JBoss provides JSR-314-OPEN archives

by Ed Burns

Dan Allen reported on his twitter feed that these JSR-314-OPEN archives exist. Thanks to Dan and RedHat for making this data available: <http://lists.jboss.org/pipermail/jsr-314-open-mirror/>. Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 14 work days until German Oracle User's Group Conference

14 years, 4 months

1
0
0 / 0

[jsr-314-open-mirror] [jsr-314-open] [2.1 Spec Review] Pre/PostValidateEvent publishing conditions

by Andy Schwartz

The following text was added to the Pre/PostValdiateEvent API doc: > When an instance of this event is passed to > SystemEventListener.processEvent(javax.faces.event.SystemEvent) or > ComponentSystemEventListener.processEvent(javax.faces.event.ComponentSystemEvent), > the listener implementation may assume that the source of this event > instance is the UIComponent instance that is that has just been validated. > > Note that iterating components such as UIData, and form components > such as UIForm must publish this event after processing their children > nodes in UIComponent.processValidators(javax.faces.context.FacesContext). Does this mean that only input, UIData and UIForm components will deliver these events? If so, some concerns about this: 1. Mojarra 2.0 delivered these events for all components. 2. The Mojarra trunk still does this (see UIComponentBase.processValidators()). 3. This prevents mutti-component validation where a listener is registered on an arbitrary ancestor component. For an example of #3, see the "Multi-Component Validation" section of Core JavaServer Faces, 3rd ed: http://my.safaribooksonline.com/9780137013968/331#X2ludGVybmFsX0ZsYXNoUmV... Note that the PostValidateEvent listener is registered on an h:panelGrid. With the new addition to the specification, it seems that this is no longer supported. Andy

14 years, 4 months

3
2
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] [2.1 Spec Review] composite:clientBehavior still missing

by David Geary

I don’t see this in the 2.1 spec. I’d be happy to write something. david 2010/7/14 Roger Kitain <roger.kitain(a)oracle.com> > That item is listed as one of the deferred items on the change log. > We have it implemented, but it is not specified correctly - so we'll do it > for 2.1. > > > On 7/14/10 10:12 AM, David Geary wrote: > >> composite:clientBehavior still does not appear to be documented anywhere >> in the spec or VDL docs. >> > > > -- > roger.kitain(a)oracle.com > https://twitter.com/rogerk09 > http://www.java.net/blogs/rogerk > > >

14 years, 4 months

1
0
0 / 0

[jsr-314-open-mirror] [jsr-314-open] FYI: non-normative text added to FacesContext.setViewRoot()

by Ed Burns

I propose adding the following non-normative text to FacesContext.setViewRoot(), regarding the timing of when it is valid to call this method. /In the present version of the specification, implementations are not required to enforce this restriction, though a future version of the specification may require enforcement./ Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 15 work days until German Oracle User's Group Conference

14 years, 4 months

2
1
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] [Mojarra-1812-FacesServlet.service] PROPOSAL

by Ed Burns

Thanks for your prompt response. Comments inline. >>>>> On Wed, 8 Sep 2010 18:05:15 +0200, Matthias Wessendorf <matzew(a)apache.org> said: MW> I think I don't get why the release() has been (re)moved at all and MW> why this now need to exposed as lifecyle API. MW> Doesn't the ticket talk about exception handling/reporting? I think I MW> don't understand how that is related to release the facesCtx. The reason it impacts exception handling is the case where an exception is thrown as a result of action taken by the JSF impl to synchronize session scoped beans at the end of a JSF request so that clustering requirements are not violated. This is the catch block that needs to be invoked when such an exception is thrown: EB> + } catch (Throwable t) { EB> + ExceptionQueuedEventContext eventContext = EB> + new ExceptionQueuedEventContext(context, t); EB> + context.getApplication().publishEvent(context, EB> + ExceptionQueuedEvent.class, eventContext); EB> + context.getExceptionHandler().handle(); EB> + } finally { Obviously, this needs to happen *before* the FacesContext is released. This proposal, provides a simple and clean way for the implemention to know that the jsf portion of the request processing lifecycle has finished. Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 7 work days until JavaOne 2010

14 years, 4 months

3
2
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] UIComponent.invokeOnComponent does not call pushComponentToEL() and popComponentFromEL()

by Ed Burns

>>>>> On Tue, 19 Oct 2010 19:47:01 -0700, Ed Burns <edward.burns(a)oracle.com> said: >>>>> On Tue, 19 Oct 2010 09:30:01 -0700, Ed Burns <edward.burns(a)oracle.com> said: >>>>> On Mon, 18 Oct 2010 17:02:32 -0700, Blake Sullivan <blake.sullivan(a)oracle.com> said: B> I definitely consider it a bug for the reason you mention. All of the B> Trinidad components do push and pop the EL context during B> invokeOnComponent. I believe that tree visiting does establish the B> context correctly, which also shows where the intent lies. EB> I agree this is probably a bug. I have made the change and am EB> re-running our automated test suite. If there are no errors, I'll take EB> the liberty of modifying the spec and impl, attaching a patch, seeking EB> review, and commiting it. I think this can reasonably be grandfathered EB> in under existing JSF 2.1 changelog issue 868. [1] EB> I have attached the diffs to the issue. I would appreciate a quick code EB> review of attachment 310 on [1], but considering that it is a small EB> change, I'll commit it ahead of the review. EB> Note that I modified the automated tests as well. EB> [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=868 Phooey, found and fixed another test failure, related to copyright nonsense. Attachment 311, but ignore the FacesContext changes. They are not in this commit. Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 16 work days until German Oracle User's Group Conference

14 years, 4 months

1
0
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] UIComponent.invokeOnComponent does not call pushComponentToEL() and popComponentFromEL()

by Ed Burns

>>>>> On Tue, 19 Oct 2010 09:30:01 -0700, Ed Burns <edward.burns(a)oracle.com> said: >>>>> On Mon, 18 Oct 2010 17:02:32 -0700, Blake Sullivan <blake.sullivan(a)oracle.com> said: B> I definitely consider it a bug for the reason you mention. All of the B> Trinidad components do push and pop the EL context during B> invokeOnComponent. I believe that tree visiting does establish the B> context correctly, which also shows where the intent lies. EB> I agree this is probably a bug. I have made the change and am EB> re-running our automated test suite. If there are no errors, I'll take EB> the liberty of modifying the spec and impl, attaching a patch, seeking EB> review, and commiting it. I think this can reasonably be grandfathered EB> in under existing JSF 2.1 changelog issue 868. [1] I have attached the diffs to the issue. I would appreciate a quick code review of attachment 310 on [1], but considering that it is a small change, I'll commit it ahead of the review. Note that I modified the automated tests as well. Ed [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=868 -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 16 work days until German Oracle User's Group Conference

14 years, 4 months

1
0
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] [2.1 Spec Review] ViewHandler.FACELETS_SUPPRESS_XML_DECLARATION

by Ed Burns

>>>>> On Tue, 19 Oct 2010 14:21:08 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said: AS> This constant is specified in the 20101013 version of the spec AS> (JavaDoc). I believe that we can remove this now as this functionality AS> is covered by the new Facelets processing mode. I intentionally left it in because I thought it useful enough to keep as a plain-ole context-param. Do you really think we should pull it out? Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 16 work days until German Oracle User's Group Conference

14 years, 4 months

2
1
0 / 0

[jsr-314-open-mirror] [jsr-314-open] [2.1 Spec Review] ViewHandler.FACELETS_SUPPRESS_XML_DECLARATION

by Andy Schwartz

This constant is specified in the 20101013 version of the spec (JavaDoc). I believe that we can remove this now as this functionality is covered by the new Facelets processing mode. Andy

14 years, 4 months

1
0
0 / 0

Re: [jsr-314-open-mirror] [jsr-314-open] JCP Maintenance Review for JSF 2.1 ends on 22 October

by Ed Burns

>>>>> On Thu, 14 Oct 2010 08:19:18 -0700, asmirnov <asmirnov(a)exadel.com> said: AS> Great, I've a troubles performing 'diff' in mind :-) I discovered an error in the color coding, so I put a new one up. https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153... Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/

14 years, 4 months

3
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jsr-314-open-mirror October 2010