[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, 1 month
[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
13 years, 9 months
Re: [jsr-314-open-mirror] [jsr-314-open] CDI constructor integration
by Ed Burns
>>>>> On Thu, 24 Jun 2010 10:42:03 -0400, Stephen Kenna <kenna(a)us.ibm.com> said:
SK> We did some testing on Glassfish, and not only did constructor injection
SK> not occur, but field injection did not occur either. (Field injection is
SK> working on JBoss)
Did you try putting the @Inject annotation on the field itself (not the
setter) and also putting the @javax.faces.bean.ManagedProperty
annotation on the field?
>>>>> On Sat, 26 Jun 2010 08:26:32 -0700, Pete Muir <pmuir(a)redhat.com> said:
SK> and we also need to support constructor injection
PM> I'm pretty [sure] you don't. The @ManagedBean which causes the JSF
PM> managed bean container to get involved is *different* to the
PM> @ManagedBean which the EE spec indicates should support
PM> (javax.faces.bean.ManagedBean vs javax.annotation.Managed[Bean] -
PM> and yes, IMO this is a crazy divergence, and we did argue against
PM> it).
This decision was driven by platform adoption more than anything else.
I decided it was important to support improverished (CDI-bereft)
containers like Tomcat 6 for JSF 2.0.
PM> Using this logic, there is *no way* for a managed bean which
PM> lives in the JSF managed bean container to become a managed bean as
PM> defined by EE.5.20, and thus support ctor injection. So, JSF managed
PM> beans are just required to support field injection.
PM> This is what we check in the CDI TCK.
PM> If you think about it, this makes sense. If you are in a CDI enabled
PM> bean archive, then why would you be using JSF managed beans. If you
PM> aren't in a CDI enabled bean archive, ctor injection is certainly
PM> not required.
Stephen, is this ok with you?
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Work Days Til JSF 2.1 Milestone 1
13 years, 10 months
[jsr-314-open-mirror] [jsr-314-open] Ajax inside a DataTable
by Cagatay Civici
Hi,
I've faced with an issue in our app I'd like to share when trying to update the datatable itself from a command element located inside a column. Case is to select a row, execute logic and update the datatable. Basic code:
<h:dataTable id="cars" var="car" value="#{tableBean.carsSmall}">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#{car.model}" />
</h:column>
<h:column>
<f:facet name="header">
Action
</f:facet>
<h:commandButton value="Some Action" actionListener="#{tableBean.handleRowAction(car)}">
<f:ajax render="cars" />
</h:commandButton>
</h:column>
</h:dataTable>
As datatable has a rowIndex >= 0 during rendering of commandButton f:ajax defines the component id to render as cars:{rowIndex} where I should expect "cars" only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax case.
Regards,
Cagatay Civici
13 years, 10 months
[jsr-314-open-mirror] [jsr-314-open] [ADMIN] Expert Community meeting 20100707 13:00 EDT
by Ed Burns
Hello Experts,
I would like to have a meeting of our expert community to go over our
plans for JSF 2.1. This query shows the spec issues we're targeting for
2.1 [3]. The dashboard being used by the management organization who is
sponsoring JSF 2.1 development is at [4]. This dashboard includes links
to relevant schedules.
Here is the call in information for the meeting.
Vienna Wednesday, July 7, 2010 at 7:00:00 PM UTC+2 hours CEST
(Austria)
London Wednesday, July 7, 2010 at 6:00:00 PM UTC+1 hour BST
(U.K. - England)
New York Wednesday, July 7, 2010 at 1:00:00 PM UTC-4 hours EDT
(U.S.A. - New York)
San Francisco Wednesday, July 7, 2010 at 10:00:00 AM UTC-7 hours PDT
(U.S.A. - California)
Toll Free US access number
1 866 682 4770
Conference Code: 7824109
Password: 7824109
Please see [1] for additional access numbers for your contry.
Please allocate 60 minutes for this meeting.
Sincerely,
Ed Burns
JSF Spec co-lead
[1] http://www.intercall.com/oracle/access_numbers.htm
[2] http://timeanddate.com/worldclock/meetingdetails.html?year=2010&month=7&d...
[3] https://javaserverfaces-spec-public.dev.java.net/issues/buglist.cgi?compo...
[4] http://wiki.glassfish.java.net/Wiki.jsp?page=3.1JSF
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Work Days Til JSF 2.1 Milestone 1
13 years, 10 months
Re: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal
by Ed Burns
>>>>> On Mon, 14 Jun 2010 11:49:36 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
>> public abstract class FaceletContext extends ELContext
>> {
>> // TODO: REPORT this aberration to the EG
>> public static final String FACELET_CONTEXT_KEY =
>> "com.sun.faces.facelets.FACELET_CONTEXT";
AS> Oh. Woops. :-)
AS> We should fix this, though, in the future... shouldn't we expose a
AS> type-safe utility method for this sort of thing rather than a named key?
I've opened spec issue [860-FACELET_CONTEXT_KEY] for this. I don't
think we should add a utility method right now. Let's rework this under
the View Abstract Syntax Tree work (which is beyond the scope of JSF
2.1).
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Work Days Til JSF 2.1 Milestone 1
13 years, 10 months
Re: [jsr-314-open-mirror] [jsr-314-open] [545-VisitHints] proposal
by Ed Burns
>>>>> On Thu, 10 Jun 2010 18:18:50 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> BTW, any thoughts on what an acceptable name, or, at least, prefix
AS> would be? The VisitHint will be SKIP_ITERATION. Can we go with
AS> something like "javax.faces.visit.SKIP_ITERATION" - or do we need to
AS> stay away from the "javax.faces" prefix since this won't be part of
AS> the specification?
I agree with Martin and Leonardo, the name you propose is acceptable,
Andy.
Thanks for providing the patch.
Ed
--
| edburns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Work Days Til JSF 2.1 Milestone 1
13 years, 10 months
