[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] 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/
13 years, 4 months
Re: [jsr-314-open-mirror] [jsr-314-open] ANNOUNCE: JSF 2.1 Spec, Release Candidate Five
by Ed Burns
>>>>> On Fri, 05 Nov 2010 14:53:48 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> On 11/5/10 2:32 PM, Ed Burns wrote:
>>>>>>> On Thu, 04 Nov 2010 23:33:29 -0700, Ed Burns <edward.burns(a)oracle.com> said:
>>>>>>>
>>
>> The unprefixed namespace, also known as the root namespace, must be
>> passed through without modification or check for validity. The
>> passing through of the root namespace must occur on any non-prefixed
>> element in a facelet page.
AS> Sounds good. (Sounds like we are just specifying behavior that Faclets
AS> has always implemented, right?)
Yes, that is correct.
AS> BTW, I see that we still have <h:html> and <h:title> components in the
AS> latest spec. I haven't seen an explanation for why this are
AS> necessary/useful. When I asked about this, you mentioned that <h:html>
AS> was useful as a resource target. However, it is not. From our earlier
AS> thread:
>> I see. Unfortunately this approach is flawed. The <html> element may
>> only contain <head> and <body> elements. As such, "html" is not a
>> valid target for resource relocation. We need to remove this new
>> requirement from the 2.1 specification.
>>
>> If <h:html> cannot serve as a resource target and if <html> is a valid
>> element in XML processing mode, I am still unclear on the value of
>> <h:html> and wonder whether this should be included in the 2.1
>> specification.
>>
>> On a related note, what's up with <h:title>? :-) Can we kill this
>> off? Or is there some reason why folks would need to use this instead
>> of <title>?
AS> I don't remember seeing a response to this, though with all of the
AS> emails lately, I may have missed it.
AS> I still do not understand why our users would use <h:html> and <h:title>
AS> over <html> and <title>. If we don't have a strong reason for why these
AS> components are useful, we should remove these from the specification in
AS> order to avoid spec/component bloat.
I will drop <h:html> and <h:title>.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 3 work days until German Oracle User's Group Conference
| 10 work days until GlassFish 3.1 Hard Code Freeze
13 years, 5 months
Re: [jsr-314-open-mirror] [jsr-314-open] ANNOUNCE: JSF 2.1 Spec, Release Candidate Five
by Ed Burns
>>>>> On Fri, 05 Nov 2010 16:37:55 -0700, Blake Sullivan <blake.sullivan(a)oracle.com> said:
B> Just to chime in further on the continued presence of <h:html> and
B> <h:title>, as Andy said, in addition to just pointlessly bloating the
B> specification, having <h:html> act as a resource relocation target seems
B> just plain wrong.
I agree. I'll take it out.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 3 work days until German Oracle User's Group Conference
| 10 work days until GlassFish 3.1 Hard Code Freeze
13 years, 5 months
Re: [jsr-314-open-mirror] [jsr-314-open] ANNOUNCE: JSF 2.1 Spec, Release Candidate Five
by Ed Burns
>>>>> On Thu, 04 Nov 2010 23:33:29 -0700, Ed Burns <edward.burns(a)oracle.com> said:
>>>>> On Wed, 3 Nov 2010 13:09:30 -0700, Ed Burns <edward.burns(a)oracle.com> said:
EB> Hello JSF Expert Community,
EB> This is the fifth, and most likely final, iteration of the JSF 2.1
EB> spec. Please let's get this done so we can move on to JSF 2.2 and
EB> resolve all these nice composite component issues.
EB> Well, here's the sixth iteration. It has the improvements suggested by
EB> Andy.
EB> https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153...
Imre Osswald, another excellent community member, grabbed me on IM this
morning and pointed out another little hole in the namespace solution.
This prompted me to make an edit to the PDF, which I have updated in the
above zip. If you downloaded it, download it again. It has a new pdf
but the rest is the same. Here is the commit message.
M integrationWithFacelets.fm
M preface.fm
M title.fm
- update date
- 10.3.2
add spec language that asserts that the root namespace must be passed
through unmodified.
The unprefixed namespace, also known as the root namespace, must be
passed through without modification or check for validity. The
passing through of the root namespace must occur on any non-prefixed
element in a facelet page. For example, the following markup
declaration:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<msup>
<msqrt>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</msqrt>
<mn>27</mn>
</msup>
</math>
would be rendered as
<html xmlns="http://www.w3.org/1999/xhtml">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<msup>
<msqrt>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</msqrt>
<mn>27</mn>
</msup>
</math>
I added an automated test to Mojarra to make sure this works and I do
indeed see the square root of a + b to the 27th when viewing the page in
Firefox with the necessary MathML fonts installed.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 3 work days until German Oracle User's Group Conference
| 10 work days until GlassFish 3.1 Hard Code Freeze
13 years, 5 months
