Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
>>>>> On Mon, 18 Jan 2010 11:40:14 -0800, Cay Horstmann <cay(a)horstmann.com> said:
CH> On 01/18/2010 10:46 AM, Lincoln Baxter, III wrote:
>>
>> PS. As a side-note. I've updated the Tutorial on
>> www.javaserverfaces.org/getting-started
>> <http://www.javaserverfaces.org/getting-started> to reflect the
>> Development ProjectStage in web.xml. So by default, people following the
>> getting-started tutorial will see /up front/ that there is a control for
>> the ProjectStage, and that we chose to show them the Development mode
>> first. Four lines of XML is trivial to include in a tutorial, and also
>> relatively self-explanatory.
CH> (That's get-started, not getting-started.)
CH> In a modern app server, you don't need to use any web.xml. You could
CH> tell people to install GlassFish and deploy a directory containing
CH> nothing but
CH> index.xhtml
CH> next.xhtml
CH> WEB-INF/classes/org/javaserverfaces/Hello.class
CH> No Maven, no XML. Now that's an OOBE :-)
Yes, this is definately the way to sell JSF to people for getting
started.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
>>>>> On Mon, 18 Jan 2010 13:46:35 -0500, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com> said:
LB> However, I really think that access through a *
LB> -Djavax.faces.ProjectStage=Development* system property is simple, and
LB> understandable. It doesn't take much work to figure out how to use it, much
LB> less potentially confusing than configuring JNDI and it's mapping in
LB> web.xml.
For the record, the Servlet EG was STRONGLY against a system property
because such values are VM wide, whereas the intent of the ProjectStage
value was designed to be application wide.
Does anyone HERE, in *this* EG, agree with this particular argument from
the Servlet EG?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
Re: [jsr-314-open] jira edit access
by Ed Burns
>>>>> On Tue, 19 Jan 2010 17:40:31 +0100, Ganesh Jung <ganesh(a)j4fry.org> said:
GJ> please provide edit access to
GJ> https://javaserverfaces-spec-public.dev.java.net/issues for
GJ> 'ganeshpuri'
GJ> These issues seem to have slipped into the wrong target milestone,
GJ> they all target AJAX and 1.2, which is a bit condracdictory.
GJ> Does anybody have a problem if I set them to 2.1, once I can edit them?
Yes, please do.
Thanks.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
[jsr-314-open] jira edit access
by Ganesh Jung
please provide edit access to
https://javaserverfaces-spec-public.dev.java.net/issues for
'ganeshpuri'
These issues seem to have slipped into the wrong target milestone,
they all target AJAX and 1.2, which is a bit condracdictory.
Does anybody have a problem if I set them to 2.1, once I can edit them?
678 ENHANC P3 All javaserverfowner driscoll NEW
1.2 Add new client event type - between complete and success
679 DEFECT P3 All javaserverfowner driscoll NEW 1.2 Chained
response actions should all be run, even if one fail
680 DEFECT P3 All javaserverfowner driscoll NEW 1.2 Add
constants for event and error names
681 DEFECT P3 All javaserverfowner driscoll NEW 1.2 Response
XML should include a version #
682 DEFECT P1 All javaserverfowner driscoll NEW 1.2 Add
support for XHR timeout
683 DEFECT P2 All javaserverfowner driscoll NEW 1.2 Form
serialization should happen at the last possible second
684 ENHANC P3 All javaserverfowner driscoll NEW 1.2 Be able
to get a list of all client side event listeners
685 DEFECT P3 All javaserverfowner driscoll NEW 1.2 Add
ability to cancel a client side listener
688 ENHANC P4 All javaserverfowner driscoll NEW 1.2 Allow for
mixed Ajaxified and non-ajaxified controls in a pa
689 DEFECT P3 All javaserverfowner driscoll NEW 1.2 Provide
ajax function to get the number of requests on the q
692 DEFECT P3 All javaserverfowner mwessendorf NEW 1.2 JSF-2
AJAX response needs default namespace declaration
723 ENHANC P2 All javaserverfowner ganeshpuri NEW 2.1 add
partialSubmit parameter
724 DEFECT P1 All javaserverfowner ganeshpuri NEW 2.1 run
scripts from AJAX response
725 DEFECT P3 All javaserverfowner ganeshpuri NEW 2.1 apply
style tags in AJAX responses
726 ENHANC P3 All javaserverfowner ganeshpuri NEW 2.1
specifiy parameter 'queue' to define AJAX queue size
Best regards,
Ganesh
14 years, 11 months
Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
CH> Still, this points to the fact that the default for the project stage is
CH> probably wrong.
EB> Let's take a step back and look at my motivation for wanting to have the
EB> default be "Development". One of the biggest classes of gripes about
EB> JSF is the "JSF's error messages suck, if you get them at all" kind of
EB> gripe. We need to make the out of the box experience address those
EB> kinds of gripes directly.
CH> Just to clarify--everyone seems in agreement that the default should be
CH> Development, so developers get a good OOBE.
CH> But that's not what the spec says it is. The default is Production
CH> (http://java.sun.com/javaee/6/docs/api/javax/faces/application/Application...).
CH> It sounds like you thought the default was Development, in which case
CH> this would simply be a spec error that can hopefully be corrected quickly.
DA> +1. (It sounds like Ed is arguing with his alter-ego. Hehehe. Just joking)
Gah! Cay is right, the spec does say the default is Production. Either
1) I'm not remembering things correctly, 2) the spec is wrong 3) I've
changed my mind since writing the spec. In any case, this discussion is
apropos.
JD> So, do we want naive users to have imperfect error messages, or a slow
JD> server?
JD> Because those are the choices...
PM> I like the idea of a container-wide setting - it fits with how
PM> people use container instances (people rarely use the same server
PM> for development and production).
PM> It would also be great to get this pushed into the EE platform - I
PM> know that this has been suggested by the 314 EG, but when I speak to
PM> the EE guys, they also seem keen on this idea...
You weren't here for the JavaOne 2008 Web Tier EG meeting. I spent a
lot of time there pushing for this in Servlet, but was ultimately
thwarted by that EG and we just kept it in JSF.
I sent a proposal to Hani Suleiman on 14 May 2008, and he advocated and
forward it to the JSR-315 EG. Thereafter a 30 message thread commenced,
spanning five months involving such lumaniaries as Joe Walker, Howard
Lewis Ship, Greg Wilkins, and Dhaji Prasanna. Surely, such great minds
as these would see the value in PROJECT_STAGE. Right? Well, the idea
got conflated with JSR-299 development types and thereafter bogged down
and was eventually dropped.
Not content with just the JSR-315 EG, I brought the idea to Sun's EE
architects and met with resistence there. I even brought it Charles
Nutter, then a Sun employee and stalwart Rails advocate, to promete the
idea.
If it's in JSF, it's in the platform. I dont think we need to take this
battle any further up the platform.
CH> Absolutely. This is something that I have requested for years. An app
CH> server is a development platform, not just a deployment platform.
Oh do I wish I could share the JSR-315 EG traffic on this topic with
you. Perhaps you should be on the servlet EG.
DA> We need to make sure this request makes it out of the mailinglist and in
DA> front of the Java EE spec leads. Is there a formal way for one spec to
DA> propose and enhancement to another spec, other than submitting a JSR? We
DA> want to propose it in such a way that they understand that all of us that
DA> support it are pushing/voting for it.
It's already been requested, 19 months ago. I suggest you get your
Servlet EG rep to advocate for it.
LB> I've been hearing "appserver", but would the "Java EE Umbrella Spec" be
LB> enough to bring this behavior to servlet containers? The last thing we want
LB> is to create another thing that appservers provide, that servlet containers
LB> do not. We still need ProjectStage to make it into the Servlet spec,
LB> explicitly, in order to bridge that gap, right? Is that an accurate
LB> assumption?
As I said, they didn't care too much for the idea.
PM> As I understand it, if the JSF EG feels that this a feature that
PM> should be pushed to another spec, it is the responsibility of the
PM> spec lead to take this up. But rest assured if this doesn't happen,
PM> then we (Red Hat) can push this through other channels such as our
PM> Java EE EG rep :-)
With all due respect: What is it with you Red Hat/JBoss guys always
assuming Ed Burns is standing in the way of your work and not doing
anything on your behalf? There is a provable pattern of behavior here
stretching back to October 2007 and I'm getting tired of it. Can you at
least *check* with me before assuming that you need to take it straight
to the highest levels? On the other hand, I have a provable pattern of
being accomodating and consensus building and continue to expect to run
this EG in that manner.
DA> ...and to add another point, I guess it would be nice if those other
DA> specs had an issue tracker like our where we could record these
DA> wishes.
I have pushed for this too. For what it's worth, I have forwarded the
JSR-315 discussion of this topic to JSR-314-EG. I cannot forward it to
JSR-314-OPEN because JSR-315 is not an open EG and I don't think they'd
like me to share their content on an open list.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
[jsr-314-open] Problem with Resource.getRequestPath() in a portlet environment
by Neil Griffin
Hello all,
This could be a bug in Mojarra 2.0.2, or it could be a problem with the spec -- I'm not sure. Someone please help me out. :-)
I'm trying to get JSF 2.0 resource stuff to work right in the PortletFaces Bridge, but the return value from Resource.getRequestPath() is not encoded...
So the question is... who's responsibility is it to call ExternalContext.encodeResourceURL()? Should that already be done by Resource.getRequestPath(), or should the calling method (like StyleSheetRenderer.encodeEnd(FacesContext, UIComponent) take care of it?
Thanks,
Neil
14 years, 11 months
[jsr-314-open] getting behind CDI
by Dan Allen
I'm going to venture out onto a limb here in hopes of leveraging the
influence of your professional recommendations. I ask that you read through
this message with an open, forward-looking mind.
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind CDI.
Now, I realize there are Spring developers and supporters on this EG. So,
before going any further, I want to clarify that the point I am making
relates specifically to the native Java EE 6 technology stack. Spring has
always been a strong alternative to the native Java EE programming model and
continues to be a great companion of JSF. The common rival that we want to
downplay is JSF managed beans.
I made the following analogy in my JSF 2 talk at JSF Summit that sets the
stage for my advice:
Facelets replaces JSP as CDI replaces JSF managed beans
(Keep in mind CDI is not a programming model, but adds additional discovery
of a platform-defined managed beans)
When JSF was created, no other facility was available for defining
contextual managed beans. As of Java EE 6, there is now a platform-wide
definition of a managed bean. With the services of CDI, there is a way to
discover, produce, scope, inject, name and override beans. All of a sudden,
the injection facility, and limited number of services in the JSF managed
bean facility looks rudimentary in comparison. And the reality is, before
CDI, most developers likely used an alternative bean container anyway
(probably Spring) to define managed beans. So the JSF managed bean facility
has been falling out of favor for a long time.
But there is a more serious problem with continuing to recommend the use of
the JSF managed bean facility. The injections do not take the scope of the
injected bean into consideration. That means, you cannot inject a
request-scoped bean into a session-scoped bean without causing the
request-scoped bean to become a session-scoped bean through attachment. This
is a very typical occurance with having managed beans in a web application.
CDI not only keeps beans in different scopes loosely coupled, it hides the
scope at the injection point. Therefore this discrepency of JSF managed
beans alone could be enough to question their viability. (If you are a
type-safety advocate, CDI has that going for it over JSF managed beans as
well. And with @ManagedBean, you still can't scope a stateful EJB, which
could cut out an unnecessary middle layer).
Having stated my advice for recommending CDI over JSF managed beans, let me
address some common misconceptions that may be stopping you from embracing
CDI.
*
Isn't CDI heavyweight?*
No. CDI is extremely efficient. All bean definitions and injection points
are calculated at startup. The scanning process is localized to archives
that contain a beans.xml file, so the number of classes to scan is
reasonable. The scanner is pluggable, so it can leverage the scanning that
may already be taking place in the application server. I would estimate that
it doesn't take any longer than looking for @ManagedBean annotations on
classes. Also, proxies are used to manage scoped injections, meaning the
overhead of interceptors is not present.
*Doesn't CDI require extra setup?*
CDI is present in any Java EE 6 application server (full or web profile), so
you can depend on it being there. JSF 2 is part of the Java EE 6 platform,
which is one of it's greatest differentiators over competing web frameworks.
(Of course, other web frameworks could use CDI too, but that is a separate
point).
*But I won't be able to use CDI in a Servlet Container, right?*
Not true. The CDI reference implementation (Weld) provides a single
extension JAR (weld-servlet.jar) that you drop into your web application
archive and you get a full CDI environment (you just don't get EJBs, but
that's to be expected).
*What about older Java EE containers?*
The Weld servlet extension JAR could be added to an application deployed to
a pre-Java EE container and likely work just fine. Let the Weld team know
what doesn't work: https://jira.jboss.org/jira/browse/WELDX
*Isn't it easier just to get started with JSF 2 along?*
Use these Maven 2 archetypes to get started with JSF 2.0 + CDI 1.0 in a
jiffy: http://tinyurl.com/weld-archetypes (soon to be available in the Maven
Central Repository)
*But we worked hard to be able to define JSF managed beans with annotations*
Yes, when we did that Java EE 6 was not around and it was a good step
forward at the time. But 6 months has gone by and Java EE 6 is here, along
with CDI. It's time to embrace the improvements.
*Isn't CDI just a Red Hat thing*?
Of course not. We should all be behind CDI. As the spec lead, Red Hat worked
very hard to define a set of services for Java EE managed beans that would
make the development of enterprise applications simpler. That's exactly the
type of effort we all put in for the JSF 2 specification. (JSF 2 was forged
by all of us collectively. CDI has the same story). So CDI is your
technology, one that you can use in Java EE 6 or even outside of it. There
is no reason to back away from it.
Perhaps a lot of the heated debating over dependency injection turned you
off, but that heated debate really made the whole platform better because EG
members, like us, talked and worked things out in the end. I really want you
guys to view CDI as just as much part of our collective stack as the EL,
JSF, JPA and other successful technologies.
Showing users how to use @ManagedBean on a class and inject other managed
beans with @ManagedProperty or an EJB with @EJB is showing developers only a
portion of the value of this platform's programming model. We want to put
our best foot forward. That's why we show composite components in
presentations and not how to create a components in Java. We show Facelets,
not JSP. We want to make it seem as easy as it can be.
Rather than recommending:
@ManagedBean
@RequestScoped
public class BlogEditor {
@ManagedProperty("#{blogDao}") BlogDao blogDao;
// getters and setters required
}
We want to show them:
@Named
@RequestScoped
public class BlogEditor {
@Inject BlogDao blogDao;
}
or even simpler, we can use the built-in @Model stereotype that combines
@Named and @RequestScoped
@Model
public class BlogEditor {
@Inject BlogDao blogDao;
}
The only consolation is that they have to add an empty beans.xml to WEB-INF.
I'm asking you to consider my request to get behind CDI. We aren't talking
about a big change here. But the consistency of the message, and the power
that they get with CDI, will make a huge impact. I encourage you to read the
Weld reference guide as it very clearly explains what CDI is all about (if
it doesn't, tell us). http://tinyurl.com/weldrefguide
(I'll conclude by saying that if this were a Spring + JSF 2 talk, I won't
start by recommending @ManagedBean as a first step).
I welcome your feedback. I'll be glad to answer questions as well.
-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
14 years, 11 months
[jsr-314-open] del.icio.us tags for JSF critical articles
by Ed Burns
In preparation for my JFokus talk I'm going through Peter Thomas's "jsf
sucks" screed and tagging the referenced articles with delicious tags.
My goal is to separate the wheat from the chaff. Here are the tags I've
been using so far
jsf-problem-reason-outdatad
Some or all of the content in a URL with this tag is no longer relevant
because subsequent releases of JSF have directly addressed the problem.
jsf-problem-reason-polemical
Some or all of the content in a URL with this tag is purely polemical,
unsubstantiated, or otherwise not trustworthy.
jsf-problem-reason-complexity
Some or all of the content in a URL with this tag complains about the
complexity of JSF but misses out on the design center of JSF providing
flexibility.
jsf-problem-reason-misunderstanding-persistence
Some or all of the content in a URL with this tag stems from a
misunderstanding of how JSF uses persistence or a database.
jsf-problem-reason-misunderstanding-security
Some or all of the content in a URL with this tag stems from a
misunderstanding of how JSF provides security
I've only made it to "Gradebook Taming JSF 1.1" in his thread. If you
have some time to do some tagging, please have at it. Feel free to
create new tags, but please follow the naming convention of starting
your tag with
jsf-problem-reason-*
jsf-problem-reason-misunderstanding-*
Once we develop a vocabulary of tags, I think we'll have a valuable
resource, turning a negative into a positive.
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
Re: [jsr-314-open] JSF 2.0 Rev A Change Log
by Ed Burns
>>>>> On Fri, 15 Jan 2010 01:40:12 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> It appears the jcp wiki is down at the moment.
It's back now. Thanks Roger and Imre for recovering from this malicious
attack. I have made these changes.
* Header information from old wiki page
* Footnote information from old wiki page
* I have copied the Jsf2ErrataScratchPad content to the new wiki site and
linked to it from the new ChangeLog.
* I have replaced the content of the old page with a link to the new home.
* I have modified the link from javaserverfaces-spec-public to point to
the new wiki page.
This brings us to where we wanted to be on 4 January. An unfortunate
delay, but as we see with Google, we'll all have to deal with this
sort of thing more and more often.
This brings us to actually doing the work for 2.0 Rev a.
Let's have an EG meeting on it. I'm composing a mail about it right
now.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
