[jsr-314-open] Metadata complete jar files
by Andy Schwartz
Gang -
Section 11.5.1 of the spec defines the following annotation scanning
behavior:
> Requirements for scanning of classes for annotations
> * If the <faces-config> element in the WEB-INF/faces-config.xml file
> contains metadata-complete attribute whose value is “true”, the
> implementation must not perform annotation scanning on any classes
> except for those classes provided by the implementation itself.
> Otherwise, continue as follows.
> * If the runtime discovers a conflict between an entry in the
> Application Configuration Resources and an annotation, the entry in
> the Application Configuration Resources takes precedence.
> * All classes in WEB-INF/classes must be scanned.
> * For every jar in the application's WEB-INF/lib directory, if the jar
> contains a “META-INF/faces-config.xml” file or a file that matches the
> regular expression “.*\.faces-config.xml” (even an empty one), all
> classes in that jar must be scanned.
Since application developers have the ability to disable annotation
scanning at a global level, this means that any component set that wants
to support this mode would need to provide a metadata complete
faces-config.xml file. I don't think this is a hardship for most
component vendors, since presumably component vendors are going to want
to provide design-time metadata (eg. JSR-276 metadata), which, for the
moment, requires a faces-config.xml file anyway.
A question that came up here is whether we can tweak section 11.5.1 to
accommodate metadata complete jar files. That is, can we specify that
any jar that contains a faces-config.xml with a metadata-complete="true"
attribute would not be scanned? This would allow component vendors to
indicate that their jar files are metadata complete, and thus avoid the
cost of annotation scanning for the contents of the jar.
Note that while the annotation scan is typically a one time hit (during
application startup), design-time tools may end up starting/stopping JSF
repeatedly during the development process. Thus, avoiding unnecessary
scanning should provide for a more efficient development experience.
Any thoughts on whether we could/should make this change? Does anyone
know of reasons why we avoided specifying this originally?
Also - if we agree to make this change, is this small enough that we
could get this into the the next MR?
Andy
13 years
Re: [jsr-314-open] JSFDays updates for JSF.org
by Jay Balunas
Fairly certain this list is not active anymore. I've been sending direct messages to Ed if needed.
-Jay
On Feb 27, 2010, at 1:34 AM, Dan Allen wrote:
> To answer the question/request about reviewing changes, it does not appear that Google Sites supports this feature. The closest request I found for this feature in the forums is unanswered.
>
> http://www.google.com/support/forum/p/sites/thread?tid=3df99957f4d062d6&h...
>
> That's just one reason why Google Sites is a temporary measure until we can setup a CMS of our own. That is obviously a longer discussion.
>
> I had not planned on publishing current content, news if you will, about JSFDays. Though I was a bit vague in what I meant, so let me clarify and at the same time collect approval.
>
> It can be very difficult for the Java EE community to connect with and trust an EG if they cannot see that they are real people and familiar faces. We've had tremendous success in our recent outreach to Java EE developers at conferences: JavaOne, JSFSummit and JSFDays. From these conferences, we have three distinct group pictures which collectively cover most of the current EG members. My idea is to put these pictures on a page titled "Faces of the JSF EG", similar in spirit to the slide that has been used in the JSF presentations that has been going around.
>
> I've attached the candidate photos. The pictures from JavaOne and JSFSummit are already posted on the web.
>
> -Dan
>
> On Sat, Feb 27, 2010 at 6:14 AM, Kito Mann <kito.mann(a)virtua.com> wrote:
> Does Google Sites have any functionality that would let you actually review changes, or should we just do a simple vote for anything other than simple edits?
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral
> +1 203-404-4848 x3
>
> Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
>
>
>
> On Sat, Feb 27, 2010 at 1:32 AM, Ed Burns <Ed.Burns(a)sun.com> wrote:
> Hi Dan,
>
> I kindly request that the EG has the opportunity to review changes to javaserverfaces.org before they are made, especially one so big as adding pictures to the site. Remember, adding current content to the site was explicitly *not* a part of the initial charter. I would think that kind of content would be better on jsfcentral.com.
>
> Ed
>
>
>
> --
> 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
> <jsf-crew.jpg><jsf2-group.jpg><jsf2-eg-meeting2.JPG>
13 years, 1 month
[jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
by Ed Burns
Hello Experts,
We can continue the work we've been doing all along, but now we have a
delivery vehicle defined: the JSF 2.2 JSR.
The current draft of the JSR that Oracle plans to submit is at [1] and
you can comment on it by following up to this email. I'll do my best to
roll the edits into the draft as we go.
I'd like to hand this to JCP by the end of next week so please get your
comments in by then. Please know that the JSR document describes the
goals of the JSR at a high level, and that the final product will not
look exactly like what is outlined in a JSR.
Also, I would like to know if your company would like to be listed as a
supporter of the JSR when we submit it to the JCP. For those of you who
are individual members of this expert group, please let me know if you
would like to be listed as an individual supporting the JSR.
The long term plan for JSF evolution now is to do smaller JSRs, one
after the other. This one is scheduled to be done by end of CY 2011.
This JSR includes a number of items to further flesh out the work we did
in JSF 2.0 and 2.1, as well as many items to address requests from the
community for additional functionality.
We'll be forming a new expert group but we will be creating new mailing
lists similar in spirit and function to what we're doing with
jsr-314-open. We will be doing these lists entirely on the java.net
infrastructure. I firmly believe the transparency for which Dan Allen
has advocated will be achieved.
Ed
P.S. I blogged about it as well [2]
[1] http://javaserverfaces-spec-public.java.net/nonav/proposals/JSF-2_2-draft...
[2] http://weblogs.java.net/blog/edburns/archive/2011/02/11/pre-jcp-filed-dra...
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 1 month
[jsr-314-open] PostAddToViewEvent publishing conditions still inconsistent
by Leonardo Uribe
Hi
Some days ago, I tried to check if publishing conditions for
PostAddToViewEvent were fixed, but unfortunately it was not. These issues:
- PostAddToViewEvent delivery specification needs clarification
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-805 (for 2.0 rev A)
- Fix PostAddToViewEvent and PreRemoveFromViewEvent publishing conditions
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-782 (for
2.1_gf31_m5)
were marked as fixed.
This is what javadoc for JSF 2.1 says about it (I put the javadoc to make it
more easier to understand):
- (see UIComponent.getChildren method, the part in orange)
"... After the child component has been added to the view,
Application.publishEvent(javax.faces.context.FacesContext, java.lang.Class,
java.lang.Object) must be called, passing PostAddToViewEvent.class as the
first argument and the newly added component as the second argument if any
the following cases are true.
* FacesContext.getCurrentPhaseId() returns PhaseId.RESTORE_VIEW and
partial state saving is enabled.
* FacesContext.isPostback() returns false and
FacesContext.getCurrentPhaseId() returns something other than
PhaseId.RESTORE_VIEW..."
- Another reference to the previous point (see PostAddToViewEvent class
description)
"... The implementation must guarantee that
Application.publishEvent(javax.faces.context.FacesContext, java.lang.Class,
java.lang.Object) is called, immediately after any UIComponent instance is
added to the view hierarchy except in the case where
ResponseStateManager.isPostback(javax.faces.context.FacesContext) returns
true at the same time as FacesContext.getCurrentPhaseId() returns
PhaseId.RESTORE_VIEW. When both of those conditions are met,
Application.publishEvent(javax.faces.context.FacesContext, java.lang.Class,
java.lang.Object) must not be called. ..."
- (see UIComponent.setParent method)
"... Set the parent UIComponent of this UIComponent. If parent.isInView()
returns true, calling this method will first cause a PreRemoveFromViewEvent
to be published, for this node, and then the children of this node. Then,
once the re-parenting has occurred, a PostAddToViewEvent will be published
as well, first for this node, and then for the node's children, but only if
any of the following conditions are true.
* FacesContext.getCurrentPhaseId() returns PhaseId.RESTORE_VIEW and
partial state saving is enabled.
* FacesContext.isPostback() returns false and
FacesContext.getCurrentPhaseId() returns something other than
PhaseId.RESTORE_VIEW ..."
The first thing to notice is the description here is not what is happening
right now in Mojarra (2.0 and 2.1). The description found in
UIComponent.setParent is more close to the reality (the conditions related
to parent.isInView() ) but the part that says "... but only if any of the
following conditions are true ..." is not being preserved.
The intention of those conditions are clear. See this coment from Andy
Schwartz (JAVASERVERFACES_SPEC_PUBLIC-805):
"... 2. We don't actually want to deliver PostAddToViewEvents during render
response when Facelets temporarily removes/re-adds existing components from
the tree. ..."
Unfortunately, in practice the previous two conditions does not warrant
that. Its more, there are valid scenarios in facelets when it is required to
throw PostAddToViewEvent (for example, an ui:include src="#{someEL}" should
propagate that event so the view could be restored).
- (see PostAddToViewEvent class description)
"... 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 a UIComponent instance and that either that instance or an
ancestor of that instance was just added to the view. Therefore, the
implementation may assume it is safe to call UIComponent.getParent(),
UIComponent.getClientId(), and other methods that depend upon the component
instance being added into the view. ..."
In practice, that's not true in Mojarra, but it is on MyFaces. The reason is
Mojarra still uses a Listener attached to PostAddToViewEvent, making
UIComponent.getClientId() "unstable". If the developer has a listener that
is executed before the one doing relocation, UIComponent.getClientId() call
will not work correctly.
The central point of this mail is how should PostAddToViewEvent should
really behave?
In theory, and according to the latest JSF 2.1 spec, the original intention
must be preserved. That means:
- Deliver PostAddToViewEvents during restore view when partial state saving
is enabled.
- Don't deliver PostAddToViewEvents during render response when Facelets
temporarily removes/re-adds existing components from the tree, but propagate
it when the component is removed or added permanently.
The current behavior of Mojarra, from the point of view of the spec should
be consider a bug. How to do fix it? I propose do the following for Mojarra:
1. Check when a component is temporally removed/added on
ComponentTagHandlerDelegate implementation. If that so, disable event
processing using FacesContext.setProcessingEvents() method temporally while
removal and addition is done.
2. Propagate another internal event (for example PostAddToViewOnRefreshBuild
or something like that) to notify the listeners used for relocation
(cc:insertChildren, cc:insertFacet, h:outputScript, h:outputStylesheet) to
do their job like before.
Anyway, it could be good to know how this should really work, and fix the
relevant points on the spec.
Suggestions are welcome.
regards,
Leonardo Uribe
13 years, 1 month
[jsr-314-open] PostRestoreStateEvent is not published using Application.publishEvent
by Leonardo Uribe
Hi
Just one question: why PostRestoreStateEvent is not published using
Application.publishEvent?.
This event is used to update component bindings on beans. The only mention
on the spec is on JSF 2.0 spec (not rev A) UIViewRoot.processRestoreState,
but that code was changed to be called on restore view phase.
The final effect is you can't suscribe listeners to this event, which is odd
because there is nothing on the spec or javadoc that says this event can't
be intercepted by a listener. It is just in practice when you find both
Mojarra and MyFaces do the same (because this behavior comes from the
description on UIViewRoot.processRestoreState).
regards,
Leonardo Uribe
13 years, 1 month
Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
by Ed Burns
>>>>> On Mon, 14 Feb 2011 11:27:30 +0000, Pete Muir <pmuir(a)redhat.com> said:
PM> Ed, could you discuss how this, and plans for future revisions of
PM> JSF, fit into the Java EE 7 roadmap? For example, are you intending
PM> to do another spec revision before Java EE 7 is due? That would be
PM> most helpful when evaluating the proposal.
Certainly. We are indeed intending to do another revision before EE7 is
due. The intent of scoping this one for calendar year 2011 is to
demonstrate a philosophy of smaller, but more frequent, releases of the
JSF spec.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 1 month
Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
by Ed Burns
>>>>> On Wed, 16 Feb 2011 11:58:56 -0500, Stephen Kenna <kenna(a)us.ibm.com> said:
SK> Just looking for a quick clarification on the following statement:
SK> Make the composite component feature usable so a "component server" can be
SK> included in a portlet runtime such that portlets can use the components in
SK> context-dependent ways. This feature is known as "remote components" in
SK> the portlet community.
SK> Is 'remote components' referring to WSRP?
No, this is a new idea that was kicking around from the time we
developed the composite component feature and Mike Freedman from the
Portlet spec suggested something very similar. Considering that a
composite component declares its interface and impl in markup, it's
possible to allow your deployed composite component library to be served
up in response to simple get requests.
SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
SK> you have referred to the existing JSR 329 which was written for JSF 1.2.
Personally, I think we do need to open up such a JSR, and having IBM's
support for such a JSR would be very helpful. However, what *I'm*
trying to establish is support for a new JSR for JSF. A portlet JSR is
another matter entirely.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 1 month