Re: [jsr-314-open] [admin] JSFDays EG Meeting, Feb 23-25, 2010
by Ed Burns
>>>>> On Wed, 10 Feb 2010 13:24:23 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Could we make it Wednesday night, Thursday morning or Monday night instead?
DA> Or really any time within the bounds of the conference (the last session
DA> being the end of the range). There are a number of us who have flights on
DA> Thursday afternoon or plan to explore the area after the conference has
DA> wrapped up.
Thursday morning would work, but Ted Goddard is teaching an all-day
workshop on Thursday.
Wednesday evening is hard because the sessions end at 20:00. Doing an
EG meeting after a long day like that is not optimal.
I don't like Monday night because we will not be able to bring the
experience of the conference to the meeting, which is always
productive.
Give these choices, I think Wednesday night is the best option, right
after the final session.
I recall last year that the venue staff quickly escorted us out when the
official time had run out. Therefore, I'll have to talk to the
conference organizers to see about a room.
Folks, anyone who has skype and an external mic please bring it to the
meeting.
I'll report back here when I have a room and a time.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
Re: [jsr-314-open] [admin] JSFDays EG Meeting, Feb 23-25, 2010
by Ed Burns
>>>>> On Tue, 9 Feb 2010 10:49:02 -0800, Ed Burns <ed.burns(a)sun.com> said:
>>>>> On Thu, 04 Feb 2010 14:55:11 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> +1
DA> The sooner we know the day and time, the better ;)
EB> Yes, this is a very sensible idea. Let me look thru the conference
EB> schedule and see what I can come up with.
I'm thinking Thursday night shortly after the last session would be
good, but I want to confirm with the conference team that they do not
have anything planned on that night. I've sent them mail and will get
back to you all.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
[jsr-314-open] Ed Burns back on task
by Ed Burns
Hello Team,
I have been not working lately in order to attend to a family medical
issue. Thankfully, this issue now seems under control and I am
returning to a normal work schedule.
I apologize for delay in responding to issues raised here on the EG.
Also, I cannot share any details about the new JCP structure but I
expect we'll hear something soon.
Sincerely,
Ed Burns JSF spec co-lead
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
>>>>> On Tue, 19 Jan 2010 17:03:08 -0500, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Personally I don't understand the nature of the objection. In some case
AS> fine-grained (application-specific) control is desired. We have
AS> addressed this case via the context parameter. There seems to be
AS> general agreement in our EG that a system-level property would also be
AS> beneficial and in particular would improve the ease of use of this
AS> feature for development-time scenarios (ie. no need for a web.xml or
AS> JNDI config). Not sure why we need to choose one approach vs. the
AS> other. Both serve a purpose.
EB> In fact, I'm on the phone with Bill Shannon, Roberto Chinnici, Rajiv
EB> Mordani, and the Sun EE architects right now for our weekly meeting. I
EB> have requested a timeslot to bring this up (again) there. I'm glad I'm
EB> on the phone because otherwise, I might get tomatoes thrown in my face.
AS> Wow, sounds harsh. I guess I am missing why this is so
controversial.
I brought this issue to the Sun JavaEE Architecture meeting on Tuesday
19 January 2010. This meeting happens mostly weekly and is where the
Sun EE Spec leads coordinate efforts to drive JavaEE spec efforts to
completion. The technical leadership at this meeting includes Bill
Shannon, Sun Distinguised Engineer and past JavaEE spec lead, and
Roberto Chinnici JavaEE 6 spec lead.
I brought up two issues regarding ProjectStage
1. revive the drive to expose ProjectStage to lower level technologies
in EE.
2. have a System property to set the ProjectStage.
For 1), the following questions were raised:
* What specific use-cases exist for having ProjectStage at the servlet
level? If the Servlet EG reviewed the proposal and ultimately
rejected it, why bring it up again?
* What about Gavin King's "alternatives" proposal?
Pete Muir has clarified at this meeting that the "alternatives"
proposal from Gavin did not make it into CDI in such a way as to be
appropriate for our needs in the ProjectStage feature.
For 2), the following points were raised:
* There are no other System Properties in all of EE. Why do we need one
now?
* Why, specifically, does this system property need to be a part of the
portable programming model?
I voiced that it's useful in cases like mvn jetty run, or mvn tomcat
run. Bill countered that such usages are already container specific,
so it would best be addressed with a container specific configuration.
In conclusion, I think we should close this spec issue and handle the
System Property at the impl level. I have opened issue 1539 for this
case. I will send a separate email regarding this issue.
>>>>> On Tue, 19 Jan 2010 17:07:13 -0500, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com> said:
LB> We should also probably decide and state that configuration defined in
LB> web.xml will override the system property.. or visa versa. Though I think
LB> the former allows more fine grained control.
LB> I am in favor of the System property overriding web.xml. I don't think it
LB> makes sense otherwise.
I agree also.
DA> For the implementations, it might be a good idea to borrow the log message
DA> the Wicket uses when running in development mode.
DA> ********************************************************************
DA> *** WARNING: JavaServer Faces is running in DEVELOPMENT mode. ***
DA> *** ^^^^^^^^^^^ ***
DA> *** Do NOT deploy to your live server(s) without changing this. ***
DA> *** See Application#getProjectStage() for more information. ***
DA> ********************************************************************
Yes, I've added that to the issue.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
Re: [jsr-314-open] cc.parent mystery
by Ed Burns
>>>>> On Thu, 04 Feb 2010 11:00:31 -0500, David Geary <clarity.training(a)gmail.com> said:
DG> Does anyone know whether cc.parent is supposed to work for composite
DG> components?
It absolutely should work.
>>>>> On Thu, 04 Feb 2010 11:52:17 -0500, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> I can't remember what our resolution was on this issue. My concern was
AS> that #{cc.parent} should not be given any special/non-obvious meaning.
AS> #{cc} resolves to the composite component instance, which is a
AS> UIComponent. Dereferencing the "parent" property on a UIComponent,
AS> whether accessed via #{cc.parent}, "#{component.parent} or any other
AS> expression that resolves to a UIComponent, should do the
AS> obvious/consistent thing and actually call UIComponent.getParent().
This is correct. But you must bear in mind that it is the parent of the
*current* composite component. This gets complicated when nesting
composite components. Just remember that it's the parent relative to
the <cc:implementation> section of the xhtml page in which the #{cc}
expression appears.
AS> Okay, this seems like an oversight to me. I have logged the following
AS> issue to request that we remove this from the spec:
AS> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=741
AS> Any objections to making this change in the MR?
I'm not sure about removing this statement. The section you quote is
for the special composite component ELResolver, the thing that makes the
#{cc.attrs} magic work. If we remove this statement, then the
following, currently supported, code will cease to work.
I have removed the corresponding code in my local workarea and am
currently re-running the automated tests.
Index: jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java
===================================================================
--- jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java (revision 8307)
+++ jsf-ri/src/com/sun/faces/el/CompositeComponentAttributesELResolver.java (working copy)
-131,23 +131,6 @@
return getEvalMapFor(c, ctx);
}
- if (COMPOSITE_COMPONENT_PARENT_NAME.equals(propertyName)) {
- UIComponent c = (UIComponent) base;
- context.setPropertyResolved(true);
- FacesContext ctx = (FacesContext)
- context.getContext(FacesContext.class);
- CompositeComponentStackManager m =
- CompositeComponentStackManager.getManager(ctx);
- UIComponent ccp = m.getParentCompositeComponent(TreeCreation,
- ctx,
- c);
- if (ccp == null) {
- ccp = m.getParentCompositeComponent(Evaluation,
- ctx,
- c);
- }
- return ccp;
- }
}
return null;
I will share the scenarios in which the tests fail and we can discuss if
they are valid or not. However, I feel that since these scenarios work
in the current spec, it is unacceptable simply to make them not work any
more.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 10 months
[jsr-314-open] cc.parent mystery
by Cay Horstmann
I can't get cc.parent to work, and I stared at it for long enough that I
am pretty convinced that it is a bug.
(https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1529)
What I am wondering in this forum is whether cc.parent is actually
intended to be supported. There was some use case in the olden days,
when cc was dynamically scoped, but around September 15, Andy Schwarz
convinced you all that it should be statically scoped. For all I know,
that took away the raison d'être for cc.parent.
Or is there another use case? I only found one other example, David
Geary's developerWorks article
(http://www.ibm.com/developerworks/java/library/j-jsf2fu2/index.html).
He has a map component inside a place component that retrieves the
location from the parent. I am not even sure that's good practice. It
doesn't make the map component reusable, but instead couples it with the
parent.
Thanks,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
14 years, 10 months
[jsr-314-open] JSR-314-OPEN archives and migration status
by Dan Allen
Max (and the JCP PMO),
Happy belated New Year! I'd like to pick up where we left of at the end of
last year with the JSR-314 mailinglist issues. I'm hopeful that we can make
swift progress now that we are well into 2010. I've retained our last
communication at the bottom of this message for reference.
The most pressing concern of the JSR-314 EG is that we get the archives for
the JSR-314-OPEN mailinglist restored. The archives stopped working in June
2009 and we have no archived messages since then:
http://archives.java.sun.com/cgi-bin/wa?A0=JSR-314-OPEN
This is *hindering* progress on the JSR because we cannot find or link to
unresolved discussions.
While on the one hand we have expressed an interest in migrating our
mailinglist over the the jcp.org software, we are in *desperate* need of a
short term fix that allows the EG and the community to have access to the
existing archives online. There is growing frustration amongst the EG over
the missing archives. It's also putting me in a bad position since I am not
upholding my promise to the group to find a solution. Even more troubling,
we are also breaking our promise of openness to the community.
Before anything else happens, we absolutely must find a way to get that
problem solved.
Looking ahead, here are the other points that we agreed on:
1. Import all JSR-314-OPEN messages into jsr-314-observers
2. Give the EG an opportunity to review the results of the import to ensure
that the results are acceptable
3. Make the jsr-314-observers archives (stored in the online board) open to
the public for read access
4. Clarify that the jsr-314-observers will function as a mailinglist
5. ...prepare for official migration
I'll also restate some lower-priority changes that I would like to see to
the jcp.org site:
1. Cut down (or otherwise document) the delay between the time a message is
sent to jsr-314-public(a)jcp.org to the time it appears in the board
2. Make the full list of public-facing boards available when the user first
visits http://wiki.jcp.org/boards/
3. Get rid of the wiki syntax in the boards as it will result in archives
messages being displayed improperly
4. Dark the text on jcp.org to at least #333333 (about 80% black). Most news
sites adhere to this convention for the vision impaired.
Please provide an update as soon as you can.
Thanks,
Dan, on behalf of the JSR-314 EG
On Wed, Dec 16, 2009 at 12:27 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> Max (and the JCP PMO),
>
> I want to start by saying that we appreciate your thorough response and
> your willingness to address our requests. I'm confident that our work
> together with have a positive and lasting influence on the JCP community.
>
> I've provided feedback and clarification inline.
>
> On Tue, Dec 15, 2009 at 8:07 PM, Max Lanfranconi <Max.Lanfranconi(a)sun.com>wrote:
>
>> Please be aware that making the jsr-314-observers board visible to
>> the public
>> is a customization of the code that needs to be implemented.
>>
>
> It would help us if we understood why it is necessary to customize the
> off-the-shelf software to make the observers boards public. I'm not
> questioning the need, but rather trying to understand why the observers
> boards are different than the public boards, which are public facing
> already. If we understood better what the problem is, I think we would have
> an easier time remaining patient.
>
>
>>
>> Also, as discussed with Roger, we are waiting on a couple of really
>> critical
>> fixes to the code that we are using for the boards that prevent us to
>> release the
>> features you are looking forward to.
>> Such fixes are being implemented outside Sun, and, as much as we would
>> like
>> to have them now, they are going to take some time to be developed,
>> tested and implemented.
>>
>
> Understood.
>
>
>>
>> So, here is a summary of what we will do:
>>
>> We will import the current subscribers from jsr-314-open into
>> jsr-314-observers.
>>
>
> Great!
>
>
>>
>> The mailing list jsr-314-open will go away.
>>
>
>> Subscribers to jsr-314-observers will be able to both read and write
>> to the board/alias.
>>
>
> This doesn't add any restrictions to what we currently have with
> jsr-314-open, so we are willing to migrate immediately based on the
> information you have provided. (Note that we are still seeking public read
> access, but that was never possible with jsr-314-open, so by migrating we
> can pursue this need)
>
>
>> Other users who are NOT subscribed will be able to read the
>>
>> jsr-314-observers archives in the discussion board
>>
>
> I'm assuming you mean "not subscribed, but signed in jcp.org members". I
> just want to clarify the current state.
>
>
>>
>> Users may request to become subscribers by filling out the existing
>> form to join the jsr-314-observers board; Ed and/or Roger would then be
>> able to review the nomination and approve/decline the request using the
>> existing form.
>>
>
> That's fine in the short term. In the long run, I don't see why we need a
> human task in the subscription process. That will burden Ed and Roger and
> slow down the subscription. I'd like to request that the process be
> completely automated.
>
>
>>
>> Note: the list of boards on jcp.org is browsable by logged-in users, but
>> there are publicly-readable boards that anyone can read, though they
>> can't see the navigation if they don't log in. So, a question about read
>> permissions: do you want the list readable by registered users of
>> jcp.org, who will have handy navigation to find the jsr-314-observers
>> board, or do you want anyone with an internet connection to be able to
>> read it, with the idea that you would send out a direct link to the world?
>>
>
> First of all, one of my major complaints with jcp.org right now is that
> the list of boards is not visible at first view. I don't understand why the
> complete list can't be displayed (obviously, the jsr-xxx-eg boards can be
> hidden). When I first arrived at the boards page, I thought that there were
> only a handful of boards. Later I realized there are a lot more, just
> hidden.
>
> So yes, we want the complete board list to be visible. There is no reason
> to hide the names of any of the boards (with the exception of the jsr-xxx-eg
> boards).
>
> We also want a search engine, such as Google, to be able to navigate to the
> threads in the jsr-314-observers forum so that they can be indexed. That
> means they should be visible by an anonymous visitor.
>
>
>> Once again, just so that there will be no misunderstanding, I am restating
>> the current status next to each of your requests marking it with ****:
>>
> 1) Make jsr-xxx-observers readable by the world and writable by anyone
>> w/ post access to jsr-314-open
>> ****Waiting of third party developers****
>>
>
> Your saying we can't even migrate without critical fixes? We really want to
> migrate as soon as possible, so anything that can be done to speed this up
> would be great.
>
>
>> 2) Import the archives of jsr-314-open into jsr-314-observers
>>
>> ****Waiting on third party developers****
>>
>
> Again, I'm wondering which fixes we need to at least do the migration.
>
> Just to clarify this point, we also need to jsr-314-open archives (the
> messages dating back to March 09) imported into jsr-314-observers. The EG
> would like to review the result of the import (i.e., how the messages appear
> in the board) before we commit to switching over to the new mailinglist.
>
>
>> 3) Messages sent to jsr-314-public(a)jcp.org
>>
>> <mailto:jsr-314-public@jcp.org> are still not ending up on the forum
>> unless the sender is on the JSR-314 EG; anyone should be allowed to post
>> through that email address
>> ****The problem is somewhat different of what it seems:
>> registered users ARE able to use the jsr-314-public board, but that it
>> takes a
>> while after registration for those permission to propogate to all systems
>> (similar
>> to what happens about making Expert Group edits). This will be fixed in
>> the
>> future but it is basically a "feature, not a bug"TM for now ****
>>
>
> Okay, as long as we can document how long it will take as an upper bound,
> at least the community will know that they have to be patient. Is it 1 hour?
> 12 hours? 24 hours? 48 hours? You should strongly consider documenting this
> on jcp.org in a prominent place, because otherwise the community is going
> to assume the software is broken. I can live with a propagation delay, as
> long as we can set the expectation.
>
>
>>
>> Also, while you are reading this, is there anyway to reverse the order
>> that posts appear on the forum? Currently, the new posts in a thread
>> show up first and the oldest last. That is totally upside down from how
>> 95% of the forums on the web work.
>> ****We are discussing this with the forum's developers.
>> It should be doable but has much lower priority compared with everything
>> else they are working on right now so it might take quite some time
>> before this
>> will be addressed. ****
>>
>
> Understood.
>
> One other thing I noticed recently (sorry to keep adding things, but this
> is really important to get this right). I'm strongly against the wiki syntax
> in the boards. When we import our messages, it is going to produce all kinds
> of strange links and other markup that we don't want. When people post to a
> mailinglist, they expect it to be interpreted as plain text. We absolutely
> need to get rid of the wiki syntax in the boards.
>
>
>
>
>>
>> Rest assured that your needs are very high on our priority list. As soon
>> as we
>> receive the fixes from the third party developers we will test them,
>> deploy them
>> and let you know.
>>
>
> A sincere thanks.
>
>
>>
>> Unfortunately we are not able to provide a firm date yet, but we will let
>> you
>> know as soon as possible.
>>
>
> Please don't hesitate to send an update, even if it is brief.
>
>
>>
>> Please let me know if there is any further concern that I did not cover.
>>
>
> Another very quick, yet important change request. The text on jcp.org is
> very, very difficult to read, especially for people that don't have strong
> eyesight (I am lucky in that regard, but I must keep the general population
> in mind). The problem is that the text is too light! It needs to be darked
> to at least #333333 (about 80% black). Most news sites adhere to this
> convention for the vision impaired.
>
> Thanks again. I'm very glad to have established a good working relationship
> with your team. Our streamlined collaboration is what's best for the JCP
> community!
>
> -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
>
--
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, 10 months
