Re: [jsr-314-open] mailinglist: looking for immediate action
by Ed Burns
>>>>> On Fri, 13 Nov 2009 16:13:46 -0500, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com> said:
LB> "Maybe JBoss doesn't want an exclusively private list as one of the list
LB> options, but I know Sun does. I'll leave it for other EG members to
LB> respond"
LB> Where does this leave people like me?
Do you have a gigantic revenue stream that is impacted by decisions
regarding your company's interaction with JCP? What I'm talking about
here is stuff that lawyers tend to be interested in.
Here's the guideline we've been using with jsr-314-open since it
started.
When you sit down to write an email to the EG, write to jsr-314-open
unless any of the following are true:
1. your employer's lawyers are likely to be interested in what you say
2. you want to share only with official EG members. This might be when
you want to share product plans that are not yet public knowledge.
If any of the above are true, write to jsr-314-eg.
We need to have this private option when writing to the list.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 5 months
Re: [jsr-314-open] Fwd: [seam-dev] Interesting feedback on error reports
by Ed Burns
>>>>> On Fri, 13 Nov 2009 11:52:28 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> I think this article points out two important things:
DA> 1. JSF 2 is improving with regard to reporting what the problem is (line
DA> number and message)
DA> 2. We can take this as an opportunity to figure out how to communicate the
DA> problem better to the user
DA> When people criticize JSF or Java EE in this way, we need to see it as a
DA> good use case for how to improve the experience.
DA> Of course, tooling vendors can run with this too ;)
DA> -Dan
DA> p.s. Btw, in a future Java EE I would love to see a type safe EL (or at
DA> least a smarter EL that can help tools find problems easier).
For the record, there is a lot of API for this in the EL already. For
example, ELResolver.getType(), getFeatureDescriptors(), etc.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 5 months
[jsr-314-open] Fwd: Allow multiple taglib.xml files for the same namespace
by Lincoln Baxter, III
Forwarded from dev list.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
---------- Forwarded message ----------
From: "Matthias Berndt" <matthias.berndt(a)systemtrap.net>
Date: Nov 13, 2009 10:01 AM
Subject: [jsr-314-open] Allow multiple taglib.xml files for the same namespace
To: <dev(a)javaserverfaces.dev.java.net>
Hello,
first I'd like to explain my intention. The scenario is writing multiple
JSF components being bundled in more than one java archive. Each java
archive has its own taglib.xml descriptor so you can use them
separately. These components belong to the same project or organisation
and should be published within the same namespace. This isn't possible
with facelets at the moment and is a known issue to facelets. See:
https://facelets.dev.java.net/issues/show_bug.cgi?id=118
To support this scenario I'm aware of 3 possible solutions.
The first one is merging the needed java archives especially the
taglib.xml. I think this one is bad because the separation between the
component projects is destroyed.
The second one is merging the taglib definitions while being processed
by FaceletTaglibConfigProcessor#processTagLibrary(). In line 308 a new
TagLibraryImpl is created for every facelet-taglib element. This can be
extended to use an already existing TagLibraryImpl for a specific
namespace. This extension requires about 10 to 15 lines of code. As a
result there will be one TagLibraryImpl for multiple facelet-taglib
elements with the same namespace.
The third one, my preferd one, is using the existing
CompositeTagLibrary. As a result and in contrast to the second method
each facelet-taglib element will be represented by a TagLibraryImpl and
combined by CompositeTagLibrary. This requires only a minor change. In
FaceletTaglibConfigProcessor#processTagLibrary() in line 318 the created
TagLibraryImpl is added to the compiler. Compiler#addTagLibrary() tests
if the given library is already known to the compiler. Subsequently this
is done by using equals() and hashCode() in AbstractTagLibrary. At the
moment hashCode() is implemented to use nothing except the namespace. If
there are multiple TagLibraryImpl with the same namespace only one will
be included in the compiler. The rest is thrown away. By extending
hashCode() to use this.factories and this.functions in the calculation
multiple TagLibraryImpl with different tags etc. can coexist. IMO it
makes sense by reason taglibs are not equal only because they define the
same namespace.
CompositeTagLibrary handles this very well so no other changes are
required.
I attached a patch to modify AbstractTagLibrary#hashCode(). The
algorithm is base on Joshua Bloch's Effective Java. The existing test
cases are not harmed and apologize my self not writing a specific test
case. I don't like to call it a patch because it's so stupidly simple,
but I'd be glad if something like it could be shipped with JSF2 to
provide this feature.
kind regards,
Matthias Berndt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe(a)javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help(a)javaserverfaces.dev.java.net
14 years, 5 months
Re: [jsr-314-open] mailinglist: looking for immediate action
by Ed Burns
>>>>> On Mon, 09 Nov 2009 16:06:33 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Pete, Andy, Lincoln and I would really like to get the following two issues
DA> ironed out before Pete, Andy and I go in front of the audience at Devoxx to
DA> give our "JSF 2 and beyond: Keeping progress" coming talk:
DA> #1. Fix the broken JSR-314-OPEN mailinglist archives: **
DA> http://archives.java.sun.com/jsr-314-open.html
DA> #2. Have a community maillinst or forum.
DA> We are willing to say that the JCP.org boards are the community forum, if we
DA> can get a statement from the JCP that the e-mail gateway will eventually
DA> work (http://wiki.jcp.org/boards/index.php?b=958)
DA> The main emphasis is this talk is community involvement. It's pretty useless
DA> for us to stand up there and have zero options for the community to get
DA> involved. jsr314-comments(a)jcp.org is not a solution.
DA> I'm willing to get on a conference call if necessary to get some
DA> action.
Hello Dan. As I have mentioned several times to you before, the JCP and
Sun are under duress due to ongoing well reported regulatory concerns.
This certainly does not excuse their apparent unresponsiveness but it
can explain it.
I recommend you do this.
1. Call Max Lanfranconi of the JCP Program office and identify yourself
as the JBoss EG rep for JSR-314.
2. Mention that your spec leads have tried to resolve this issue but
have thus far not been accomodated.
3. Mention that you have the option to escalate to your EC
representative on this issue.
Dan, I understand your position and I hope you understand mine. Do you
feel that Roger and I have done enough to resolve this? If not what
other actions can we take to ensure your satisfaction?
Ed
14 years, 5 months
[jsr-314-open] Errata: contentType and encoding on f:view
by Jim Driscoll
Just an FYI:
The f:view tag in Facelets 1.1 had the ability to set contentType and
encoding of responses via two named attributes.
The 2.0 RI inherited that capability, but we neglected to add it to the
faclets tld.
Unless there are any objections, the RI team would like to treat this as
a specification bug, adding these attributes to the TLD, and documenting
this in the MR. This behavior is already supported in the released RI.
Please let me know if you have any concerns.
Jim
14 years, 5 months
[jsr-314-open] JSF logo
by Dan Allen
JSF is nearly a decade old and still has no recognizable logo. While there
are plenty of logos floating around for the different implementations and
component libraries, there's no face for JSF itself. I've frequently come
across this gap when putting together presentations or websites that feature
JSF.
Thus, I pose the following two questions to the EG:
1. Do others agree that we should have a logo to represent JSF the
framework?
2. Do you think we should host a contest for people to submit a logo? The
alternative would be to get an EG member (JBoss, Oracle, Sun, an individual)
to submit a candidate.
Why a logo for JSF? JSF is unique in that it competes against other web
frameworks that are not part of the Java EE platform. We need someway to
represent the spec when standing JSF up against Wicket, Tapestry, Struts,
etc. We can't put the Mojarra or MyFaces logos in there because that's not
the true identity of JSF.
Plus, the logo will be central to our effort to put together a launch page
for JSF, which I'll mention in a later e-mail.
-Dan
p.s. Hopefully we start a trend of specs including logos, even the platform
itself, but that is a topic for another conversation.
--
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, 5 months
[jsr-314-open] UIViewRoot afterPhase
by Dan Allen
Sorry, I let this one site for a while. From the jsr314-comments.org inbox.
-Dan
---------- Forwarded message ----------
From: Jakob Korherr <jakob.korherr(a)gmail.com>
Date: Tue, Oct 27, 2009 at 4:07 PM
Subject: [jsr-314-open] [jsf 2.0] UIViewRoot afterPhase
To: jsr-314-comments(a)jcp.org
Cc: MyFaces Development <dev(a)myfaces.apache.org>
Hi,
While working on MYFACES-2374 "UIViewRoot.getBeforePhaseListener() and
UIViewRoot.getAfterPhaseListener() could be called on PhaseId.RESTORE_VIEW",
I found out that the mojarra javadoc was changed, so that only
UIViewRoot.getAfterPhaseListener should be called on RESTORE_VIEW.
Mojarra javadoc on UIViewRoot.setAfterPhaseListener says: "Allow an
arbitrary method to be called for the "afterPhase" event as the UIViewRoot
runs through its lifecycle. This method will be called for all phases
including PhaseId.RESTORE_VIEW."
Just a week ago UIViewRoot.setBeforePhaseListener also said "...for all
phases including PhaseId.RESTORE_VIEW.", now it says "...except
PhaseId.RESTORE_VIEW."
It is clear to me, why this was changed, because you have to restore the
view before you can access the attributes, not really difficult to see.
But why should we still call UIViewRoot.getAfterPhaseListener on
RESTORE_VIEW?
Spec says that we should only call an afterPhase method, if the relating
beforePhase method returned without an Exception. Of course, these
attributes of UIViewRoot are different to its "normal" PhaseListeners, but I
think that this behaviour is kind of strange.
Why don't we change it back to the way it was in jsf 1.2? So that
UIViewRoot.getBeforePhaseListener AND UIViewRoot.getAfterPhaseListener are
called for all phases except RESTORE_VIEW.
Also: Mojarra 2.0.1 does not call UIViewRoot.setAfterPhaseListener on
RESTORE_VIEW.
Thanks in advance.
Regards
Jakob Korherr
14 years, 6 months
