[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] JavaOne meeting
by Kito Mann
Hello everyone,
We've been talking about having a JSF meetup during JavaOne over on the
MyFaces list. When are people going to be around? I'm thinking Tuesday or
Wednesday is probably best. We were also thinking of maybe meeting in the
Mission so as to avoid the large crowds near Moscone. Thoughts?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
14 years, 3 months
[jsr-314-open-mirror] [jsr-314-open] CLOSED: small addition to composite component metadata specification
by Ed Burns
>>>>> On Mon, 23 Aug 2010 18:44:12 -0700, Ed Burns <edward.burns(a)oracle.com> said:
EB> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1782
EB> The proposed solution is to enhance the composite component metadata
EB> specification to include information about the list of composite
EB> component attributes for which default attribute values have been
EB> declared.
EB> This information is used in the Facelets tag layer in the code that
EB> installs the ValueExpression for any child attributes in the using page.
EB> In this case, the MetadataHandler manually removes the attribute from
EB> the attributes map if there is a ValueExpression for an attribute for
EB> which there also is a composite component attribute.
EB> SECTION: Modified Files
EB> ----------------------------
EB> M Spec section 3.6.2.1 Composite Component Metadata
EB> Add a new paragraph at the end of the section, which would fall under
EB> the bullet that describes the runtime representation of the
EB> <cc:attribute> element.
EB> The composite component BeanDescriptior must return a
EB> Collection<String> when its getValue() method is called with an
EB> argument equal to the value of the symbolic constant
EB> UIComponent.ATTRS_WITH_DECLARED_DEFAULT_VALUES. The
EB> Collection<String> must contain the names of any <cc:attribute>
EB> elements for which the default attribute was specified, or null, if
EB> none of the attributes have been given a default value.
I have committed this change.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 9 work days until JSF 2.1 Milestone 5
14 years, 3 months
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Thu, 26 Aug 2010 16:23:25 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> Hi
LU> I attached a patch with better documentation for TransientStateHelper -
LU> TransientStateHolder and the answers requested. If you need anything
LU> else just let me know and I'll do it.
Thank you. I'll work in the content of your revised patch. Also, I
can't say enough how great the test app is. Very thorough. It'll fit
right into our automated test library.
Leonardo, I'll need you to fill out and submit the necessary
documentation for the Joint Copyright Assignment so that both you and
the JSR sponsor (Oracle) can jointly own the copyright on the code.
Get this PDF <http://oss.oracle.com/oca.pdf>, print it out, fill it out
with pen, scan it, and email it to me directly. This is necessary to
take the patch, and it is also necessary if you want to get commit
access eventually.
LU> I resume the comments below:
Ok, I'll work this content into the spec language.
[...]
LU> To include the patch in jsf 2.1, we need to resolve the following point
LU> left:
LU> - On UIData.markInitialState do not use a facesContext attribute
LU> "com.sun.faces.MARK_INITIAL_STATE", instead it could be better to use
LU> a variable on FacesContext to indicate when we are marking the initial
LU> state,
LU> like FacesContext.isProcessingEvents() works.
We can do that if you like, but it's just syntatic sugar IMHO. I prefer
to just introduce constants rather than methods. Would you be ok if we
made it an official "javax.faces.MARK_INITIAL_STATE" attribute?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 11 work days until JSF 2.1 Milestone 3
14 years, 3 months
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Thu, 26 Aug 2010 11:01:08 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi all,
MM> thanks to Ed and Leonardo for this discussion - I really believe this
MM> is a positive example how any spec work should go ;)
MM> @Leonardo: if you need help with the wording, just ping me.
MM> @everyone else who is interested in this: please can you also invest
MM> some work to review this? this is really a delicate issue, and might
MM> change quite a lot of the UIData behaviour, so it makes sense you
MM> invest the time.
It is indeed incredibly delicate. It's so delicate that it's really
hard to specify it in a way that is coherent and easy to understand.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 15 work days until JavaOne 2010
14 years, 4 months
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Wed, 25 Aug 2010 20:12:59 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> The problem with allow it with a context-param is there is no way to
LU> "reset" the deltas or remove rows to synchronize the model with the
LU> component state.
LU> Suppose a simple use case, where there is a datatable and an option
LU> that removes one row. Since we don't have a way to notify the
LU> component that the row has been removed the state of the deleted row
LU> will be applied on the next one.
Ok, I see.
Now, when I discussed with the expert community at a recent meeting the
process for accepting new features for 2.1, I tried to be as clear as
possible that we'd need the contributing party to do *all* of the work.
Leorando, you've done the code, and it's great, but the spec language is
even more important since this body, technically, is partially
responsible for the spec. Oracle, as the sponsor, is solely responsible
for the impl. Now, as I said, I'm delighted with your contribution of
an implementation for this feature, but I need you to author as much as
possible of the spec text.
I've started by documenting the preserveRowComponentState property in
the UIData.setPreserveRowComponentState() method.
Please take a look at the javadoc I've generated in this attachment [1]
to issue 153 [2]. I've posed some questions in there, you can anwser
them here. Also, please correct my where I've gone wrong.
If you could submit a text file with sketches of the javadoc for other
elements of this feature, for example, the new TransientStateHelper
interface, it would really increase the likelihood of this feature
making it into 2.1.
[1] https://javaserverfaces-spec-public.dev.java.net/nonav/issues/showattachm...
[2] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 12 work days until JSF 2.1 Milestone 3
14 years, 4 months
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Wed, 25 Aug 2010 13:52:46 -0700, Ed Burns <edward.burns(a)oracle.com> said:
>>>>> On Tue, 17 Aug 2010 16:02:01 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> Hi
LU> 2010/8/13 Ed Burns <edward.burns(a)oracle.com>
EB> Here is my response.
LU> Note by default this feature is not active, so I think to test it fully it
LU> is necessary to activate it setting
LU> preserveRowComponentState to true.
EB> I have executed your very excellent testcase app. When I traverse the
EB> app with the markInitialState variant of your fix in place, the fields
EB> are red that should be red. When I remove the fix and re-traverse the
EB> app, all of the fields are red.
EB> I'm experimenting with having preserveRowComponentState to true by
EB> default. What do you think of that?
Well, that didn't work so well. As you'd expect, this failed pretty
quickly because we had an existing test that exercised the existing
behavior.
Is everyone OK with having this be configured as a UIData property, or
would it be better done using a context-param?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 12 work days until JSF 2.1 Milestone 3
14 years, 4 months
Re: [jsr-314-open-mirror] [jsr-314-open] Fwd: Fix UIData state saving model
by Ed Burns
>>>>> On Tue, 17 Aug 2010 16:02:01 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> Hi
LU> 2010/8/13 Ed Burns <edward.burns(a)oracle.com>
EB> Here is my response.
LU> Note by default this feature is not active, so I think to test it fully it
LU> is necessary to activate it setting
LU> preserveRowComponentState to true.
I have executed your very excellent testcase app. When I traverse the
app with the markInitialState variant of your fix in place, the fields
are red that should be red. When I remove the fix and re-traverse the
app, all of the fields are red.
I'm experimenting with having preserveRowComponentState to true by
default. What do you think of that?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 12 work days until JSF 2.1 Milestone 3
14 years, 4 months
