[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
[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, 2 months
Re: [jsr-314-open-mirror] [jsr-314-open] composite components: targets attribute revisited
by Ed Burns
>>>>> On Thu, 28 Oct 2010 12:56:53 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> Hi
LU> To be more explicit, this is the example that should fail:
LU> <ez:loginPanel id="loginPanel" model="#{bean}">
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener}" />
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener2}" />
LU> <f:actionListener for="cancelEvent"
LU> binding="#{bean.cancelEventListener}" />
LU> </ez:loginPanel>
LU> <composite:interface name="loginPanel">
LU> <composite:actionSource name="loginEvent" />
LU> <composite:actionSource name="cancelEvent" />
LU> </composite:interface>
LU> <composite:implementation>
LU> <h:commandButton name="button1">
LU> <f:actionListener
LU> binding="#{cc.actionSource.loginEvent}"/>
LU> </h:commandButton>
LU> <x:mycompositecomponent name="button2">
LU> <f:actionListener
LU> binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/>
LU> </x:mycompositecomponent>
LU> </composite:implementation>
LU> In this case, the binding #{cc.actionSource.loginEvent} does not point to
LU> just
LU> one actionListener.
GP> Leo, IMO your example wouldn't need to fail: the nested
GP> actionListener with binding="#{cc.actionSource.loginEvent}" would
GP> need to execute *all* actionListeners that have been bound to
GP> "loginEvent". In this case "#{bean.loginEventListener}" and
GP> "#{bean.loginEventListener2}" would reside in a Map named
GP> cc.actionSource.loginEvent and could both be executed. Wouldn't this
GP> work?
The type of the binding attribute is specified thus.
Value binding expression that evaluates to an object that implements
javax.faces.event.ActionListener
How would you make that handle a list?
Sure, we could go and add a raft of new "bindingList" attributes to all
of the attached object handlers in f:, but is it worth the complexity?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 9 work days until German Oracle User's Group Conference
13 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] [901-DeprecateTargetConcept]
by Ed Burns
>>>>> On Fri, 29 Oct 2010 16:00:06 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> On 10/29/10 3:32 PM, Ed Burns wrote:
>> If we're talking verbs here, I think an even better one is "exposes".
>> The component implements the thing whether it's exposed or not.
AS> I can see two different notions of "implements":
AS> 1. The <h:commandButton> implements the ActionSource(2) contract.
AS> 2. The <h:commandButton> provides the implementation of the action
AS> source that is declared in the interface section of the composite component.
AS> I think that "implementsActionSource" works well for #2. I also like
AS> how this name leverages nomenclature/concepts that are already present
AS> in our composite component architecture. We have "interface" and
AS> "implementation" sections - "implementsActionSource" fits in nicely with
AS> this model.
Ok, then I can get behind "implements".
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
Re: [jsr-314-open-mirror] [jsr-314-open] [859-MultiActionComponent] RESOLVED (was: Re: Composite components only support one action) attribute (review of issue 859)
by Ed Burns
>>>>> On Fri, 29 Oct 2010 07:52:36 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi guys,
MM> targetAttributeName is problematic for me if we want to move to a
MM> world "without" the target attribute. If we really want to allow
MM> everything to work in this way, we need the implementation to pull the
MM> method-expressions in - and not the interface to push them down.
Yes, I understand. We're working towards that. But we're not going to
be removing anything from the API. We'll just document that there is a
better way to do it.
MM> In such a world, the attribute name "targetAttributeName" is
MM> meaningless, at least to my understanding.
Your comments have been noted.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] Composite component file extensions
by Andy Schwartz
Gang -
Both MyFaces and Mojarra currently assume/require the file extension
".xhtml" for composite component resources. This seems overly
restrictive. Composite component authors should be able to use other
file extensions - eg. ".view.xml", or, as we would like to do here: ".jsf".
What do folks think about introducing spec language that requires the
JSF implementations to check for composite component resources under any
extensions specified via the "javax.faces.FACELETS_VIEW_MAPPINGS"
context parameter?
Or, if we start looking into jar-specific configuration, it might be
interesting to allow such extensions to be specified on a per-resource
library basis.
Thoughts?
Andy
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [537-PrePostValidate] RESOLVED (was: Re: [2.1 Spec Review] Pre/PostValidateEvent publishing conditions)
by Ed Burns
>>>>> On Thu, 21 Oct 2010 09:55:15 -0600, David Geary <clarity.training(a)gmail.com> said:
DG> The only reason I can think of is that UIData is also (potentially,
DG> anyway) a container of inputs. But so are panels, and they,
DG> evidently, are excluded. Why?
EB> No, it does not mean that *only* those components will deliver those
EB> events. It means that in the case of components who are iterating
EB> components, the event must be published before, or after, the child
EB> component processing. This is true for any components that have
EB> children. I will revise the documentation to be as follows.
EB>
EB> PostValidateEvent
EB>
EB> Components with children must publish this event after processing their
EB> child nodes in processValidators. This is especially important for
EB> iterating components such as UIData and form components, such as UIForm.
EB>
EB> PreValidateEvent
EB>
EB> Components with children must publish this before after processing their
EB> child nodes in processValidators. This is especially important for
EB> iterating components such as UIData and form components, such as UIForm.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [153-UIDataTransient] RESOLVED Re: [2.1 Spec Review] Transient State [Was: Fix UIData state saving model]
by Ed Burns
>>>>> On Thu, 21 Oct 2010 12:27:46 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
MM> I agree with the points:
MM> - get/putTransient should be on UIComponent, or TransientStateHelper
MM> needs to be exposed
MM> - no Serializable keys are necessary
AS> Great.
MM> But - I am not sure about removing the TransientStateHelper
MM> contract... It doesn't need to extend from StateHelper,
AS> Yep.
MM> that is true -
MM> but won't the code look funny if state-saved property handling looks
MM> different from transient property handling?
AS> The first patch does the following:
AS> - Serializable -> Object for keys
AS> - TransientStateHelper no longer extends StateHelper
AS> - UIComponent.getTransientStateHelper() methods are public
AS> - The 1-arg versions of getTransientStateHelper() and getTransient() are
AS> now final (convenience methods)
AS> - While I was in the code, I optimized the save/restoreTransientState()
AS> methods to avoid unnecessary instantiation of the ComponentStateHelper
I have committed this. Thanks Andy for supplying it.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months