[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each
by Ed Burns
This is the final list of issues for JSF 2.0. No other issues will be
considered for 2.0.
I do not think content of any of these issues, nor their quantity,
warrant another Proposed Final Draft, but I will of course produce an
Editor's Draft for the public on jsr-314-open to review.
I will send another email with the dates for the remainder of JSR-314.
Any further discussion on any topic sent to this list will be rolled
into the next release of the spec.
SECTION: List of EG Members from whom I have obtained explicit buy-in
I have obtained explicit buy in for this list in its present state from
the following EG members.
Pete Muir Status: DONE, but need final official answer from JBoss. Promised by 1800 EDT 20090415.
Andy Schwartz 617 794 7974 Status: DONE Spoke with him 1319 20090415
Kito Mann 917 848 3359 Status: DONE Spoke with him 1600 20090415
Martin Marinschek +43 699 1805 3906 Status: DONE Spoke with him at 1400 EDT 20090415
Ken Paulsen x42083 Status DONE Spoke with him 1403 20090415
Alexandr Smirnov DONE IRC chat with him 16:00 20090415
SECTION: Issue sums
Number of issues remaining: 30
I've broken down the issues into two groups, bigger and smaller. I
assert that we do not need to do a PFD2 because none of the issues are
so big as to warrant such an action.
Bigger issues:
Number of bigger issues: 16
deferred: 5
will fix: 10
pushed to EG member requesting the issue: 1
Smaller issues:
Number of smaller issues: 14
deferred: 1
will fix: 13
SECTION: Bigger issues
PM> ISSUE: 1) Fully stateless views. This is a performance optimization
PM> which is ideal for the use case of pages which are output-only (no
PM> form). This is moderately complex to get right, and a blocker in our
PM> opinion. This also has the support of Apache.
We see two aspects to consider.
a. Marking specific views in an app as stateless. Putting a
transient="true" attribute on <f:view> doesn't work here because the
template page with <f:view> can be shared across pages.
There are several options we could try but none of them are feasible at
this point in time.
b. If the Form Renderer never calls StateManager.writeState(), and the
ViewHandler is aware of this fact, then you have a stateless view.
Therefore, statelessness is an implementation detail. Adam Winer
provided this idea, which we implement in Mojarra.
ACTION: Defer to a later release.
EB> Pete agrees to defer, but Gavin does not.
EB> Andy agrees to defer.
EB> Ken agrees to defer.
EB> Martin agrees to defer.
EB> Kito agrees to defer
EB> Alexandr, agrees to defer, but is unhappy about it.
PM> ISSUE: 3) Better handling of whitespace in facelets. Currently
PM> whitespace in view sources can get "eaten" and you have to resort to
PM> tricks like to add space. I would put this as a critical and
PM> the (spec) complexity as low (simply switch it on/off).
ACTION: Defer to a later release.
EB> Pete says, "70 - yes, defering that is fine"
EB> Andy is ok for deferring this
EB> Ken is ok to defer.
EB> Martin agrees to defer. Not a spec issue.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 2) First class support for page actions. This allows a more
PM> action orientated approach (Struts style) approach to page
PM> authoring, where some arbirtrary method can be run when the page is
PM> accessed. Use cases include security (redirect to another page if
PM> the user isn't logged in for example). JSF2 currently includes
PM> "second class" support - it's possible to do this stuff, but not in
PM> simple fashion. As the design for this has already been done, and
PM> reviewed/approved by the EG, the complexity is low. I would put this
PM> as a blocker. It also has the support of Oracle.
Pete, when we had the discussion regarding View Parameters, we decided
to defer Page Actions to a later release. We will not reverse that
decision.
ACTION: Defer to a later release.
EB> Pete says "I am happy for this to slip, given you can do a
EB> workaround with events. l know Dan is unhappy with the current
EB> state. On this one, Gavin was wavering, and would probably be happy
EB> to slip it".
EB> Andy can accept deferral for this
EB> Ken says, "Events should be able to accommodate this use case until
EB> we have a chance to improve the user-experience in a later release.
EB> I think we should defer this.
EB> Martin says ok to defer. But Ed and Martin agree that we should
EB> have a {Pre,Post}BuildViewEvent that is published appropriately.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 5) make behaviour of new components more consistent -
PM> currently f:validateBean (JSR-303 support) / f:ajax use different
PM> strategies to mark areas of the areas of the page to enable. Align
PM> these. This is a blocker (once it is written in stone we can't go
PM> back and fix it) and complexity low (the EG has agreed on the
PM> correct design, so the language needs tweaking in the spec and
PM> javadoc). This has the support of Oracle.
ACTION: If the EG agrees that the default validator setup currently hard
coded into UIInput.encodeEnd() can be moved into
Application.createComponent(), this can be done.
EB> Pete agrees with the plan on this.
EB> Andy agrees with the plan on this.
EB> Ken agrees with the plan on this.
EB> Martin agrees with the plan on this.
EB> Kito agrees with the plan on this.
EB> Alexandr agrees with the plan, but thinks the tag handler is a
EB> better place to imbue the component with the default validator.
PM> ISSUE: 7) Allow multiple error messages for a component to be
PM> displayed - especially useful for JSR-303 support. This is
PM> complexity low, and priority minor (easy for an addon to fix).
ACTION: Pete, please submit a diff patch modifying the following files:
standard-html-renderkit-base.xml jsf-api/doc/standard-html-renderkit-base.xml
message-message-props.xml jsf-api/doc/message-message-props.xml
to specify the change, and the necessary implementation changes for this
feature.
For to the patch to be accepted at this VERY late date it must meet the
following requirements. Because of the late timing of this feature
request we will be unable to accept the feature if the patch doesn't
meet all of the following requirements.
* All existing automated tests still run successfully after applying the patch.
* The spec wording in the patch requires no grammatical or formatting
changes.
* The patch is sent to the EG list no later than 23:59 EDT Wednesday
20090415.
RL> ISSUE: 2. View ID Derivation Fix
RL> (java.net Issue 1002)
RL> Status: Ed had a fix - push back from Ken Paulsen on the fix;
ACTION: Because this breaks the V3 Admin GUI, it must be fixed for 2.0
=> edburns fix by Thursday 20090316 17:00 EDT.
RL> ISSUE: 3. Client Behavior in Composite Components
RL> (patch from Exadel)
RL> Status: Patch 1 checked in; Patch 2 checked in;
RL> Javadocs / prose updates need to be made.
ACTION: Fix checked in to revision 6952, will review spec implications
RL> ISSUE: 4. Bean Validation Bug Fixes
RL> (java.net issue 1058)
RL> Status: Checked in; Needs discussion; Javadocs, prose updates
ACTION: Will review docs, RELEASE_PENDING. Make sure spec for
CompositeComponent Attributes ELResolver mentions this, 5.6.2.2
JD> ISSUE: Impl 1071: UIData.visitTree()
ACTION: Will Fix. fully specify
JD> ISSUE: Impl 1072: Facelet Meta* Javadocs not cleanroom implementable
ACTION: Will fix.
EG> ISSUE: JavaScript disabled support [Was: Outcome of JSFDays
EG> discussions]
ACTION: This can easily be doable in a later release. Considering the
late date of this request we need to defer it.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken is ok to defer.
EB> Martin is ok with defer
EB> Kito agrees to defer.
EB> Alexandr agrees to defer.
EG> ISSUE: minor feature enhancement for Facelets/VDL
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer.
EG> ISSUE: required attributes in composite components
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer this.
EB> Martin is ok to defer this.
EB> Kito ok to defer this.
EB> Alexandr, agrees to defer
EG> ISSUE: remove target attr from h:outputStylesheet (was:
EG> h:outputStylesheetdocs need to be updated)
ACTION: Will fix this
EG> ISSUE: #{compositeComponent.attrs....} verbosity
ACTION: Change "compositeComponent" to be "cc". Implementations may
provide a context-param that allows renaming the implicit object name to
an arbitrary value for the case where an app happens to have a
managed-bean named cc.
EB> Pete says he won't object to this solution.
EB> Andy is ok with this action
EB> Ken says, "I like 'cc' better to solve the verbosity issue. I
EB> recommend deferring on the renaming via context-param for now -- but
EB> would not object to it making the release if others feel strongly
EB> that it needs to be done now."
EB> Martin is ok with this solution.
EB> Kito is ok with this solution.
EB> Alexandr is ok to defer.
EG> ISSUE: composite insert children
ACTION: 2 days. Take the following steps
EB> Pete is ok with this action.
EB> Andy is ok with this action.
Ken says,
KP> I am very nervous about the reparenting (insert*) commands. If 2
KP> composite:insertFacet/Children tags are used in the same composite
KP> component, it will likely fail. Is that acceptable?
EB> We will specify that if multiple <composite:insertFacet> elements
EB> exist with the same name in the <composite:implementation> section,
EB> the "last one wins".
EB> We will specify that if multiple <composite:insertChildren> elements
EB> exist in the <composite:implementation> section the facelet layer
EB> must throw a FaceletException.
KP> If the component inserted has code which does: getParent(), they'll
KP> be exposed to the internal workings of a composite component (which
KP> they shouldn't know exists).
Yes, you are correct, but I feel this is sufficiently corner case to
ignore.
KP> I would prefer render* in most cases. In cases where this isn't
KP> possible (implementing a facet inside a composite component),
KP> perhaps we can do a proxy component which can be added to the inner
KP> facet and delegate rendering to the page-facet? I think there will
KP> be problems with this implementation. If I am wrong, then I do not
KP> object to this going in -- otherwise, I think it should be deferred.
EB> Martin is ok with this action.
EB> Alexandr is ok with this action.
1. rename composite:insertFacet to composite:renderFacet
2. create composite:insertFacet that reparents the named facet from the
top level component to be a facet child of the parent tag in the
composite:implementation section in which the composite:insertFacet
resides.
3. delete composite:renderUsingPageChildren
4. create composite:insertChildren that reparents the children from the
top level component to the parent of tag in the composite:implementation
section in which the composite:insertChildren resides.
5. For composite:insert{Facet,Children} support nested composite
components.
=> edburns take this to Bill and see what he thinks, if we need to do a
PFD2.
SECTION: Smaller issues
PM> ISSUE: 6) Better support for timezones. Currently only one of two
PM> timezones can be used - default or system. The user may well be in
PM> some other timezone entirely, so make the timezone used
PM> configurable. This is a critical issue, and the complexity is medium
PM> (but we have a full proposal for this waiting in the wings that
PM> didn't make it due to time constraints)
If this was a truly critical issue, it would have been brought up a long
time ago, not after the PFD has been published. Furthermore, this is a
platform level thing. I direct you to your JSR-316 EG rep for this feature.
ACTION: Defer to later release.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken says defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer
RL> ISSUE: 2. 11.4.7 - Absolute ordering. I think if a document name
RL> is explicitly referenced but not present, an exception should be
RL> thrown.
ACTION: We'll log a message in this case.
EB> Pete's ok with this action.
EB> Andy's ok with this action.
EB> Ken's ok with this action.
EB> Martin is ok with this action.
EB> Kito is ok with this action
EB> Alexandr states, "if related document was not present, it is
critical error, therefore Exception should be thrown." Given the
prevailing opinion, we'll stick with logging.
RL> ISSUE: 3. FacesRenderKit annotation hasn't existed from some time
RL> now.
ACTION: Remove this from the spec.
RL> ISSUE: 4. Javadocs for EditableValueHolder.addValidator() and
RL> ValueHolder.setConverter() mention ResourceDependency annotation
RL> processing. This documentation should be moved to
RL> Application.createConverter() and Application.createValidator().
ACTION: Will fix this in the spec.
RL> ISSUE: 5. 3.1.11 mentions that the AttributesMap, if the current
RL> component is composite, must eval any ValueExpressions stored in the
RL> Map. This is incorrect. This logic is handled by the
RL> CompositeComponentAttributesELResolver
ACTION: Will fix in the spec.
RL> ISSUE: 6. Preface references META-INF/managed-beans.xml. Support
RL> for this file is no longer required.
ACTION: Will fix.
RL> ISSUE: 7. 5.6.2.2 Doesn't mention any support for the special
RL> parent keyword in #{compositeComponent} expressions.
ACTION: Will fix.
RL> ISSUE: 8. 6.1.1.15 lists Flash as a property of FacesContext. It's
RL> now a property of ExternalContext.
ACTION: Will fix.
RL> ISSUE: 9. 7.1.1 and 7.1.2 Typo in assertion marker
RL> 'defualtActionListener' and 'defualtRenderKit' There may be others.
ACTION: Will fix
RL> ISSUE: 10. 7.4.2 will need to be discussed due to the
RL> implementation of issue 1066.
ACTION: Will fix
RL> ISSUE: 11. 7.4.3 should include a navigation case example with
RL> redirect parameters.
ACTION: Will fix
RL> ISSUE: 7.5.1 and others. This may already be done, but
RL> PageDeclarationLanguage should be ViewDeclarationLanguage
ACTION: Will fix. Make sure retargetAttachedObjects and retargetMethodExpressions are on VDL, not ViewHandler.
RL> ISSUE: 1. Spec ResponseWriter methods: startCDATA endCDATA (java.net
RL> issue 1055) Status: impl done; method javadocs / prose need to be
RL> done;
ACTION: Will fix
EG> ISSUE: View and custom scoped eager managed beans?
ACTION: Will Fix. Add eager for session scoped managed beans
RL> Update 3rd bullet in 11.5.1 so that pattern for custom faces config file
names is something that ends with .faces-config.xml. This brings it in
alignment with 11.4.
--
13 years, 10 months
[jsr-314-open] inter-component and form-level validation
by Dan Allen
>From the jsr-314-comments mailbox comes this discussion between myself and
Mathias Werliz about inter-component validation. Unfortunately the
discussion progressed outside of the mailinglist, so the post below is the
aggregate of the individual messages. If there is confusion we can summarize
the discussion up to this point and continue the discussion on each
individual point.
---------- Forwarded message ----------
From: Dan Allen <dan.j.allen(a)gmail.com>
Date: Thu, Jul 9, 2009 at 2:09 PM
Subject: Re: [jsr-314-open] inter-component and form-level validation
To: "Werlitz, Mathias" <werlitz(a)adesso.de>
Cc: jsr-314-comments(a)jcp.org
On Thu, Jul 9, 2009 at 11:36 AM, Werlitz, Mathias <werlitz(a)adesso.de> wrote:
> Sorry for the late response. I’m very busy on a customer project at the
> moment, analysing JSF 1.2 (view state) and Facelets memory consumption on
> IBM Portal 6.1.
>
> I agree that there are two basic approaches to solve multiple-field /
> form-validation:
>
> 1. model based validation after the update model phase and
> 2. validating the converted values of multiple components
>
> In both cases there should be an easy way to assign the proper validation
> message to the originating input component or group of input components. With
> complex forms including inputs within naming containers like <h:dataTable>
> this may become quite complicated. Flattening the properties of the object
> graph for JSR-303 model validation does not seem to be a good idea in this
> case.
>
> I realize that JSR-303 isn't going cover every case. I must admit to still
> being the fence on how to best handle the situation you are citing...meaning
> can I do it comfortably with JSR-303 or not? I think a solid use case would
> help us test the limits.
>
>
>
> Well I simplified a test case – I’m unsure that this is easily done with
> JSR-303. Image a form with a master date and several additional dates. The
> number of the additional dates is dynamic – will be configured by the user
> (added and removed) or determined by the server.
>
> For simplicity there is only one multi-field validation rule: all
> additional dates must be after the master date. The view would look
> something like this (note: the list of additional dates is a list of a
> custom bean that stores the date and maybe additional data for every entry):
>
>
>
> <h:input id=”masterDate” value=”mybean.masterDate” />
>
> <h:datatable value=”mybean.myAdditionalDates” var=”item” >
>
> <h:input id=”addtionalDate” value=”item.additionalDate” />
>
> </h:datatable>
>
This could be done with JSR-303. You can have a validation annotation on the
array (or List) property holding the "after" dates and say that they must
come after the master date property. But again, the limitation is that it
has to happen after update model values.
Earlier when I said you have to flatted your model, I didn't mean you
couldn't use collections. You just can't easily validate a property on one
class against a property on another.
But pointing that aside, you could still accomplish w/ a regular JSF
validator if all conversions happened before the validation phase. Then you
just do something like:
<h:input id="additionalDate" value="#{item.additionalDate}">
<x:validateAfter id="masterDate"/>
</h:input>
>
>
>
> One downside of the model based validation is that the whole validation
> process is split up into two phases. That means the user may get the error
> messages in two bunches: first the errors of the validation phase and later
> the model errors. This can be quite confusing.
>
> The reality is, there are two validation phases in input-based
> applications. You simply cannot test some business validations if you don't
> have correct data to start with. I think the real point is to make sure that
> all input validation is handled together...and that business validation is
> really business validation. Having one date before another I agree is likely
> an input validation, not a business validation.
>
>
>
> Yes, that’s the point. At the moment JSF does make it very hard to do the
> input validation altogether.
>
There will likely always be two steps. The question is, can we get those two
steps right?
>
>
> To emphasize why there must be two validation phases, consider this case. You
> walk into an ice cream store and the employee asks you which flavor of ice
> cream you want. You say you want pizza. They say, "Sir, we don't have pizza,
> you have to pick and ice cream." Then you say that you want Heath ice cream.
> The employee says, sorry, we don't have that in stock. So the first is an
> input validation, the second is business. The employee couldn't have told
> you they don't have Heath ice cream in stock because the employee doesn't
> know what you want. It's not really that confusing.
>
>
>
> I agree with you, but in fact there are three steps where messages could be
> associated with an input field (convert, validation, business rules) and
> every step depends on the previous one.
>
>
> Well, one common requirement of our customers is: Display error messages as
> early as possible. Separating the validation into two phases makes this
> hard. Using good old Struts this example is no problem at all.
>
> That's because Struts effectively updated the model and then validated,
> moving all validation to the later phase. In JSF there is an understanding
> that values won't get assigned to the model unless they are valid syntax or
> type. You could throw that out the window and do all your validations after
> the update model values phase and get the same result. So we are questioning
> the fundamental guarantee of JSF (which, by the way, may need to be
> questioned).
>
>
>
> Well I think you got me wrong. The point is that in Struts you are able to
> store all the form data (as strings) in a form bean. You are responsible to
> make your own conversation. But because of that you are able to validate all
> input data including multi-field validation. On success you proceed to
> assign the values on your own to the real model.
>
>
>
> That’s not perfect. The only problem with JSF is that you don’t have this
> intermediate view on the form data where all converted values of the form is
> available altogether before deciding to move on to the update model phase.
>
I think we are saying the same thing. JSF applies the values directly to the
model by attempting to convert each value. Now, you could copy all
properties to a model with string properties and essentially coerce JSF into
skipping validation so that you can handle it yourself, but that really
defeats a large goal of JSF.
>
> I like your idea of dividing converting and validation. I think JSR-303
> model based validation is not sufficient. In the discussion with my
> college we had a similar idea as a workaround for JSF 1.2: We thought about
> a special custom validator added to all relevant input components that
> collects all converted input data from the components and the corresponding
> client ids/component instances. This also works fine with <h:dataTable>. The
> data could be collected with a Map or special validation-model bean. At the
> end of the validation phase another special form/multi-field validator
> (possible phase listener) is called with the collected data and invokes the
> validation logic. This way you get all converted data, components/client
> ids, the real model data is not touched at all and the whole validation is
> processed in one phase.
>
> It seems blatantly obvious to me that all conversion should happen before
> any validation occurs. I think the current situation is ridiculous and it's
> the root of why multi-field validation is so screwed up to begin with.
>
> See my previous comment… The question is: when this will change. JSF 2.0
> would be the right version. But I guess it’s already too late for such a
> fundamental change in the lifecycle – separating conversation and
> validation.
>
It won't be JSF 2.0. Hopefully JSF 2.1 or sooner.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
14 years, 8 months
[jsr-314-open] [NEW - MR] Add ExpressionFactory to "11.4.6 Delegating Implementation Support"
by Pete Muir
Hi all,
I would like to propose adding ExpressionFactory to the list of
classes required to support the decorator pattern. This is to aid
integration with CDI (JSR-299) implementations, which are require a
callback when EL expression evaluation completes; the necessary hook
into EL is via the ExpressionFactory. Adding ExpressionFactory to this
list would make implemetors have to jump through fewer hoops to obtain
the callback [1].
I propose this change to the MR so it can be used in the EE6 platform,
the target for JSR-299.
Changes to spec required
-----------------------------------
* Add ExpressionFactory to the list of classes required to support the
decorator pattern
* Add ExpressionFactoryWrapper class to support the decorator pattern
Changes to implementation required
--------------------------------------------------
* Add support for exposing and using wrapped ExpressionFactory
Impact on users and frameworks
--------------------------------------------
Users can now:
* call application.setExpressionFactory(new
WebBeansExpressionFactory(application.getExpressionFactory());
* configure a wrapping expression factory in faces-config.xml
<application>
<expressionFactory>org.jboss.webbeans.el.WebBeansExpressionFactory</
expressionFactory>
</application>
[1] Currently this is possible by wrapping the application via the
application factory and overriding the getExpressionFactory method
14 years, 8 months
[jsr-314-open] Providing the ability to instantiate EzComp components in Java code
by Dan Allen
This is a somewhat old request from Lincoln Baxter that I don't think ever
made it to the list. After reviewing the message, I too feel it is worth
discussing for JSF 2.1.
---------- Forwarded message ----------
From: Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
Date: Thu, Mar 5, 2009 at 10:25 PM
Subject: [jsr-314-open] Providing the ability to instantiate EzComp components in Java code
To: jsr-314-comments(a)jcp.org
I feel there is value in the ability to instantiate an EzComp object in
Java so that a component tree can be built in a backing bean (or other
Class). JSF must be doing this in the background through Facelets, so
providing this ability in Java should not be too difficult.
Referencing an object by its namespace should be sufficient:
UIComponent comp = Application.createComponent(FacesContext, "
http://java.sun.com/jsf/composite/mynamespace:component").
Attributes would be assigned via the normal method:
comp.getAttributes().put("rendered", false);
This would greatly extend the reach of EzComp objects.
Thanks,
Lincoln
PS... re-posted here on suggestion of Ryan Lubke
14 years, 8 months
[jsr-314-open] outputStylesheet and media type, bug #550
by Jim Driscoll
There's a bug filed against the spec, 550.
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=550
I also filed a separate bug on the issue, which I've just marked as a
duplicate.
To summarize the problem: Sometimes, you don't *want* the css link to
be media="screen", but that's what's currently required by the spec.
To fix this, we need to add an attribute to the outputStylesheet tag,
"media". Then specify that the media type is set to that attribute's
value, or unset if not specified.
I think this is example of JSF overspecifying - there was no reason to
specify media type of 'screen' in the output tag.
This is a small change, and there's good reason to view this as an
oversight in the 2.0 spec. As such, I'd like advocate placing this on
the errata list, and change the implementation immediately. Please
respond if you disagree.
Jim
14 years, 9 months
[jsr-314-open] request for listeners to support container injection and life-cycle callbacks
by Dan Allen
One of the questions that is often raised when discussing Java EE
integration (JSR-299 and EJB) is how to get a reference to a
container-managed resource from within a JSF listener (e.g., EJB session
bean, BeanManager, EntityManager). While Java EE certainly provides
mechanisms to lookup up a resource, such as through JNDI, I think we need to
restate the question at hand. Why is it that JSF listeners don't support
Java EE resource injection like managed beans. Requiring this functionality
in a Java EE environment would go a long way towards making JSF extensions
(such as Seam or ADF) portable and generally make the effort of integration
w/ container-managed resources easier.
With that said, I would like to propose for the next rev of the JSF
specification that listeners, in addition to managed beans, support
container injection and life-cycle callbacks when JSF is run in a Java EE
environment (the rule for servlet containers would parallel that of managed
beans today).
Listeners include:
PhaseListener
SystemEventListener
BehaviorListener? (not sure)
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
14 years, 9 months
[jsr-314-open] EL property accessor name Forgiveness / Flexibility
by Lincoln Baxter, III
I just ran across this when using the Builder pattern in some Pojos --
each setter returns the current instance of the pojo to allow for
chaining set-statements:
Pojo pojo = pojo.setName("name").setValue(23);
With setters implemented like so:
public Project setName(final String name)
{
this.name = name;
return this;
}
But JSF complains:
javax.servlet.ServletException:
javax.el.PropertyNotFoundException: /faces/page.xhtml @36,20
value="#{pageBean.pojo.name}": Property 'name' not writable on type
java.lang.String
It seems to me that this is a slightly harsh restriction. Is there
anything we can/should do about this? Does anyone else feel it's worth
mentioning?
The obvious answer is to use dumb getter/setter methods, but in some
cases that can be restrictive, and I like the idea of being more
forgiving.
Thoughts?
--Lincoln
14 years, 9 months
[jsr-314-open] f:viewParam property javadoc inconsistent
by Dan Allen
>From the jsr-314-comments mailbox comes this message from Leonardo Uribe
reporting inconsistencies in the javadoc for the f:viewParam component tag.
---------- Forwarded message ----------
From: Leonardo Uribe <lu4242(a)gmail.com>
Date: Tue, Jun 30, 2009 at 2:28 PM
Subject: [jsr-314-open] f:viewParam property javadoc inconsistent between
To: jsr-314-comments(a)jcp.org
Hi
Just to note it (maybe you already noted it, maybe not), the javadoc for jsp
and pld is inconsistent for this component.
It appear two properties: maxlength and for, but no property getter and
setter founded on javax.faces.component.UIViewParameter.
In theory, a component that works on jsp and facelets should have the same
properties. The only justification for have one property in facelet and not
in jsp is some hack on its related TagHandler (really I have never seen this
case), but this does not seem to be the case.
regards
Leonardo Uribe
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
14 years, 9 months
[jsr-314-open] FYI: Annotations for JSF 2.0 specification
by Dan Allen
>From the jsr-314-comments mailbox, there was an inquiry about the location
of the documentation for the managed bean annotations. You can find a link
to the JavaDoc below.
-Dan
---------- Forwarded message ----------
From: Ed Burns <Ed.Burns(a)sun.com>
Date: Mon, Jun 29, 2009 at 7:35 PM
Subject: [jsr-314-open] Annotations for JSF 2.0 specification
To: David Konecny <David.Konecny(a)sun.com>
Cc: Roger Kitain <Roger.Kitain(a)sun.com>, Denis Anisimov <
Denis.Anisimov(a)sun.com>, jsr-314-comments(a)jcp.org, Petr Jiricka <
Petr.Jiricka(a)sun.com>
>>>>> On Thu, 11 Jun 2009 10:13:49 +1200, David Konecny
<David.Konecny(a)Sun.COM> said:
DK> Hi Roger,
DK> Denis and me are both working on JSF 2.0 support in NetBeans IDE.
DK> I still have a question: is there a list of all annotations which JSF
DK> 2.0 implementation must support? JSF 2.0 spec (Proposed Final Draft
DK> Candidate 20090327 and latest version available at jsp.org) states in
DK> chapter 11.5 just 5 annotations (for component, converter, renderer,
DK> renderkit and validator). But Ryan in his blog entry
DK> http://blogs.sun.com/rlubke/entry/faces_config_xml_we_don suggests many
DK> more annotations being part of JSF2.0 API. And mojarra builds confirm
that.
Here they are:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/managed-bean-javadocs...
Ed
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
14 years, 9 months
