[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] CDI constructor integration
by Stephen Kenna
We have internally been discussing @Inject into @ManagedBeans (should be
the same for JSF Managed beans defined in the faces-config.xml).
Originally we were trying to figure out if JSF managed beans should
support constructor injection if they were inside a BDA (in other words,
if JSF should defer to CDI for creation).
We did some testing on Glassfish, and not only did constructor injection
not occur, but field injection did not occur either. (Field injection is
working on JBoss)
My reading of JSR-299 & the EE6 spec differs from this.
>From JSR299 Section 1.2.1:
In the Java EE 6 environment, all component classes supporting injection,
as defined by the Java EE 6 platform specifica-
tion, may inject beans via the dependency injection service.
Or JSR299 Section 3.8:
An injected field is a non-static, non-final field of a bean class, or of
any Java EE component class supporting injection.
>From the EE6 spec, Section EE.5.20 states:
Per the CDI specification, dependency injection is supported on
managed
beans. There are currently three ways for a class to become a managed
bean:
1. Being an EJB session bean component.
2. Being annotated with the @ManagedBean annotation.
3. Satisfying the conditions in Section 3.1 of the CDI specification.
Classes that satisfy at least one of these conditions will be eligible
for full
dependency injection support, as described in CDI.
and
Clearly, in the absence of any additional annotations, most component
classes
listed in Table EE.5-1 will not be managed beans. So as to make injection
support
more uniform across all component types, Java EE containers are required
to
support field or method injection (but not constructor injection) using
@javax.inject.Inject on all component classes listed in Table EE.5-1 when
the
containing archive is a bean archive.
Our interpretation of the above is that we definitely need to support
field injection of @Inject into @ManagedBean beans, and we also need to
support constructor injection
What are other's interpretation?
Regards,
Stephen
14 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] ADMIN no meeting today (was: Re: Fwd: Fix UIData state saving model)
by Ed Burns
>>>>> On Mon, 26 Jul 2010 08:14:42 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> sorry, it took me a while to review the patch, but this is Leonardo´s
MM> suggestion for partial state saving in tables. He also included a test
MM> webapp, and a test for Mojarra.
MM> What do you say?
Well, it's taken me longer than that to get to reviewing it.
Let's see what people think of the proposal and have a meeting after
interested parties have had a chance to understand and comment.
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 11 work days until JSF 2.1 Milestone 2
14 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] [696-SuppressXmlDeclaration] PROPOSAL
by Ed Burns
SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/ViewHandler.java
-
/**
* <p class="changed_added_2_1">If this param is set to true, the
* XML declaration that appears at the start of a Facelet page (if
* present) is suppressed and not passed through to the user agent.</p>
*
* @since 2.1
*/
public static final String = FACELETS_SUPPRESS_XML_DECLARATION
"javax.faces.FACELETS_SUPPRESS_XML_DECLARATION";
ACTION: Please review by Friday 20100730.
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 15 work days until JSF 2.1 Milestone 2
14 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] Facelets Template Client API does not take into account tags semantic
by Leonardo Uribe
Hi
Doing some tests about facelets template client api, I found some examples
that requires to take into account a new concept about how templates should
be resolved.
The problem was reported on:
http://issues.apache.org/jira/browse/MYFACES-2753
and on:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1708
It was closed this issue as duplicate:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684
but really it describes another different problem (in my opinion this issue
is invalid but that's another discussion).
In resume, some tags should "isolate" the context where the templates
definitions or insertions are resolved. Let's see just two examples (only
the important points):
EXAMPLE 1: Composite component
testCompositeInsertChildren4Template.xhtml
<ui:composition>
<h:panelGroup id="testGroup1">
<h:outputText value="ALFA " />
<ui:insert name="item">
<!-- This one should not be rendered -->
<h:outputText value="EPSILON "/>
</ui:insert>
<h:outputText value="OMEGA " />
</h:panelGroup>
</ui:composition>
testCompositeInsertChildren4.xhtml
<ui:composition template="testCompositeInsertChildren4Template.xhtml">
<ui:define name="item">
<testComposite:compositeInsertChildren4>
<h:outputText value="BETA " />
</testComposite:compositeInsertChildren4>
</ui:define>
</ui:composition>
compositeInsertChildren4.xhtml
<composite:interface>
</composite:interface>
<composite:implementation>
<ui:insert name="item">
<composite:insertChildren/>
</ui:insert>
<h:outputText value="GAMMA "/>
</composite:implementation>
Result:
ALFA
BETA
GAMMA
OMEGA
Comments: The tag ui:insert inside composite:implementation should not take
into account definitions made "outside" it.
EXAMPLE 2: ui:include
OuterTemplate.xhtml:
<ui:composition>
<ui:insert name="content" />
</ui:composition>
OuterClient.xhtml
<ui:decorate template="/templates/OuterTemplate.xhtml">
<ui:define name="content">
<ui:include src="InnerClient.xhtml" />
</ui:define>
</ui:decorate>
InnerClient.xhtml:
<ui:composition
template="/templates/InnerTemplate.xhtml">
<ui:define name="content">
Do you see me?
</ui:define>
</ui:composition>
InnerTemplate.xhtml:
<ui:composition>
<ui:insert name="content" />
</ui:composition>
Comments: definitions inside ui:include referenced page should ignore what
is outside it.
As you can see, there are some situations where the tag semantic requires
isolate the context where the templates are resolved. After do some test I
identified these cases:
- Composite components
- ui:include
- User tag handlers (facelets tags from xhtml files)
The solution implemented on myfaces is use a class called TemplateContext,
that encapsulates template operations, and use a stack to isolate the
different context. When a new context is required a new TemplateContextImpl
is created and pushed on the stack. When it is no longer required it is
removed from the stack. If it is necessary to resolve the markup on the
previous context, we temporally pop the context from the stack and the push
it again. It passes all tests proposed.
I'm still thinking about how template client api should be to write a
proposal about it, but I wanted to comment this stuff because it could be of
interest here.
Suggestions are welcome,
best regards,
Leonardo Uribe
14 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Martin Marinschek
Hi guys,
sorry, it took me a while to review the patch, but this is Leonardo´s
suggestion for partial state saving in tables. He also included a test
webapp, and a test for Mojarra.
What do you say?
best regards,
Martin
---------- Forwarded message ----------
From: Leonardo Uribe <leonardo.uribe(a)irian.at>
Date: Wed, Jul 21, 2010 at 6:33 AM
Subject: Fix UIData state saving model
To: Martin Marinschek <mmarinschek(a)apache.org>
Hi Martin
I have attached the required patches to be discussed on:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153
myfaces alternate patches are here:
https://issues.apache.org/jira/browse/MYFACES-2616
fixUIDataPSS-9-3-2.patch
fixUIDataPSS-9-3-no-markInitialStateFix-3.patch
I also included an example and a explanation of the conclusions taken
into account to do this proposal.
best regards,
Leonardo Uribe
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
14 years, 5 months
[jsr-314-open-mirror] [jsr-314-open] jsf.js 2.0 reva jsdoc changes
by Werner Punz
Hello everyone while checking the jsdocs of 2.0 rev a, I stumbled upon
something which does not make too much sense to me: following new
definitions:
<inner>
*isAutoExec<file:///Users/werpu2/Desktop/jsf-2_0_rev_a_fr-all-spec/jsdocs/symbols/jsf.ajax.html#-isAutoExec>
*()
<inner>
*replaceNode<file:///Users/werpu2/Desktop/jsf-2_0_rev_a_fr-all-spec/jsdocs/symbols/jsf.ajax.html#-replaceNode>
*(node, newNode)
Replace one node with another.
Both functions being exposed in the jsdocs but marked as inner functions
(which are then not exposed to the outside)
Both do not make any sense in their respective location within jsf.ajax, if
they should be jsdocwise exposed they probably would make more sense under
jsf.util, and in case of replaceNode I am not entirely convinced if it
should be exposed documentationwise at all.
Do not get me wrong both implementations definitely already have implemented
both functions otherwise the impls would not work, but why exposing them
jsdocwise?
Was this an accident or was there a reason behind it.
Werner
14 years, 5 months
Re: [jsr-314-open-mirror] [jsr-314-open] New anti-JSF blog entry: http://facemetal.wordpress.com/2010/07/19/jsf/
by Ed Burns
>>>>> On Wed, 21 Jul 2010 17:25:05 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Ed,
>> Doesn't CDI give you this?
MM> sure, CDI gives you the conversation scope - but the link between the
MM> beans behind the page and the page (or several pages, like a flow) is
MM> still not established. This is something we need to take care of.
MM> Spring Webflow has it - we only have the global scope; from any page
MM> we see any bean.
I spoke on the phone to Keith Donald about this recently. He's working
on SpringWebFlow 3, which will have a very strong integration with JSF
2.0. In there, he's working on a way to declare flows as java code.
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 16 work days until JSF 2.1 Milestone 2
14 years, 5 months
Re: [jsr-314-open-mirror] [jsr-314-open] New anti-JSF blog entry: http://facemetal.wordpress.com/2010/07/19/jsf/
by Ed Burns
>>>>> On Wed, 21 Jul 2010 09:31:32 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> The stuff which is still lacking from JSF, which he partially mentions:
MM> - back button support
MM> - double click handling
MM> - pretty URLs
MM> we should definitely address that at some point of time.
Thank you so much for your summary. The double click handling is being
covered by Roger as part of [559-SynchronizerToken].
MM> And: something he mentions I also think is not really good is the
MM> "global" managed bean scope. It would be good to have a way to let
MM> managed beans live only in a reduced, page (or conversation) visible
MM> scope.
Doesn't CDI give you this?
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 18 work days until JSF 2.1 Milestone 2
14 years, 5 months
