Re: [jsr-314-open] [www.javaserverfaces.org] A couple of things
by Lincoln Baxter, III
Even better, why not use/recommend embedded glassfish as the ultimate
quick-start through maven?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 10, 2009 3:43 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
Overall, the new home page looks great. However, I'm not comfortable with
the "Getting started" section. We are sending them on a wild goose chase
right away to Wikipedia, which wrongly identifies Tomcat as a Java EE
Application Server, which it is absolutely not (sorry, I get worked up over
that topic).
I think what we need to do is direct them straight to the getting started
page which provides a Maven 2 archetype to deploy either to Jetty/Tomcat or
a Java EE app server (GlassFish is probably going to be the most neutral
recommendation given it is the RI). We may have to tinker with our options
here. It really is more complex than it should be right now.
I'd like to recommend using the Maven 2 archetypes that Steven Boscarine has
been preparing in the Weld source tree. Keep in mind that there is no hard
dependency to Weld, except for the use of the Weld servlet extension to use
CDI on Tomcat and Jetty. The Java EE 6 archetype, on the other hand, creates
a project that produces a pure, server-independent WAR based on JSF 2.0, BV
1.0 and CDI 1.0. The only tie to Weld is an import of the helper POM that
sets the API versions in a dependency management section (just a convenience
thing). We are working to get these things published to Maven central.
Again, more details to come.
-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in
Action Registered Linux ...
15 years
Re: [jsr-314-open] [admin] JSF 2.1 branch
by Ed Burns
>>>>> On Fri, 11 Dec 2009 17:07:23 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> At the EG meeting, we discussed creating a JSF 2.1 branch. To our surpirse,
DA> we learned that this branch has already been created:
DA> https://mojarra.dev.java.net/source/browse/mojarra/branches/2_1_BRANCH/
DA> But Jim informed us that while it exists, it hasn't been updated in a while.
DA> Given how much collaborative development happens on JSF, I wonder whether it
DA> would be reasonable to request that we use a distributed system for
DA> prototyping (not necessarily that Mojarra has to move). Project Kenai is the
DA> supported distributed revision "forge" inside of Sun, and that would be
DA> accetable, though I will mention that Seam is looking to move to Git at
DA> Github.com, so we are partial to Git.
DA> So, before you work to update the branch, Jim, is there any chance we could
DA> do forks at Kenai? http://kenai.com/ Otherwise, we would like to request
DA> that the branch be updated.
My plan was to merge the branch back into HEAD and do the work there.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] [xmldecl-696] suppressing XML declaration for MR1
by Dan Allen
Max (Oracle) brought up a critical point at JSF Summit (and earlier in
private discussions). Facelets is passing through the XML declaration in a
template to the browser. This is problematic for certain browsers, to the
point that it can change the rendering behavior of the browser. There needs
to be a way to suppress this. A stopgap solution is to introduce a context
param. A more long term approach is to add an attribute to f:view that
indicates whether the XML declaration should be sent to the client (you may
want it for an atom feed for example).
I'll let Andy chime in on Max's behalf for follow up, since he has some use
cases he can cite and perhaps further suggestion.
-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://www.google.com/profiles/dan.j.allen
15 years
[jsr-314-open] [ajax] Updated proposal for PartialResponseWriter
by Jim Driscoll
Based on feedback from Imre and Ken, I've modified the proposal, below.
Please read through this, as silence == consent. If there are no
further comments, I'll enter this into the spec issue database, and the
changes will probably be high on my queue for implementation in January.
This change is intended to go into the MR.
-----------------------------
Problem Description:
PartialResponseWriter has very little JavaDoc or spec associated with
it. Users are finding it difficult to use as a result. Additionally,
the implicit call to startUpdate means that writing out other XML
directives from a custom component is quite difficult.
The JavaDoc preamble says:
PartialResponseWriter decorates an existing ResponseWriter to support
the generation of a partial response suitable for Ajax operations. In
addition to the markup generation methods inherited from
javax.faces.context.ResponseWriter, this class provides methods for
constructing the standard partial response elements.
The individual method summaries say such things as:
void startUpdate(String targetId)
Write the start of an update operation.
And
void startEval()
Write the start of an eval operation.
And
void startDocument()
Write the start of a partial response.
Currently, what to do if you were to call a startXXX method while
already in a startXXX function is unspecified.
The spec (section 13.4.4.1) simply says:
Writing The Partial Response
JavaServer Faces provides javax.faces.context.PartialResponseWriter to
ensure the Ajax response that is written follows the standard format as
specified in Section 1.3 “XML Schema Definition for Partial Responses”
Implementations must take care to properly handle nested CDATA sections
when writing the response. PartialResponseWriter decorates an existing
ResponseWriter implementation by extending
javax.faces.context.ResponseWriterWrapper. Refer to the
javax.faces.context.PartialResponseWriter JavaDocs, and the JavaScript
documentation for the jsf.ajax.response function for more specifics.
Proposal:
We need to tighten up the spec in several ways:
1) Add comments to the JavaDoc that PartialResponseWriter will typically
have startDocument and startUpdate called before the component can get
hold of it. Note that this is to allow interoperability with components
that are not instrumented for Ajax.
2) Expand description in 13.4.4.1 to describe that an error will be
thrown if:
startDocument is called more than once on a response.
any method is called after endDocument.
any method is called before startDocument
3) Add a description to the spec of what methods will typically be
called before the client receives the PartialResponseWriter in
RenderResponse. Describe when this is not so (render = @none).
4) Allow for the calling of other methods besides startUpdate within a
normal component’s Render Response.
a) I propose that we treat all calls to the following methods when
within a startUpdate block as having their content placed on a queue, to
be written out after the endUpdate is called:
delete
redirect
startEval/endEval
startUpdate/endUpdate
startExtension/endExtension
startInsertBefore/endInsert
startInsertAfter/endInsert
startError/endError
updateAttributes
b) for other (non-startUpdate) paired methods, calling any other method
than the ending method is an error, and will raise an exception.
c) unlimited nesting of startUpdates is allowed (though care should be
taken, since significant memory can be consumed) - all queued writes
that are made within that update block will be written out after the
endUpdate is called, essentially writing things out depth first.
5) Update JavaDoc to indicated paired methods -
startEval/endEval
startUpdate/endUpdate
startExtension/endExtension
startInsertBefore/endInsert
startInsertAfter/endInsert
startError/endError
It will be an error, and an exception will be thrown, to call one
method without the other.
Concluding statement:
While the description of this behavior (in particular the queuing) may
be a little difficult, I believe that this behavior most closely matches
what users are expecting when they currently use the API. If this
approach is accepted by the EG, I’ll write up the formal changes.
15 years
[jsr-314-open] [695-ccNamespace] CONDITIONALLY CLOSED (was: Re: [JSF 2.1 NEW] composite component namespace simplification)
by Ed Burns
>>>>> On Fri, 11 Dec 2009 14:35:22 -0500, Kito Mann <kito.mann(a)virtua.com> said:
KM> I like this idea... For a long time I've thought it was silly to use a
KM> full-blown URL when it isn't necessary; I've been using URNs for my own
KM> namespaces for a while.
KM> At any rate, the main issue here is consistency with the rest of Java EE --
KM> we should be careful here.
>>>>> On Fri, 11 Dec 2009 13:04:17 -0600, Jason Lee <jason(a)steeplesoft.com> said:
JL> On 12/11/09 12:49 PM, Dan Allen wrote:
>> My second choice is (a), so if I lose on (c), I'll be happy with (a)
>> too. I think that (b) is just too vague.
JL> My preference is a, c, then b.
a) jsf:cc:whatevername
b) cc:whatevername
c) jsfcc:whatevername
This issue has been discussed thoroughly and the consensus rests on (a).
I also favor (a). I have filed [1].
I'm marking it conditionally closed here pending the result of a "heads
up" email to get feedback from the rest of JavaEE.
Finally, we can't make this change in the very next release of the spec
because the very next release will only contain very simple spec
changes. However, there's nothing stoping implementors from doing it.
Ed
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=695
15 years
[jsr-314-open] [admin] JSF 2.1 branch
by Dan Allen
At the EG meeting, we discussed creating a JSF 2.1 branch. To our surpirse,
we learned that this branch has already been created:
https://mojarra.dev.java.net/source/browse/mojarra/branches/2_1_BRANCH/
But Jim informed us that while it exists, it hasn't been updated in a while.
Given how much collaborative development happens on JSF, I wonder whether it
would be reasonable to request that we use a distributed system for
prototyping (not necessarily that Mojarra has to move). Project Kenai is the
supported distributed revision "forge" inside of Sun, and that would be
accetable, though I will mention that Seam is looking to move to Git at
Github.com, so we are partial to Git.
So, before you work to update the branch, Jim, is there any chance we could
do forks at Kenai? http://kenai.com/ Otherwise, we would like to request
that the branch be updated.
-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://www.google.com/profiles/dan.j.allen
15 years
Re: [jsr-314-open] Our good friend strikes again:
by Ed Burns
>>>>> On Fri, 11 Dec 2009 10:09:26 -0800, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> Anyone want to volunteer to contact him, to correct the factual
JD> errors (including the fact that he could probably could have avoided
JD> using a 3 1/2 year old spec in favor of a recent one), and tell him
JD> we're examining his comments for concrete solutions (or better, turn
JD> him to suggesting concrete solutions, with APIs?)
I agree that one person here should be given responsibility for this
task but the choice of person is important. They need to be close
enough to the spec to speak with credibitily, but far enough away to not
be seen as being defensive. Whomever volunteers, their job will be made
easier by the rest of us on the group giving feedback and commentary.
I think Lincoln or Neil would be good choices.
Anyone?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] Nick is still having problems posting
by Jay Balunas
Hi Guys,
Just got done talking with Nick he is having problems posting and we are not sure exactly why. He received a letter from the system saying he has post rights, but a test letter never went through. He is using nbelaevski(a)exadel.com to send the email.
Can someone take a look and see what might be going on?
Thanks,
Jay
15 years
