[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-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
[jsr-314-open] ViewScoped severe bug or expected behavior?
by Werner Punz
Hi I ran into following issue while doing some testing on MyFaces and after
testing it on Mojarra I noticed that Mojarra behaves the same. So I am not
sure if this is a bug or expected behavior. Hence I am posting it here.
Following usecase.
a Page with a managed bean as page controller which is ViewScoped.
Now the page keeps some data which is serialized per definition on the
scope.
An action is triggered from the page which then issues an implicit
navigation case onto itself.
Now what happens on both implementations is, that the ViewScoped bean is
dropped and the data is lost.
This is easily reproducable with the case in the attachments.
As you can see the value is initially set to another value by the
postConstruct and then once the action is triggered it is reset to the
initial value, although it should
have been restored to the last value which was present before issuing the
action onto itself.
I could reproduce this behavior on MyFaces 2.0.3 and on Mojarra. Any ideas
if this is a bug or expected behavior? Because from a logical point of view
a nav case should not retire the view scope if it hits the same page again
no matter if a redirect is in between if it is implicit or explicit or if it
is just
a null restore case.
Werner
13 years, 11 months
Re: [jsr-314-open] JSF 2.1 final posted on jcp.org
by Ed Burns
>>>>> On Wed, 24 Nov 2010 08:07:51 -0700, David Geary <clarity.training(a)gmail.com> said:
DG> Thanks, Ed. Perhaps I missed it, but are there plans to create a new
DG> EG for 2.2?
You didn't miss it. With a new JSR there is always a new EG, so yes.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
14 years
