[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, 8 months
[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, 9 months
[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, 9 months
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, 9 months
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, 9 months
Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
by Ed Burns
>>>>> On Fri, 25 Feb 2011 12:43:56 -0500, Kito Mann <kito.mann(a)virtua.com> said:
KM> Hello Ed,
KM> Have you handed this over to the JCP yet?
I just did yesterday.
KM> There are a couple of other things I'd like to see:
KM> * Integration of Facelets ResourceResolver with resource management system,
KM> so that normal Facelet views can be packaged in libraries.
KM> * Simplification of locale specification for resource libraries (already in
KM> the issue tracker)
KM> * Support for mapping a request directly to an action without specifying a
KM> page first (more Struts-style); this may be possible with page actions.
Can you please edit the JSF-2_2-draft.html file at
https://svn.java.net/svn/javaserverfaces-spec-public~svn/trunk/www/proposals
and add those points? Let me know if you need commit access. We may
have a chance to change it before it goes on the ballot.
In any case, I don't want to lose them.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 10 months
Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
by Ed Burns
>>>>> On Wed, 16 Feb 2011 11:35:14 -0500, Kito Mann <kito.mann(a)virtua.com> said:
KM> Hello Ed,
KM> Are any other Java EE specs following the same philosophy (Bean Validation
KM> comes to mind).
At this point, JSF is once again the trailblazer. I suspect that once
we do it, others will follow suit.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
13 years, 10 months
[jsr-314-open-mirror] [jsr-314-open] Should the ViewDeclarationLanguage be responsible to indicate if a viewId can be created?
by Leonardo Uribe
Hi
The current algorithm to check if a view with a specific viewId does not
allow to add or extends a new ViewDeclarationLanguage using a new
prefix/extension.
This issue is related to
https://issues.apache.org/jira/browse/MYFACES-2628 Facelets ResourceSolver
can't work
and
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567
The problem resides on a "hidden" requeriment for Restore View Phase
algorithm, that is ignored silently. On mojarra, this is the code on
MultiViewHandler.getViewDeclarationLanguage:
public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext
context,
String viewId)
{
String actualViewId = derivePhysicalViewId(context, viewId, false);
return vdlFactory.getViewDeclarationLanguage(actualViewId);
}
Now on myfaces is this:
@Override
public ViewDeclarationLanguage getViewDeclarationLanguage(
FacesContext context, String viewId)
{
// return a suitable ViewDeclarationLanguage implementation for the
given viewId
return _vdlFactory.getViewDeclarationLanguage(viewId);
}
The difference is subtle, but very, very important. This method is called
from many locations, but only once (from RestoreViewPhase) it is passed the
"raw" viewId. To "derive" the physical viewId it is required to know if
prefix or suffix mapping is used and if suffix mapping is used, try to check
if a view "resource" exists or not with different derived ids with the
extensions configured ".xhtml .jsp".
javax.faces.view.facelets.ResourceResolver documentation says this:
"... Provide a hook to decorate or override the way that Facelets loads
template files. A default implementation must be provided that satisfies the
requirements for loading templates as in Pre-JSF 2.0 Facelets ..."
So, in theory it is possible to override ResourceResolver interface and
serve resources from a different location. But the algorithm in
MultiViewHandler.derivePhysicalViewId does not take into account this
interface, so it try to check if the view "resource" exists on the same
location and fails.
The solution proposed is add a method on ViewHandler,
ViewDeclarationLanguageFactory and ViewDeclarationLanguage called:
public boolean existsViewId(String viewId)
So the VDL can indicate if a viewId exists or not. In this way, on Facelets
VDL we can check if a viewId exists using the ResourceResolver instance. It
is curious that ViewDeclarationFactory implementation has some methods that
indicate if a vdl can handle a viewId or not (it is not the same, but
similar). I'm not done too much work on this issue, but it could be good to
take a look at this one. It could be good to open an issue on the spec for
this one too (if no objections I'll open an issue for this one, but better
to ask first).
Suggestions are welcome.
regards,
Leonardo Uribe
13 years, 10 months
