Questions about the schedule component
I am interested in using and submitting patches for the Schedule component. I have a few question: 1) Does this component have a lot of community support or interest? 2) Is their a better component with similar features? 3) What is the process to move a component out of the sandbox and into Tomahawk? 4) Is their any design plan or feature wish list for the schedule component? I have checked the Help Wanted page, the component's wiki page, and JIRA to no avail. 5) Is this list the best place to get permission to add features to the component? 6) Is the best way to submit patches is via JIRA? Paul Spencer
Re: [jira] Commented: (MYFACES-888) Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag.
Jurgen, Where does this fit on your schedule? I would like to create a patch based the changes posted in JIRA if you are not able to get to it. Paul Spencer Jurgen Lust (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-888?page=comments#action_12358857 ] Jurgen Lust commented on MYFACES-888: - I agree the css class should be an optional parameter of the component tag. In fact i will get to it as soon as I can. Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag. - Key: MYFACES-888 URL: http://issues.apache.org/jira/browse/MYFACES-888 Project: MyFaces Type: Improvement Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer CSS Class for the Schedule Component are hardcoded. I sugget they should be optional parameters to the tag. Currently CSS Class -- Entire Entryentry title fieldtitle subtitle field subtitle I am sure their are may other CSS Classes that are hardcoded that should be added to this list.
Question about adding CSS Style and Class configuration to the schedule component
I am looking to add CSS Style and Class configuration to the schedule component, (MYFACES-888 http://issues.apache.org/jira/browse/MYFACES-888 ). My question is what is the best approach to pass this information from the JSP to the component via the tag, s:schedule.../. Considerations: 1) Although I an not finished determining exactly how many pairs of Style and Class configurations need to be passed, I expect their are around 5 pair. 2) None of the configuration will be required. Thus the title Class can be configured, but the title Style may not be configured. My initial though is to just add optional attributes to the tag. My concern is, at what point does the attribute list become to long. Paul Spencer
Re: [jira] Commented: (MYFACES-888) Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag.
Jurgen,, The more I looking into this, the more I need to understand. So, do not wait for me to provide a patch any time soon. I would like to know where this fits into your schedule. Paul Spencer Paul Spencer wrote: Jurgen, Where does this fit on your schedule? I would like to create a patch based the changes posted in JIRA if you are not able to get to it. Paul Spencer Jurgen Lust (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-888?page=comments#action_12358857 ] Jurgen Lust commented on MYFACES-888: - I agree the css class should be an optional parameter of the component tag. In fact i will get to it as soon as I can. Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag. - Key: MYFACES-888 URL: http://issues.apache.org/jira/browse/MYFACES-888 Project: MyFaces Type: Improvement Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer CSS Class for the Schedule Component are hardcoded. I sugget they should be optional parameters to the tag. Currently CSS Class -- Entire Entryentry title fieldtitle subtitle field subtitle I am sure their are may other CSS Classes that are hardcoded that should be added to this list.
Re: Code generation documentation?
Mike, o My question was prompted by an attempt to apply a patch for the Schedule component. I noticed comments in the code from a code generator. o I assume that any patches that add code should do so outside of the generated sections. o I assume that patches to generated code may become unpatched once the generator is fixed. o It is unlikely that I will have time to work on the code generator. o The correct URL is https://svn.apache.org/repos/asf/myfaces/legacy/tags/before_svn_reorg/src/codegen/org/apache/myfaces/codegen/ Paul Spencer Mike Kienenberger wrote: Code generation isn't currently used. Some of us have talked about bringing it back, but we haven't gotten around to doing so yet. Right now you have to grab it from https://svn.apache.org/repos/asf/myfaces/impl/tags/before_svn_reorg (I think that's the correct tag.) I'm sure a bunch of us would appreciate it if you provided patches for gettings this back into the current svn :-) On 12/13/05, Paul Spencer [EMAIL PROTECTED] wrote: Where can I find documentation on the code generation used by MyFaces? As an example, tomahawk/src/java/org/apache/myfaces/custom/calendar/HtmlInputCalendar.java contains generated code. The file HtmlInputCalendar.xml appears to be used by the code generator. What else is being generated by HtmlInputCalendar.xml? Paul Spencer
Upgrading MyFaces dependency in a project's Maven2 pom.xml?
I am currently using MyFaces 1.1.1 in a project that is built via Maven 2.x. Below are the dependency entries in pom.xml related to MyFaces. How do they need to change for 1.1.2? dependency groupIdmyfaces/groupId artifactIdmyfaces-impl/artifactId version1.1.1/version /dependency dependency groupIdmyfaces/groupId artifactIdtomahawk/artifactId version1.1.1/version /dependency In general I rely on Maven to download any dependencies need for a specific application, thus I may not download the distribution. The Upgrading and Getting Started sections of the documentation should address Maven dependencies. I would also like to thank the MyFaces developers for their work. Paul Spencer
Re: [Important] Ugly bug in core pom.xml for 1.1.2 and 1.1.3
For what it is worth, I have been using MyFaces 1.1.1 inside a web application built via Maven 2.0.4. To upgrade to 1.1.3-SNAPSHOT of MyFaces and Tomahawk I made the following changes to pom.xml 1) Removed the MyFaces 1.1.1 dependencies dependency groupIdmyfaces/groupId artifactIdmyfaces-impl/artifactId version1.1.1/version /dependency dependency groupIdmyfaces/groupId artifactIdtomahawk/artifactId version1.1.1/version /dependency 2) Added MyFaces 1.1.3-SNAPSHOT dependencies. (Notice myfaces-api is a new dependency) dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-api/artifactId version1.1.3-SNAPSHOT/version /dependency dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.1.3-SNAPSHOT/version /dependency dependency groupIdorg.apache.myfaces.tomahawk/groupId artifactIdtomahawk/artifactId version1.1.3-SNAPSHOT/version /dependency 3) Added the Apache snapshot repository. repositories repository releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots idapache-maven-snapshots/id urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository /repositories The web application built cleanly and ran as expected. Paul Spencer Manfred Geiler wrote: On 4/24/06, Sean Schofield [EMAIL PROTECTED] wrote: I think this is the wrong way to fix it. I'm not sure what changing the releases enabled to false does (maybe someone can answer that) but here's the way I see the problem. This IS the right way. Believe me. The snapshot element without content is a syntax error - have a look at maven docs! What we try to tell Maven is: Use the url http://cvs.apache.org/maven-snapshot-repository to download snapshots, but do not use this url to seek release artifacts. The correct syntax is to explicitly enable this repository for snapshots but disable it for releases. Actually when you build a custom project with a myfaces-impl-1.1.2dependency Maven 2.0.4 tries to download the myfaces-master-1.0.1 release(!) from http://cvs.apache.org/maven-snapshot-repository, which is subject to fail of course. Try it out! This is the only build problem with the 1.1.2 core release. There is no issue regarding myfaces-shared. 1.1.2 branch does not build b/c the myfaces-shared stuff is not in ibiblio. Its ok that these shared artifacts are not in ibiblio (that's what we wanted), they just need to be available in our own MyFaces repository. (See my earlier post) I think you got me wrong here. I did not try to build the 1.1.2 branch. What I meant: when you build a project that DEPENDS on 1.1.2 core, then you run into problems. In the short run to build core-1.1.2 and core-1.1.3 you just need to check out the appropriate shared and maven branches and build on your local machine. For all releases going forward I think we update the master pom stuff and add a reference to a new myfaces repo which contains the shared artifacts. That's actually why I'm holding off on the vote for the 1.1.3 core b/c we really need this going forward. I'm going to revert your change for now. Please leave my changes. They are ok. We should also try to fix the releases myfaces-core-project-1.1.2.pom ASAP. Manfred On 4/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: The pom.xml of the myfaces-core-project artifact contains the following errornous lines: repositories repository snapshots / idapache-maven-snapshots/id urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository /repositories At least for the newest Maven 2.0.4 these lines make builds fail because Maven tries to download the released(!) myfaces-master from the apache snapshot(!) repo. Correct syntax would be: repositories repository releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots idapache-maven-snapshots/id urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository /repositories Just corrected this on the 1.1.3 branch. Sean, could you please build a new RC? What about 1.1.2? Is it possible to replace the already released myfaces-core-project-1.1.2.pom? Shall I correct the 1.1.2 core branch? Note: Without that correction nobody is able to build Maven projects that depend on myfaces-api-1.1.2 or myfaces-impl-1.1.2 ! Manfred
Re: [important] 1.5 in core
What is the address of the myfaces repo? What is the version number in the repo? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield [EMAIL PROTECTED] wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! This is holding up the release because of a method not found error. I am running low on time right now so I would appreciate it if others can look into this also. Which package? Shared or core? I agree, this should be fixed ASAP. I will try to find time tomorrow but its better if someone else fix first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the last bug before release fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [important] 1.5 in core
What is the address of the myfaces repo? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield [EMAIL PROTECTED] wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! This is holding up the release because of a method not found error. I am running low on time right now so I would appreciate it if others can look into this also. Which package? Shared or core? I agree, this should be fixed ASAP. I will try to find time tomorrow but its better if someone else fix first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the last bug before release fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [important] 1.5 in core
Dennis, Based on Sean's earlier post, you are correct Some how this got posted twice, probably my fault. Thank you Paul Spencer Dennis Byrne wrote: I am pretty sure you are looking for myfaces-impl-1.1.3.jar under http://myfaces.zones.apache.org/dist/maven-repository/org/apache/myfaces/core/myfaces-impl/1.1.3/ The api jar is at an equivalent location. Sean, this is right? Thanks for your interest Paul. Dennis Byrne -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Monday, May 1, 2006 02:06 PM To: 'MyFaces Development' Subject: Re: [important] 1.5 in core What is the address of the myfaces repo? I do not see a version, or snapshot, dated today in http://cvs.apache.org/maven-snapshot-repository/org/apache/myfaces/core/. Paul Spencer Sean Schofield wrote: FYI I put a new RC up on the myfaces repo. TCK testing should begin shortly. Lets get this released by the end of the week! Sean On 5/1/06, Sean Schofield [EMAIL PROTECTED] wrote: Yes we should install JDK 1.4 on the zone which is used for nightly builds and release candidates. I think that is the best long term solution. Sean On 5/1/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! This is holding up the release because of a method not found error. I am running low on time right now so I would appreciate it if others can look into this also. Which package? Shared or core? I agree, this should be fixed ASAP. I will try to find time tomorrow but its better if someone else fix first so I can use my time to rebuild the release candidate. I guess I fixed it, though, not testet but it should do its job. It looks like I become the last bug before release fixer ;-) However, the best will be to use a 1.4 JDK to build the release - or at least use the JDK 1.4 libraries (this will be possible by adding them to the bootclasspath I think - I've never done it myself, there are documentations how to do in internet), that way such incompatibilites will come up early. Ciao, Mario
Re: [jira] Commented: (MYFACES-1296) NullpointerException in JspStateManager
Mario, The problem sounds similar to a problem I described in earlier post, titled h:commandLink target=detailWindow sometimes displays an exception instead of the expected page (core 1.1.3 from myfaces-repo) http://mail-archive.com/dev%40myfaces.apache.org/msg13870.html If it is the same problem, then it exist in the 1.1.3 release candidate posted in the myfaces repo. I am using the 1.1.3 jars in the myfaces repository. http://myfaces.zones.apache.org/dist/maven-repository Paul Spencer Mario Ivankovits (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1296?page=comments#action_12377372 ] Mario Ivankovits commented on MYFACES-1296: --- This should be fixed in myfaces-core head (per 28.4.2006), could you please check it. With the lowered NUMBER_OF_VIEWS_IN_SESSION for sure ;-) At least it is a fix, though, I dont know if it is the correct one. (SVN revision: r398003 r398009) NullpointerException in JspStateManager --- Key: MYFACES-1296 URL: http://issues.apache.org/jira/browse/MYFACES-1296 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.2 Environment: JBoss 4.0.1, Tomcat 5 Reporter: Stephan Sichhart Priority: Critical Fix For: 1.1.3-SNAPSHOT, 1.1.4-SNAPSHOT Hi, I'm having trouble using the 1.1.2 release and latest nightly build. If I do some massive clicking with the sample application, I get after 30-50 clicks an NPE within the JspStateManager. In my own app. I get this error after 10 page request. This problem only occurs, if I use server state saving. I figured out, that if I increase the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION parameter to a large (500) value, the error does not occur or does not occur yet :-) I can reproduce this error every time. There is an resolved issue on jira (http://issues.apache.org/jira/browse/MYFACES-1278), which explains exactly my problem. This issue was closed. After discussing the problem with Juergen Melzer, he confirmed that the problem is still there. regards, Stephan java.lang.NullPointerException: null values not allowed at org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) at org.apache.myfaces.application.jsp.JspStateManagerImpl$SerializedViewCollection.add(JspStateManagerImpl.java:717) at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedViewInServletSession(JspStateManagerImpl.java:493) at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:332) at org.apache.myfaces.taglib.core.ViewTag.doAfterBody(ViewTag.java:122) at org.apache.jsp.home_jsp._jspx_meth_f_view_0(home_jsp.java:153) at org.apache.jsp.home_jsp._jspService(home_jsp.java:102) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:416) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:367) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter
Continuum Build error related to Myfaces Core 1.1.4-SNAPSHOT
Below is a message from the Continuum server, http://myfaces.zones.apache.org:8080/continuum. Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/repos/asf/myfaces/core/trunk' svn: PROPFIND of '/repos/asf/myfaces/core/trunk': could not connect to server (http://svn.apache.org) --- The problem may no be limited to just this project. Paul Spencer
myfaces.zones.apache.org is down
The site zones.myfaces.apache.org is responding with empty pages. This includes the maven repository. Paul Spencer
Re: myfaces.zones.apache.org is down
Thanks for restarting it. Paul Spencer Sean Schofield wrote: Thanks for the heads up. The zone was bounced and apparently the autostart of the service had a few issues. Repo should be back online now. Sean On 5/15/06, Paul Spencer [EMAIL PROTECTED] wrote: The site zones.myfaces.apache.org is responding with empty pages. This includes the maven repository. Paul Spencer
Re: Problem with nightly build and Maven
Sean, Per the maven list, and I have also confirmed it, the server http://snapshots.maven.codehaus.org/ is having problems. The builds are failing because the dependency doxia-1.0-alpha-8.pom can not be downloaded. Paul Spencer Sean Schofield wrote: The nightly build seems to be choking[1]. Can one of our Maven experts look at this and help us out? Sean [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuildbuildId=1433id=50
ClassCastException when setting timeZone attribute in f:convertDataTime using EL
I am setting the time zone attribute for the tag f:convertDataTime from a
backing bean. This causes the following
ClassCastException in core 1.1.3
Caused by: java.lang.ClassCastException
at
org.apache.myfaces.shared_impl.taglib.core.ConvertDateTimeTagBase.setConverterTimeZone(ConvertDateTimeTagBase.java:165)
at
org.apache.myfaces.shared_impl.taglib.core.ConvertDateTimeTagBase.createConverter(ConvertDateTimeTagBase.java:85)
at javax.faces.webapp.ConverterTag.doStartTag(ConverterTag.java:63)
If I hard code the time zone in the attribute, i.e. timeZone=GMT-05:00, no
exception is thrown.
** JSP that caused ClassCastException
h:outputText value=#{rowVar.date}
f:convertDateTime type=time timeZone=#{phrQueryManager.timeZone}/
/h:outputText
** JSP that works
h:outputText value=#{rowVar.date}
f:convertDateTime type=time timeZone=GMT-05:00/
/h:outputText
Is this a bug I need to report in JIRA?
Paul Spencer
Re: ClassCastException when setting timeZone attribute in f:convertDataTime using EL
The type is string
public String getTimeZone()
{
return GMT-05:00;
}
Paul Spencer
Matthias Wessendorf wrote:
f:convertDateTime type=time
timeZone=#{phrQueryManager.timeZone}/
Is this type of TimeZone ?
*snip*
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
converter.setTimeZone((TimeZone)vb.getValue(facesContext));
}
*snip*
Regards,
Matthias
Re: ClassCastException when setting timeZone attribute in f:convertDataTime using EL
Matthias,
When I changed my method getTimeZone() to return a TimeZone, things worked as
expected.
I guess my confusion comes from the TLD Documentation,
http://myfaces.apache.org/impl/tlddoc/index.html.
When this value is a value-binding to a TimeZone instance, that timezone is
used. Otherwise
this value is treated as a String containing a timezone id, ie as the ID
parameter of method
java.util.TimeZone.getTimeZone(String).
I read this to mean that the converter would converter would treat String
value-binding the same way
as a String value. Below is a coded version of my expectation.
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb = facesContext.getApplication().createValueBinding(value);
TimeZone timeZone;
Object value = vb.getValue(facesContext);
if (value instanceof TimeZone)
{
timeZone = (TimeZone) value;
}
else
{
timeZone = TimeZone.getTimeZone(value.toString())
}
converter.setTimeZone(timeZone);
}
Is my expectation in keeping with the spec?
If it is case should I enter a JIRA issue?
Paul Spencer
Paul Spencer wrote:
The type is string
public String getTimeZone()
{
return GMT-05:00;
}
Paul Spencer
Matthias Wessendorf wrote:
f:convertDateTime type=time
timeZone=#{phrQueryManager.timeZone}/
Is this type of TimeZone ?
*snip*
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
converter.setTimeZone((TimeZone)vb.getValue(facesContext));
}
*snip*
Regards,
Matthias
Re: ClassCastException when setting timeZone attribute in f:convertDataTime using EL
Matthias
I have entered the issue, http://issues.apache.org/jira/browse/MYFACES-1317,
but I was not able to
assign it to you.
Thanks you,
Paul Spencer
Matthias Wessendorf wrote:
Paul-
good catch. You are right. RI TLD Doc says the same.
Create a bug for MyFaces Core Jira project and asign the ticket please
to me !
(matzew)
Thanks,
Matthias
On 5/31/06, Paul Spencer [EMAIL PROTECTED] wrote:
Matthias,
When I changed my method getTimeZone() to return a TimeZone, things
worked as expected.
I guess my confusion comes from the TLD Documentation,
http://myfaces.apache.org/impl/tlddoc/index.html.
When this value is a value-binding to a TimeZone instance, that
timezone is used. Otherwise
this value is treated as a String containing a timezone id, ie as
the ID parameter of method
java.util.TimeZone.getTimeZone(String).
I read this to mean that the converter would converter would treat
String value-binding the same way
as a String value. Below is a coded version of my expectation.
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
TimeZone timeZone;
Object value = vb.getValue(facesContext);
if (value instanceof TimeZone)
{
timeZone = (TimeZone) value;
}
else
{
timeZone = TimeZone.getTimeZone(value.toString())
}
converter.setTimeZone(timeZone);
}
Is my expectation in keeping with the spec?
If it is case should I enter a JIRA issue?
Paul Spencer
Paul Spencer wrote:
The type is string
public String getTimeZone()
{
return GMT-05:00;
}
Paul Spencer
Matthias Wessendorf wrote:
f:convertDateTime type=time
timeZone=#{phrQueryManager.timeZone}/
Is this type of TimeZone ?
*snip*
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
converter.setTimeZone((TimeZone)vb.getValue(facesContext));
}
*snip*
Regards,
Matthias
Should t:inputCalendar have a timeZone attribute?
Should t:inputCalendar have a timeZone attribute? This would keep it consistent with the t:inputTime and f:convertDateTime tags. Should I enter a JIRA issue? Paul Spencer
Re: [jira] Closed: (MYFACES-1317) ClassCastException when setting timeZone attribute in f:convertDataTime using EL
Matthias,
Should Fixed Version be 1.1.4?
Paul Spencer
Matthias Weßendorf (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MYFACES-1317?page=all ]
Matthias Weßendorf closed MYFACES-1317:
---
Fix Version: 1.1.3
Resolution: Fixed
fixed in nbuild.
Thanks Paul!
ClassCastException when setting timeZone attribute in f:convertDataTime using
EL
--
Key: MYFACES-1317
URL: http://issues.apache.org/jira/browse/MYFACES-1317
Project: MyFaces Core
Type: Bug
Versions: 1.1.3
Reporter: Paul Spencer
Assignee: Matthias Weßendorf
Fix For: 1.1.3
I am setting the time zone attribute for the tag f:convertDataTime from a
backing bean. This causes the following
ClassCastException in core 1.1.3
Caused by: java.lang.ClassCastException
at
org.apache.myfaces.shared_impl.taglib.core.ConvertDateTimeTagBase.setConverterTimeZone(ConvertDateTimeTagBase.java:165)
at
org.apache.myfaces.shared_impl.taglib.core.ConvertDateTimeTagBase.createConverter(ConvertDateTimeTagBase.java:85)
at javax.faces.webapp.ConverterTag.doStartTag(ConverterTag.java:63)
If I hard code the time zone in the attribute, i.e. timeZone=GMT-05:00, no exception is thrown.
When I changed my method getTimeZone() to return a TimeZone, things worked as expected.
I guess my confusion comes from the TLD Documentation,
http://myfaces.apache.org/impl/tlddoc/index.html.
When this value is a value-binding to a TimeZone instance, that timezone is
used. Otherwise
this value is treated as a String containing a timezone id, ie as the ID
parameter of method
java.util.TimeZone.getTimeZone(String).
I read this to mean that the converter would converter would treat String
value-binding the same way
as a String value. Below is a coded version of my expectation.
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb = facesContext.getApplication().createValueBinding(value);
TimeZone timeZone;
Object value = vb.getValue(facesContext);
if (value instanceof TimeZone)
{
timeZone = (TimeZone) value;
}
else
{
timeZone = TimeZone.getTimeZone(value.toString())
}
converter.setTimeZone(timeZone);
}
From Matthias Wessendorf:
Paul-
good catch. You are right. RI TLD Doc says the same.
Create a bug for MyFaces Core Jira project and asign the ticket please to me !
(matzew)
Thanks,
Matthias
Re: ClassCastException when setting timeZone attribute in f:convertDataTime using EL
The type is string
public String getTimeZone()
{
return GMT-05:00;
}
Paul Spencer
Matthias Wessendorf wrote:
f:convertDateTime type=time
timeZone=#{phrQueryManager.timeZone}/
Is this type of TimeZone ?
*snip*
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
converter.setTimeZone((TimeZone)vb.getValue(facesContext));
}
*snip*
Regards,
Matthias
Re: ClassCastException when setting timeZone attribute in f:convertDataTime using EL
Matthias
I have entered the issue, http://issues.apache.org/jira/browse/MYFACES-1317,
but I was not able to
assign it to you.
Thanks you,
Paul Spencer
Matthias Wessendorf wrote:
Paul-
good catch. You are right. RI TLD Doc says the same.
Create a bug for MyFaces Core Jira project and asign the ticket please
to me !
(matzew)
Thanks,
Matthias
On 5/31/06, Paul Spencer [EMAIL PROTECTED] wrote:
Matthias,
When I changed my method getTimeZone() to return a TimeZone, things
worked as expected.
I guess my confusion comes from the TLD Documentation,
http://myfaces.apache.org/impl/tlddoc/index.html.
When this value is a value-binding to a TimeZone instance, that
timezone is used. Otherwise
this value is treated as a String containing a timezone id, ie as
the ID parameter of method
java.util.TimeZone.getTimeZone(String).
I read this to mean that the converter would converter would treat
String value-binding the same way
as a String value. Below is a coded version of my expectation.
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
TimeZone timeZone;
Object value = vb.getValue(facesContext);
if (value instanceof TimeZone)
{
timeZone = (TimeZone) value;
}
else
{
timeZone = TimeZone.getTimeZone(value.toString())
}
converter.setTimeZone(timeZone);
}
Is my expectation in keeping with the spec?
If it is case should I enter a JIRA issue?
Paul Spencer
Paul Spencer wrote:
The type is string
public String getTimeZone()
{
return GMT-05:00;
}
Paul Spencer
Matthias Wessendorf wrote:
f:convertDateTime type=time
timeZone=#{phrQueryManager.timeZone}/
Is this type of TimeZone ?
*snip*
if (UIComponentTag.isValueReference(value))
{
ValueBinding vb =
facesContext.getApplication().createValueBinding(value);
converter.setTimeZone((TimeZone)vb.getValue(facesContext));
}
*snip*
Regards,
Matthias
ERROR - Row is not available. Rowindex ... Tomahawk 1.1.3-SNAPSHOT
I am getting the following error in Tomahawk 1.1.3-SNAPSHOT (Build 26
20060525230507). This
error does not occur when running Tomahawk 1.1.2. In both cases the MyFaces
version is 1.1.3
ERROR - Row is not available. Rowindex = 2
WARN - HTML nesting warning on closing tbody: element tr rendered by component
: {Component-Path :
[Class: javax.faces.component.UIViewRoot,ViewId: /mpr_results.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: _idJsp31]
[Class: org.apache.myfaces.component.html.ext.HtmlDataTable,Id: data]} not
explicitly closed
Two rows in the table are displayed, which is the correct number of expected
rows in the table.
Below is an excerpt of the JSP.
t:dataTable id=data
value=#{mprQueryManager.resultData}
var=rowVar border=1
rows=#{mprQueryManager.dataRowsPerPage}
preserveDataModel=false
rowOnMouseOver=this.style.backgroundColor='#A5CBFF'
rowOnMouseOut=this.style.backgroundColor='inherit'
styleClass=dataTable width=100%
h:column
/t:dataTable
t:dataScroller for=data
fastStep=10
styleClass=scroller
paginator=true
paginatorMaxPages=9
paginatorTableClass=paginator
paginatorActiveColumnStyle=font-weight: bold;
renderFacetsIfSinglePage=false
...
/t:dataScroller
Paul Spencer
Re: Upcoming Tomahawk Release
Please update the 1.1.3-SNAPSHOT so it the same as the RC. This will make it much easier to test the RC with maven project that are configure to use the Tomahawk snapshot. http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk/1.1.3-SNAPSHOT/ Paul Spencer Sean Schofield wrote: OK there is an updated release candidate up there now. Can someone check it to make sure Dennis' logging stuff made it in? I need to leave the office for a bit. Once this is confirmed we can start the vote thread. (In the meantime I will be preparing the artifacts for an anticipated release.) Sean On 6/7/06, Sean Schofield [EMAIL PROTECTED] wrote: Never mind. I see that you committed to the shared trunk. I merged it up to the branch for you. Sean On 6/7/06, Sean Schofield [EMAIL PROTECTED] wrote: Right but it will be recompiled into tomahawk via maven. You checked it into the shared branch right? Sean On 6/6/06, Dennis Byrne [EMAIL PROTECTED] wrote: The logging stuff actually was in shared though. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 6, 2006 11:02 PM To: 'MyFaces Development' Subject: Re: Upcoming Tomahawk Release OK so you will check your fix into the trunk then? The current 1.1.3 snapshot isn't technically the release candidate because of the logging changes that Dennis made. I'll put together the official release candidate tomorrow (Wednesday.) Sean On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I figured out that treeTable's links aren't working, when using RI But to me no showstopper. So let's use 1.1.3-Snapshot as a RC -Matthias On 6/5/06, Dennis Byrne [EMAIL PROTECTED] wrote: The logging was actually in shared BTW. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, June 5, 2006 11:18 PM To: 'MyFaces Development' Subject: Re: Upcoming Tomahawk Release OK so once Dennis adds his logging stuff I will start the release. Thanks for the help. You are a MyFaces animal these days. Glad to have you back on full time! Sean On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Sean- TOMAHAWK-458 works now for me... I can't reproduce. May be I did something wrong during my last testing. For tomahawk 1.1.2 release I also tested against RI and the scroller worked there for me. I go ahead and close this issue. -Matthias On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yes, Ill give it a try this evening (PST). -Matthias On 6/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Can we look at TOMAHAWK-458 and close the door on this release? Sean On 6/2/06, Sean Schofield [EMAIL PROTECTED] wrote: I verified that two of the issues are also present in the 1.1.2 release so I don't consider these showstoppers. Anyone disagree? That leaves one last bug. TOMAHAWK-458. Can folks take a quick look at this one. Sean On 5/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Jira issue created. Will give RI tomorrow / friday a more detailed try! -Matthias On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote: Matthias, Can you add a few JIRA issues with fix version as 1.1.3-SNAPSHOT. That will allow us to keep track of the outstanding issues. Sean On 5/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: RI makes some trouble with this build of Tomahawk. -Some links are not working (sortable table for instance) -Some links I must trigger twice to get a *result* (scrolling through a table) -Some exceptions on the jsf page (instead of rendered output) -forceId,jsp makes troubles duplicated IDs commandLink id=button insideform id=forceIdForm commandButton id=button insideform id=dataTable both are forceId=true for me it should be fine, since their jsf client id is a)forceIdForm:button b)dataTable:button but not all components are making problems -fileupload or tree2 are working fine. -Matthias On 5/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Just check the updated brunch. Now the *rc* looks good to me! Each sample works w/ MyFaces as JSF runtime. Will give it a try w/ RI as JSF runtime -Matthias
Re: Upcoming Tomahawk Release
Sean, The snapshot is dated 25-May-2006 16:05. Per your message, OK there is an updated release candidate up there now, I was expecting one dated today. Paul Spencer Sean Schofield wrote: The 1.1.3 SNAPSHOT is the release candidate :-) Technically its a snapshot because maven considers anything that hasn't been officially released as such. Sean On 6/7/06, Paul Spencer [EMAIL PROTECTED] wrote: Please update the 1.1.3-SNAPSHOT so it the same as the RC. This will make it much easier to test the RC with maven project that are configure to use the Tomahawk snapshot. http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk/1.1.3-SNAPSHOT/ Paul Spencer Sean Schofield wrote: OK there is an updated release candidate up there now. Can someone check it to make sure Dennis' logging stuff made it in? I need to leave the office for a bit. Once this is confirmed we can start the vote thread. (In the meantime I will be preparing the artifacts for an anticipated release.) Sean snip
Re: Displaying radio buttons in datatable
Kalpana,
I suspect the use of forceId and forceIdIndex is the source of the
problem. Unless their is a reason you are using them, then I would set
both to false, otherwise set both to true.
** From the TLD http://myfaces.apache.org/tomahawk/tlddoc/index.html
forceIdIndex If false, this component will not append a '[n]' suffix
(where 'n' is the row index) to components that are
contained within a list. This value will be true by
default and the value will be ignored if the value of
forceId is false (or not specified.)
Paul Spencer
kalpana wrote:
Hi,
My requirement is to display radio buttons in a datatable. On selecting the
radio button and clicking on next button the selected rows values should be
displayed in the next page.
I tried using the selectOneRadio component of Tomahawk.
Following is the snippet of code i have used
t:selectOneRadio id=select forceId=true forceIdIndex=false
value=#{SourceInputController.select} immediate=true
valueChangeListener=#{SourceInputController.selectSourceInputRequest}
f:selectItems value=#{SourceInputController.selectList} /
/t:selectOneRadio
This code displays radio buttons with the same id. The issue is on load of
the page the last radio button is selected by default. When i click the next
button only the last row values displays irrespective of the selection i do.
Is there any possible to get rid of this issue.
Thanks in advance for the help.
Kalpana
Tomahawk, Tobago, and Trinidad are not listed in projects.apache.org. MyFaces info out of date in projects.apache.org
Apache's home page references a catalog of Apache project. I noticed the following relative to MyFaces: 1) Tomahawk, Tobago, and Trinidad are not listed in projects.apache.org. 2) MyFaces info out of date in projects.apache.org Paul Spencer
Exception in 1.1.4-SNAPSHOT after validation error while using t:panelTabbedPane serverSideTabSwitch=true
(Tomahawk 1.1.4-SNAPSHOT, MyFaces 1.1.4-SNAPSHOT)
I have a Tabbed panel with 3 tabs. If a validation error is displayed on the
current tab, then
the following exception report will be returned when a another tab is selected and
serverSideTabSwitch=true.
javax.faces.FacesException: Value is no String (class=org.apache.myfaces.shared_impl.renderkit.RendererUtils$1,
[EMAIL PROTECTED]) and component _idJsp235:reportTypewith path: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /query.jsp][Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _idJsp1][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _idJsp232][Class: javax.faces.component.html.HtmlForm,Id: _idJsp235][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp291][Class: javax.faces.component.html.HtmlSelectOneRadio,Id: reportType]} does not have a Converter
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:422)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
Do I need to report this as an issue?
Paul Spencer
Relative to Nagivation, which component shoud be used for new development?
Which navigation components should be used for new development? t:panelNavigation or t:panelNavigation2 ? t:commandNavigation, or t:commandNavigation2, or t:navigationMenuItem? Paul Spencer
Relative to Nagivation, which component shoud be used for new development?
Which navigation components should be used for new development? t:panelNavigation or t:panelNavigation2 ? t:commandNavigation, or t:commandNavigation2, or t:navigationMenuItem? Paul Spencer
Re: Exception in 1.1.4-SNAPSHOT after validation error while using t:panelTabbedPane serverSideTabSwitch=true
Matthias,
I am not annoyed, but sometimes a little frustrated :)
Paul Spencer
Matthias Wessendorf wrote:
Hey Paul,
I understand that you are annoyed about the feedback here
on the questions. I haven't used that component. Can't say
anything about.
May the others help ...
Sorry,
Matthias
On 7/12/06, Paul Spencer [EMAIL PROTECTED] wrote:
(Tomahawk 1.1.4-SNAPSHOT, MyFaces 1.1.4-SNAPSHOT)
I have a Tabbed panel with 3 tabs. If a validation error is displayed
on the current tab, then
the following exception report will be returned when a another tab is
selected and serverSideTabSwitch=true.
javax.faces.FacesException: Value is no String
(class=org.apache.myfaces.shared_impl.renderkit.RendererUtils$1,
[EMAIL PROTECTED])
and component _idJsp235:reportTypewith path: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /query.jsp][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_idJsp1][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
_idJsp232][Class: javax.faces.component.html.HtmlForm,Id:
_idJsp235][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp291][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: reportType]} does
not have a Converter
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:422)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
Do I need to report this as an issue?
Paul Spencer
Re: Exception in 1.1.4-SNAPSHOT after validation error while using t:panelTabbedPane serverSideTabSwitch=true
Gerald,
Below is related JSP code.
h:selectOneRadio id=reportType layout=pageDirection
value=#{processQueryBean.reportType} required=true
f:selectItems value=#{processQueryBean.reportTypes} /
/h:selectOneRadio
Does this help?
Paul Spencer
Gerald Müllan wrote:
Hi Paul,
I think this is not an issue of tabbedPane, it`s an issue of your
HtmlSelectOneRadio component.
How do you initialize the SelectItem list bound to the menu?
If there is an object as value, you have to take care of it via a
converter.
cheers,
Gerald
On 7/12/06, Paul Spencer [EMAIL PROTECTED] wrote:
(Tomahawk 1.1.4-SNAPSHOT, MyFaces 1.1.4-SNAPSHOT)
I have a Tabbed panel with 3 tabs. If a validation error is displayed
on the current tab, then
the following exception report will be returned when a another tab is
selected and serverSideTabSwitch=true.
javax.faces.FacesException: Value is no String
(class=org.apache.myfaces.shared_impl.renderkit.RendererUtils$1,
[EMAIL PROTECTED])
and component _idJsp235:reportTypewith path: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /query.jsp][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_idJsp1][Class:
org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id:
_idJsp232][Class: javax.faces.component.html.HtmlForm,Id:
_idJsp235][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp291][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: reportType]} does
not have a Converter
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:422)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
Do I need to report this as an issue?
Paul Spencer
Re: Relative to Nagivation, which component shoud be used for new development?
Mike, I have started the wiki page. http://wiki.apache.org/myfaces/Navigation_Overview It is still a work in progress. Paul Spencer Mike Kienenberger wrote: Hey Paul, Take a look at this thread: http://www.mail-archive.com/dev@myfaces.apache.org/msg13757.html It'd be great if you'd create a wiki entry on this. Also, my personal thanks for all of the wiki work you've been doing up to this point. On 7/12/06, Paul Spencer [EMAIL PROTECTED] wrote: Which navigation components should be used for new development? t:panelNavigation or t:panelNavigation2 ? t:commandNavigation, or t:commandNavigation2, or t:navigationMenuItem? Paul Spencer
Re: t:commandLink
Girish,
I not sure if this will help.
Since 1.1.2 t:commandLink must be enclosed in h:form. If it is not, then
clicking
the link will appear to do nothing.
Paul Spencer
Kumar, Girish wrote:
Guys,
I have problem invoking the t:commandLink onlick and
t:UpdateActionLister
Here is teh scenario,
I need to fire an even which is javascript function and goes to next
page and fire and action on the UpdateActionListener.
Here is the snippet:
t:commandLink styleClass=labelLeft
id=details
action=#{sysAppIssueEditDetailActionHandler.detailsClick}
immediate=false
target=frame2
h:outputText value=Details /
t:updateActionListener
property=#{editDetailActionHandler.sysAppIssuesEditDetailBean.dataItem}
value=#{item} /
/t:commandLink
Thanks
Girish
**
This message and any attached documents contain information
which may be confidential, subject to privilege or exempt from
disclosure under applicable law. These materials are solely for
the use of the intended recipient. If you are not the intended
recipient of this transmission, you are hereby notified that any
distribution, disclosure, printing, copying, storage, modification
or the taking of any action in reliance upon this transmission is
strictly prohibited. Delivery of this message to any person other
than the intended recipient shall not compromise or waive
such confidentiality, privilege or exemption from disclosure as
to this communication.
If you have received this communication in error, please notify
the sender immediately and delete this message from your system.
*
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 7/13/2006
Re: t:commandLink
Girish,
I not sure if this will help.
Since 1.1.2 t:commandLink must be enclosed in h:form. If it is not, then
clicking
the link will appear to do nothing.
Paul Spencer
Kumar, Girish wrote:
Guys,
I have problem invoking the t:commandLink onlick and
t:UpdateActionLister
Here is teh scenario,
I need to fire an even which is javascript function and goes to next
page and fire and action on the UpdateActionListener.
Here is the snippet:
t:commandLink styleClass=labelLeft
id=details
action=#{sysAppIssueEditDetailActionHandler.detailsClick}
immediate=false
target=frame2
h:outputText value=Details /
t:updateActionListener
property=#{editDetailActionHandler.sysAppIssuesEditDetailBean.dataItem}
value=#{item} /
/t:commandLink
Thanks
Girish
**
This message and any attached documents contain information
which may be confidential, subject to privilege or exempt from
disclosure under applicable law. These materials are solely for
the use of the intended recipient. If you are not the intended
recipient of this transmission, you are hereby notified that any
distribution, disclosure, printing, copying, storage, modification
or the taking of any action in reliance upon this transmission is
strictly prohibited. Delivery of this message to any person other
than the intended recipient shall not compromise or waive
such confidentiality, privilege or exemption from disclosure as
to this communication.
If you have received this communication in error, please notify
the sender immediately and delete this message from your system.
*
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 7/13/2006
Suggested tool for screen shot?
The wiki mentions including a screen shot in the documentation, http://wiki.apache.org/myfaces/promotion. Is their a suggest tool to use and format (JPEG/GIF)? Paul Spencer
Re: [jira] Created: (TOMAHAWK-568) Navigation links displayed are not consistent across layouts, list or table.
I am working on a patch for this issue. It will include a test case. Their are other issues related to the same component (Panel Navigation2) that may be resolved in my patch, but I will not know until the patch is done. This issue may be assigned to me. I do not have the karma to assign the issue. Paul Spencer Paul Spencer (JIRA) wrote: Navigation links displayed are not consistent across layouts, list or table. - Key: TOMAHAWK-568 URL: http://issues.apache.org/jira/browse/TOMAHAWK-568 Project: MyFaces Tomahawk Issue Type: Bug Components: NavigationMenuItem, Panel Navigation2 Affects Versions: 1.1.3, 1.1.2, 1.1.1, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Paul Spencer ** * Use of t:commandNavigation2 in t:panelNavigation2 ** t:panelNavigation2 t:commandNavigation2 value=Nav 1 action=nav1/ t:commandNavigation2 value=Nav 2 action=nav2/ /t:panelNavigation2 When the layout was undefined or set to list, ONLY the bullets where displayed. No navigation links where displayed. When the layout was set to table, the navigation links where displayed as expected. ** * Use of t:navigationMenuItem in t:panelNavigation2 ** t:panelNavigation2 t:navigationMenuItem itemLabel=Nav 1 action=nav1/ t:navigationMenuItem itemLabel=Nav 2 action=nav2/ /t:panelNavigation2 When the layout was undefined or set to list, the navigation links where displayed as expected. When the layout was set to table, nothing was displayed. Looking at the HTML source, the expected table, tr, and td tags where present.
Tomahawk 1.1.5-SNAPSHOT failing to build. Failed to resolve artifact org.apache.maven.surefire:surefire-api:jar:2.4.1
I have done a svn update after returning for a long vacation and Tomahawk now fails to build. MyFaces core does correctly build. Below is the failure: [INFO] [surefire:test] Downloading: http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-api/2.4.1/surefire-api-2.4.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-api/2.4.1/surefire-api-2.4.1.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.maven.surefire:surefire-api:jar:2.4.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.surefire -DartifactId=surefire-api \ -Dversion=2.4.1 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) dummy:dummy:jar:1.0 2) org.apache.maven.surefire:surefire-junit:jar:2.0 3) org.apache.maven.surefire:surefire-api:jar:2.4.1 -- 1 required artifact is missing. for artifact: dummy:dummy:jar:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) Any ideas? I am working on a patch to navigation tags in Tomahawk, but this is a show stopper. Paul Spencer
How to configure the default renderers and component within a Shale-Test based unit test
I am writing a unit test based on the Shale Test Framework for a Tomahawk component. My current problem is the I need to add the default MyFaces and Tomahawk components and renderers to the FacesContext. To date I have been using facesContext.getApplication().addComponent(...) and facesContext.getRenderKit().addRenderer(...). This is becoming very cumbersome. I know the defaults are out their in various configuration files, but I do not know how to tell Shale's test framework how to use them. Suggestions? Paul Spencer
Shared and API circular dependency, related to (MYFACES-1406)
Wendy, The circular dependency between the API and shared projects is a little concerning. Is this something that can be easily be fixed? Since the dependency is marked as provided, does this eliminate the circular depenency issues in Maven? I use Eclipse and the Maven Eclipse plugin to generated the Eclipse project files. Currently the shared projects reference the 1.1.1 version of the API. The means the debuggers and the other tools in the Eclipse are using 1.1.1 API. Like you said the API does not change, but use of an older version it can be confusing. Paul Spencer Wendy Smoak (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT .
Re: [jira] Commented: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
Wendy, Should the patch to core be applied? Paul Spencer Wendy Smoak (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT .
Re: [jira] Commented: (MYFACES-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
Wendy, Should the patch to core be applied? Paul Spencer Wendy Smoak (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT .
Need description for Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. in 1.1.4 annoucmenent
Mike, Please add a description, or link to one, about the following statement in in the announcement. Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. The description should include instruction on what a developer must change for 1.1.4 to work with their 1.1.3 application. Paul Spencer Mike Kienenberger wrote: Hehe. All part of the fun of being an equal partner :-) Copy what you had into a wiki page and we'll work on both announcements until they look good enough to send out. On 9/15/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Ok, the real reason for adding the tobago announcement to the core announcemnt is: 'I don't like sending announcement' Ask Arvid for sending it. Regards Bernd Mike Kienenberger wrote: Bernd, I don't have a problem with the MyFaces announcement containing a statement about Tobago, but Tobago also needs its own release announcement, just like Tomahawk needs its own release announcement. On 9/15/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Wendy, can we add the Tobago Announcement to the Core Announcement? Regards Bernd Matthias Wessendorf wrote: Wendy thanks for helping out on the release. Go ahead and announce it! On 9/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: The MyFaces Core 1.1.4 build is available for evaluation: http://people.apache.org/builds/myfaces/core-1.1.4/ ... http://wiki.apache.org/myfaces/CoreRelease114 Vote Results: 6 +1 binding votes from PMC members: Dennis Byrne [1], Martin Marinschek, Grant Smith, Bruno Aranda, Matthias Wessendorf, Mike Kienenberger 2 +1 non-binding votes Cagatay Civici, Gerald Müllan (If I've got you in the wrong place, check the myfaces-master pom [2] to make sure your information is correct, and let me know.) I'll get this on the mirrors and the central Maven repository some time this weekend. I've added a draft release announcement to the release plan wiki page. (link above) If you want me to send it out, please adjust as necessary! (It might need a statement about what version of Tomahawk is compatible, and I have no idea.) Alternately, if someone else would like to make the announcement after everything is in place, that's fine with me. Manfred? Martin? [1] Dennis voted +1 when he reported the TCK test results: http://www.nabble.com/Re%3A--MyFaces-Core-1.1.4---STATUS-p6248637.html [2] http://svn.apache.org/repos/asf/myfaces/maven/trunk/master-pom/pom.xml Thanks, -- Wendy Smoak
Re: Need description for Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. in 1.1.4 annoucmenent
Wendy, I added a link to the matrix. I also made some minor visual changes to the matrix. Feel free to back them out if you do not like them. Paul Spencer Wendy Smoak wrote: On 9/15/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Hey Paul. Maybe you can help rewrite it so it's more obvious. Apparently the problem is that some of the javascript generated by 1.1.3 isn't compatible with the JSF RI. So in 1.1.4, those javascript methods have been renamed. This probably answers my question in the other thread. I think the release announcement needs to give a reason for the incompatibility. Also, to help users figure out what can be expected to work together: http://wiki.apache.org/myfaces/CompatibilityMatrix (It could be expanded to show which component libraries work together, as well.)
Re: Need description for Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. in 1.1.4 annoucmenent
I move the warning to the matrix page and placed Wendy's text in the announcement. Paul Spencer Wendy Smoak wrote: On 9/15/06, Mike Kienenberger [EMAIL PROTECTED] wrote: The following page has been changed by PaulSpencer: http://wiki.apache.org/myfaces/CoreRelease114 The comment on the change is: Added Mike Kienenberger's descriptive text to the announcement The only problem I see with this is that it's far too verbose. Agreed. I'm having trouble boiling it down to a single sentence, though. Due to changes related to compatibility with the reference implementation, MyFaces Core 1.1.4 cannot be used with Tomahawk 1.1.3. Just trying to head off the Why not? You said... questions.
Re: Need description for Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. in 1.1.4 annoucmenent
Done. Paul Spencer Mike Kienenberger wrote: On 9/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: Agreed. I'm having trouble boiling it down to a single sentence, though. Due to changes related to compatibility with the reference implementation, MyFaces Core 1.1.4 cannot be used with Tomahawk 1.1.3. Maybe Due to changes required for compatibility with
Re: Need description for Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. in 1.1.4 annoucmenent
Mike, I added you text, although with some minor changes. Paul Spencer Mike Kienenberger wrote: Hey Paul. Maybe you can help rewrite it so it's more obvious. Apparently the problem is that some of the javascript generated by 1.1.3 isn't compatible with the JSF RI. So in 1.1.4, those javascript methods have been renamed. No application-level code needs to change (provided you're not using the internal javascript methods on your pages), but you cannot mix Tomahawk 1.1.3 with MyFaces Core 1.1.4 because they use incompatible javascript. Nor can you mix MyFaces Core 1.1.3 with Tomahawk 1.1.4. That's unfortunate because up to this point we were advertising that you could mix and match them -- we overlooked the javascript interdependencies. On 9/15/06, Paul Spencer [EMAIL PROTECTED] wrote: Mike, Please add a description, or link to one, about the following statement in in the announcement. Core 1.1.4 is not backwards-compatible with Tomahawk 1.1.3. The description should include instruction on what a developer must change for 1.1.4 to work with their 1.1.3 application. Paul Spencer Mike Kienenberger wrote: Hehe. All part of the fun of being an equal partner :-) Copy what you had into a wiki page and we'll work on both announcements until they look good enough to send out. On 9/15/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Ok, the real reason for adding the tobago announcement to the core announcemnt is: 'I don't like sending announcement' Ask Arvid for sending it. Regards Bernd Mike Kienenberger wrote: Bernd, I don't have a problem with the MyFaces announcement containing a statement about Tobago, but Tobago also needs its own release announcement, just like Tomahawk needs its own release announcement. On 9/15/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Wendy, can we add the Tobago Announcement to the Core Announcement? Regards Bernd Matthias Wessendorf wrote: Wendy thanks for helping out on the release. Go ahead and announce it! On 9/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: The MyFaces Core 1.1.4 build is available for evaluation: http://people.apache.org/builds/myfaces/core-1.1.4/ ... http://wiki.apache.org/myfaces/CoreRelease114 Vote Results: 6 +1 binding votes from PMC members: Dennis Byrne [1], Martin Marinschek, Grant Smith, Bruno Aranda, Matthias Wessendorf, Mike Kienenberger 2 +1 non-binding votes Cagatay Civici, Gerald Müllan (If I've got you in the wrong place, check the myfaces-master pom [2] to make sure your information is correct, and let me know.) I'll get this on the mirrors and the central Maven repository some time this weekend. I've added a draft release announcement to the release plan wiki page. (link above) If you want me to send it out, please adjust as necessary! (It might need a statement about what version of Tomahawk is compatible, and I have no idea.) Alternately, if someone else would like to make the announcement after everything is in place, that's fine with me. Manfred? Martin? [1] Dennis voted +1 when he reported the TCK test results: http://www.nabble.com/Re%3A--MyFaces-Core-1.1.4---STATUS-p6248637.html [2] http://svn.apache.org/repos/asf/myfaces/maven/trunk/master-pom/pom.xml Thanks, -- Wendy Smoak
Has the MyFaces Core 1.1.4 release announcement been sent?
Based on the MyFaces home page and the wiki, MyFaces Core 1.1.4 was release on September 18, but I have not seen the announcement on the mailing lists. Has the announcement been sent? Paul Spencer
Re: [jira] Updated: (MYFACES-1488) ASF Source Header and Copyright Notice Policy
Once the patch is committed, I will create and submit a patch for another project. I have configured the Checkstyle to identify files needing the header updated. I did this by adding configuration files to org.apache.myfaces.maven:build-tools and adding the Checkstyle v2.1 plugin to pom.xml in various projects. Should I open up a new issue and submit this as a patch? Paul Spencer Paul Spencer (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1488?page=all ] Paul Spencer updated MYFACES-1488: -- Status: Patch Available (was: Open) ASF Source Header and Copyright Notice Policy - Key: MYFACES-1488 URL: http://issues.apache.org/jira/browse/MYFACES-1488 Project: MyFaces Core Issue Type: Improvement Reporter: Wendy Smoak Priority: Blocker Fix For: 1.1.5-SNAPSHOT All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html We could also run Robert Burrell Donkin's RAT (release audit tool) to see if anything else is missing http://code.google.com/p/arat/
Re: Core Release 1.1.5
Wendy, I have submitted a patch to correct the license headers for one of the core maven projects [1]. As soon as it is committed, I will create patches for the remaining maven projects. FYI: I have an internal project that is waiting on the release, so I am motivated to provided a patch for the remaining projects. Paul Spencer [1] http://issues.apache.org/jira/browse/MYFACES-1488?page=all Wendy Smoak wrote: On 11/8/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I have some time to prepare the release, but will need help from some of you (eg. Wendy). First of all I will create a branch for core 1.1.5 and shared 2.0.5 and start the release process. We need to fix the license headers before branching, otherwise we'll have to do it twice. Unless someone changed it, the trunk of Core (1.1.5-SNAPSHOT) still depends on the 2.0.4 branch of shared, so if all goes well we can use it for both Core and Tomahawk. Please update the timeline on the release plan as you go along, so everyone stays informed: http://wiki.apache.org/myfaces/CoreRelease115 There's also a status document that should be updated when a new branch is created: http://svn.apache.org/repos/asf/myfaces/current/STATUS.txt Thanks!
Re: [jira] Commented: (MYFACES-1491) Implement the Checkstyle plugin
Grant, I do not see the files added by the patch: maven\build-tools\src\main\resources\config\myfaces-checks.xml maven\build-tools\src\main\resources\config\myfaces-header.txt In addition the patch deleted: maven\build-tools\src\main\resources\org\apache\myfaces\checkstyle.xml Paul Spencer Grant Smith (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1491?page=comments#action_12450140 ] Grant Smith commented on MYFACES-1491: -- Patch applied. Implement the Checkstyle plugin --- Key: MYFACES-1491 URL: http://issues.apache.org/jira/browse/MYFACES-1491 Project: MyFaces Core Issue Type: Improvement Components: build process Reporter: Paul Spencer Assigned To: Grant Smith Attachments: patch.txt As a followup to to MyFaces-1488, this is a requst to implement Maven's Checkstyle plugin to insure all source files contain the correct Apache License. Additional checks, i.e. modules, can be added in the future. This request is limited to checking for the Apache License
I need MyFaces 1.1.5 and Tomahawk 1.1.4 released and I am willing to help!
I have several projects that are moving from demoware to production. The demoware versions use a snapshot of Tomahawk 1.1.4, so I need for Tomahawk 1.1.4 to be released for the production versions. To this end, I have submitted patches for MyFaces and Tomahawk, and will continue to submit patches. Base on the wiki [1][2] the following are on task need to be completed: 1) Release MyFaces 1.1.5 - Their is one blocker, http://issues.apache.org/jira/browse/MYFACES-1488. Grant Smith has done some work on this, but he has an open question on how to proceed. If the answer involves adding the Apache license to ALL files, I can help with this. 2) TOMAHAWK-767 (http://issues.apache.org/jira/browse/TOMAHAWK-767) - i have submitted a patch on this one, which has not been applied or commented on. As with #1, I am offering to help with this issue. Paul Spencer [1]http://wiki.apache.org/myfaces/TomahawkRelease114?highlight=%28release%29 [2]http://wiki.apache.org/myfaces/CoreRelease115?highlight=%28release%29
Re: HostedQA Selenium tests for the Tomahawk components
Wendy, I would like to setup some Selenium test, in part so I know if I break something. Based on the email, we can use HostedQA to run the Selenium tests. If this is still true, will you setup an account for me on the server. Paul Spencer I would like Selenium Wendy Smoak wrote: At this point I have the popup and tree2nonav tests running at HostedQA, on Tomcat, in both IE and Firefox. You can see the results here: * https://myfaces.hostedqa.com/project/54/session/suite/list (Follow the links to see the log file and screen shots of every step of the tests.) These are the same tests that you can run locally using this info: * http://myfaces.apache.org/tomahawk/testing/selenium.html I haven't figured out how to automatically update the app at HostedQA, right now I have to go log in and upload a new version. I'll set up an account at myfaces.hostedqa.com for any committer, just ask!
Re: HostedQA Selenium tests for the Tomahawk components
Wendy, The email has not yet come through. Paul Spencer Wendy Smoak wrote: On 11/24/06, Paul Spencer [EMAIL PROTECTED] wrote: I would like to setup some Selenium test, in part so I know if I break something. Based on the email, we can use HostedQA to run the Selenium tests. If this is still true, will you setup an account for me on the server. Done. You should have gotten an email... let me know if not. See this page for information on configuration: http://myfaces.apache.org/tomahawk/testing/hostedqa.html You can also run the Selenium tests locally: http://myfaces.apache.org/tomahawk/testing/selenium.html The tests are currently only configured to run under Firefox at HostedQA, so there's not really much to be gained by executing them remotely. (The tests that use xpath expressions tend to fail in IE. My guess is that the components render themselves differently in different browsers.)
Re: panelNavigation2 icon and label issue
Chintan, This may or may not help, you can use t:commandNavigation2 to display an icon and text. Below is from a test program I am working on. Based on you message, it appears you are dynamically creating the menu items. So I do not expect this to be an exact fit, but it may provide a clue to another solution. h:form id=navForm2 t:panelNavigation2 id=pn2_list layout=list ... t:commandNavigation2 id=cn2_p2 action=page_2 h:graphicImage url=/images/icon2.jpg / h:outputText value=Page 2 / /t:commandNavigation2 ... /t:panelNavigation2 /h:form Paul Spencer chintan wrote: Hi, I am using panelNavigation2 tag to display panle navigation menu. This tag uses NavigationMenuItem class of Tomahawk. My problem is, I am not able to dispaly icon and label both together eventhough i have used NavigationMenuItem () constructor with above parameters. At a time i can displayd either label or icon. Is this bug in Tomahawk implementation or I am missing something. Pleae treat it is as an urgent. Thanks Chintan
Re: I am working on a Selenium test suite.
Wendy, Whoops, I used snapshot instead of sandbox. While I was working on the test suite, I thought about having one test suite for MyFaces and one for Tomahawk instead of one in Tomahawk that includes MyFaces tests. Wherever the test suite(s) end up, they should be a Maven project, like Tomahawk's Simple Example. So, where should the test suite(s) be added and what should they be named? BTW: Running the test on HostedQA is taking a while, any ideas why? Paul Spencer Wendy Smoak wrote: On 11/25/06, Paul Spencer [EMAIL PROTECTED] wrote: At this point I have committed none of the tests, but I would like to commit them soon. 1) Where is the best place to add them? I suspect the best place add this is myfaces/tomahawk/snapshot. 2) What should the artifactId be? Currently it is myfaces-snapshot-testing. First, thanks for taking this on! Why not add these tests to one of the existing apps? The word 'snapshot' has a special meaning in Maven, that doesn't seem to apply here-- if it does have to be separate, this would be another example app that we could ship, both to demonstrate how to use the components and encourage this sort of testing. -- Wendy
Re: I am working on a Selenium test suite.
Wendy, See below. Wendy Smoak wrote: On 11/25/06, Paul Spencer [EMAIL PROTECTED] wrote: Whoops, I used snapshot instead of sandbox. From that I would assume that these are tests for the Tomahawk Sandbox components, which I don't think is the case. While I was working on the test suite, I thought about having one test suite for MyFaces and one for Tomahawk instead of one in Tomahawk that includes MyFaces tests. Wherever the test suite(s) end up, they should be a Maven project, like Tomahawk's Simple Example. So, where should the test suite(s) be added and what should they be named? I'm resistant to adding another webapp module, especially to Core which doesn't currently have any. My preference is to add these pages and tests to the existing 'simple' app. That said, I'm not the one doing the work. :) Not a problem adding the test to the examples. I would prefer to group them in a subdirectory. Any suggestions for a name of that subdirectory? testSuite? BTW: Running the test on HostedQA is taking a while, any ideas why? They run in a virtual server, so it takes a while to set up. If you're going to be running them repeatedly, I think there's a way to start the virtual server once so it will be there. Send a note to the support address if you have any questions, Patrick [Lightbody] will be happy to help. I'd suggest running the tests locally with the Selenium TestRunner while you're working out the details. Then we can schedule Continuum to run them at HostedQA periodically. I do run them locally. Paul Spencer
Re: I am working on a Selenium test suite.
Wendy Smoak wrote: On 11/25/06, Paul Spencer [EMAIL PROTECTED] wrote: Not a problem adding the test to the examples. I would prefer to group them in a subdirectory. Any suggestions for a name of that subdirectory? testSuite? There are two parts to this, right? The tests, and the companion JSPs. IMO, the tests, (the html pages with tables that are the Selenium tests,) should go under src/test/selenium. That's how things are set up in pom.xml now, at least. Correct, I would not change that. I don't have a strong preference for where you put the JSPs (and they can always be moved around later if anyone objects to what you pick.) Fair enough. I will create a testSuite and place the jsp file their. Thanks, Paul Spencer
Re: AW: I am working on a Selenium test suite.
Andreas, Please refer to the file HowToAddATest.html [1]. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/testSuite/HowToAddATest.html?view=markup Andreas Berger wrote: I'm currently working on the XML files for automaticly generation of the components and tags (JSF 1.2). Additionally I'm developing some enhancements for the generator. Maybe It's a good idea to generate also testcases from the XML's. I dont know the format, but if you got an example I can have a look at what's possible. Cheers Andreas -Ursprüngliche Nachricht- Von: Paul Spencer [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 25. November 2006 23:01 An: MyFaces Development Betreff: I am working on a Selenium test suite. I have started writing a Selenium test suite. I have the following goals: 1) Provide a regression test environment. 2) Further my understanding on how the JSF components work. 3) Provide a simplified set of examples. 4) Provide a platform for easily developing a test case for a bug. Currently I have implemented only a few of the tags, like h:panelGrid and t:panelNavigation2, but I intend on adding many more. The test include a jsp page that sets many of the attribute for each tag and a Selenuim script that verifies the resulting HTML and functionality. I have tried to minimize the amount of java code need to implement each tag, this keeps the test cases very simple. Although much of this replicates what is currently in Tomahawk Examples, it does not rely on stylesheets or dynamically generated components. I have run the test on HostedQA [1] so the results are publicly available. The test are run against IE 7 and Firefox. Currently IE7 is failing parts of the test, I suspect the failure have to do with how the test are address elements in the dom. At this point I have committed none of the tests, but I would like to commit them soon. 1) Where is the best place to add them? I suspect the best place add this is myfaces/tomahawk/snapshot. 2) What should the artifactId be? Currently it is myfaces-snapshot-testing. Paul Spencer [1] https://myfaces.hostedqa.com/project/122/session/suite/list
Are HostedQA and Selenium version in sync?
We are a little behind on plugin versions for Selenium and HostedQA. I am bring this up because : 1) I am seeing failures on the HostedQA's site that I do not see when running the same test locally. 2) Sometimes mvn package -P hostedqa fails when all of the results are Passed. 3) Sometimes mvn package -P hostedqa runs for a very long time (1 hour+) without completing. I usually kill it believing it to be hung. Plugin Version Current - - selenium-core0.7.0 0.8.1 hostedqa-remote-ant 1.6.2 1.7.0 HostedQA is running 1.7.4-Beta Is their a reason not to upgrade the plugin to the latest? Paul Spencer
Re: Are HostedQA and Selenium version in sync?
Wendy, I have updated the plugins, although not commited it, but the problems remain. How do we contact HostedQA for support? Paul Spencer Wendy Smoak wrote: On 11/27/06, Paul Spencer [EMAIL PROTECTED] wrote: We are a little behind on plugin versions for Selenium and HostedQA. ... Is their a reason not to upgrade the plugin to the latest? No reason I can think of, go ahead.
How to associate subversion commit a Jira Issue?
What do I need to do when committing so the commit is associated with a Jira Issue ? As an example, see TOBAGO-201 [1]. Paul Spencer [1] http://issues.apache.org/jira/browse/TOBAGO-201?page=all
Building examples against RI now works.
I have patched the Tomahawk Examples POM to allow the sub projects to be built with the Sun RI v1.1_02 instead of MyFaces. To do this, simply add -Djsf=ri to the mvn command line. As an example, to build and run simple example using the Sun RI issue the following command from tomahawk/examples/simple directory. mvn clean package cargo:start -P selenium -Djsf=ri You can this point the browser to th following URL to run the Selenium test suite: http://localhost:8080/myfaces-example-simple/selenium/core/TestRunner.html Paul Spencer
Re: svn commit: r481981 - in /myfaces/tomahawk/trunk/examples/simple/src: main/webapp/WEB-INF/ main/webapp/testSuite/ test/selenium/
Wendy, I thought I had already done it. I have update the properties on the files and will verify my environment. Paul Spencer Wendy Smoak wrote: New text files need to at least have the svn:eol-style property set to native. See: http://www.apache.org/dev/version-control.html#https-svn and 'Configuring the Client' on http://wiki.apache.org/struts/StrutsMaintenanceSvn Thanks,
Re: [jira] Created: (MYFACES-1505) Attribute acceptCharset is incorrect for the tag h:form in Myface's TLD. It should be acceptcharset
Should this be a blocker? Paul Spencer Paul Spencer (JIRA) wrote: Attribute acceptCharset is incorrect for the tag h:form in Myface's TLD. It should be acceptcharset Key: MYFACES-1505 URL: http://issues.apache.org/jira/browse/MYFACES-1505 Project: MyFaces Core Issue Type: Sub-task Components: JSR-127 Reporter: Paul Spencer The attribute acceptCharset is incorrect in Myfaces TLD for the tag h:form. It should be acceptcharset. The Selenium test case testSuite/hForm.jsp is currently failing because of this. See http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/tlddocs/h/form.html
Re: svn commit: r482726 - in /myfaces/core/trunk/api/src/main/java/javax/faces: component/ webapp/
Grant,
I noticed some of the castings you removed where from generated code.
Is the code generate still in use? If so, does it need to be fixed?
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: grantsmith
Date: Tue Dec 5 10:02:43 2006
New Revision: 482726
URL: http://svn.apache.org/viewvc?view=revrev=482726
Log:
removed redundant casting some code cleanup
Modified:
myfaces/core/trunk/api/src/main/java/javax/faces/component/UICommand.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIData.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIGraphic.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIInput.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIMessage.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIMessages.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIOutput.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIParameter.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UISelectBoolean.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UISelectItem.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UISelectItems.java
myfaces/core/trunk/api/src/main/java/javax/faces/component/UISelectOne.java
myfaces/core/trunk/api/src/main/java/javax/faces/webapp/FacesServlet.java
Modified:
myfaces/core/trunk/api/src/main/java/javax/faces/component/UICommand.java
URL:
http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/component/UICommand.java?view=diffrev=482726r1=482725r2=482726
==
--- myfaces/core/trunk/api/src/main/java/javax/faces/component/UICommand.java
(original)
+++ myfaces/core/trunk/api/src/main/java/javax/faces/component/UICommand.java
Tue Dec 5 10:02:43 2006
@@ -170,7 +170,7 @@
{
if (_value != null) return _value;
ValueBinding vb = getValueBinding(value);
-return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
+return vb != null ? vb.getValue(getFacesContext()) : null;
}
@@ -183,7 +183,7 @@
values[2] = saveAttachedState(context, _actionListener);
values[3] = _immediate;
values[4] = _value;
-return ((Object) (values));
+return values;
}
public void restoreState(FacesContext context, Object state)
@@ -193,7 +193,7 @@
_action = (MethodBinding)restoreAttachedState(context, values[1]);
_actionListener = (MethodBinding)restoreAttachedState(context,
values[2]);
_immediate = (Boolean)values[3];
-_value = (Object)values[4];
+_value = values[4];
}
//-- GENERATED CODE END
---
}
Modified: myfaces/core/trunk/api/src/main/java/javax/faces/component/UIData.java
URL:
http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIData.java?view=diffrev=482726r1=482725r2=482726
==
--- myfaces/core/trunk/api/src/main/java/javax/faces/component/UIData.java
(original)
+++ myfaces/core/trunk/api/src/main/java/javax/faces/component/UIData.java Tue
Dec 5 10:02:43 2006
@@ -1020,7 +1020,7 @@
if (_value != null)
return _value;
ValueBinding vb = getValueBinding(value);
-return vb != null ? (Object) vb.getValue(getFacesContext()) : null;
+return vb != null ? vb.getValue(getFacesContext()) : null;
}
//-- GENERATED CODE END ---
Modified:
myfaces/core/trunk/api/src/main/java/javax/faces/component/UIGraphic.java
URL:
http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIGraphic.java?view=diffrev=482726r1=482725r2=482726
==
--- myfaces/core/trunk/api/src/main/java/javax/faces/component/UIGraphic.java
(original)
+++ myfaces/core/trunk/api/src/main/java/javax/faces/component/UIGraphic.java
Tue Dec 5 10:02:43 2006
@@ -96,7 +96,7 @@
{
if (_value != null) return _value;
ValueBinding vb = getValueBinding(value);
-return vb != null ? (Object)vb.getValue(getFacesContext()) : null;
+return vb != null ? vb.getValue(getFacesContext()) : null;
}
@@ -105,14 +105,14 @@
Object values[] = new Object[2];
values[0] = super.saveState(context);
values[1] = _value;
-return ((Object) (values));
+return values;
}
public void restoreState(FacesContext context, Object state)
{
Object values[] = (Object[])state;
super.restoreState(context, values[0]);
-_value = (Object)values[1];
+_value = values[1];
}
//-- GENERATED CODE
MyFaces 1.1.5 release status?
What is the status of MyFaces 1.1.5 release? The only blocker is MYFACES-1488 [1]. I know Grant updated the license text on many source file related to issue, so has this issue been resolved? Paul Spencer [1] http://issues.apache.org/jira/browse/MYFACES-1488
Re: MyFaces 1.1.5 release status?
I reviewed the checkstyle reports for MyFaces and Tomahawk projects. As a result, I updated the license header in some of the java files. Unfortunately generated files, specifically the shared files, are not checked by checkstyle. I suspect checkstyle can be configured to check the these files, but I do not have the time right now to figure it out. Paul Spencer Wendy Smoak wrote: On 12/6/06, Grant Smith [EMAIL PROTECTED] wrote: My understanding was that the blocker portion of this issue related to the changing of the headers, which has been done. Adding the copyright notice to the NOTICE files I have missed but that is trivial and will be done in the next few minutes. Thanks. As long as the existing license headers and notice files are fixed, let's close this issue and open another one to deal with the RAT output later when someone has time. Isn't there also something that needs to be done for exporting cryptography?
Re: MyFaces 1.1.5 release status?
I reviewed the checkstyle reports for MyFaces and Tomahawk projects. As a result, I updated the license header in some of the java files. Unfortunately generated files, specifically the shared files, are not checked by checkstyle. I suspect checkstyle can be configured to check the these files, but I do not have the time right now to figure it out. Paul Spencer Wendy Smoak wrote: On 12/6/06, Grant Smith [EMAIL PROTECTED] wrote: My understanding was that the blocker portion of this issue related to the changing of the headers, which has been done. Adding the copyright notice to the NOTICE files I have missed but that is trivial and will be done in the next few minutes. Thanks. As long as the existing license headers and notice files are fixed, let's close this issue and open another one to deal with the RAT output later when someone has time. Isn't there also something that needs to be done for exporting cryptography?
Re: [continuum] BUILD FAILURE: Tomahawk Project
Is someone looking into this?
Paul Spencer
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/15/buildId/7246
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue, 12 Dec 2006 19:07:29 +
Finished at: Tue, 12 Dec 2006 19:07:39 +
Total time: 9s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: myfaces.zones.apache.org
Operating system : SunOS(unknown)
Java version : 1.5.0_09(Sun Microsystems Inc.)
Changes
paulsp TOMAHAWK-809 - Exclude all test suites (Hosted QA can
not run a test suite)
Exclude FireFox specific tests (All Test are being run against
IE and FF)
/myfaces/tomahawk/trunk/examples/pom.xml
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Tomahawk Project
[INFO]task-segment: [clean, install, deploy]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/15/target
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/15/target/classes
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/15/target/test-classes
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-source}]
[INFO] NOT adding sources to attached artifacts for packaging: 'pom'.
[INFO] [install:install]
[INFO] Installing
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/15/pom.xml to
/export/home/mrmaven/.m2/repository/org/apache/myfaces/tomahawk/tomahawk-project/1.1.5-SNAPSHOT/tomahawk-project-1.1.5-SNAPSHOT.pom
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-source}]
[INFO] NOT adding sources to attached artifacts for packaging: 'pom'.
[INFO] [install:install]
[INFO] Installing
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/15/pom.xml to
/export/home/mrmaven/.m2/repository/org/apache/myfaces/tomahawk/tomahawk-project/1.1.5-SNAPSHOT/tomahawk-project-1.1.5-SNAPSHOT.pom
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache.snapshots
Uploading:
scpexe://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-project/1.1.5-SNAPSHOT/tomahawk-project-1.1.5-SNAPSHOT.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact: Exit code: 1 - scp:
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/tomahawk/tomahawk-project/1.1.5-SNAPSHOT/tomahawk-project-1.1.5-SNAPSHOT.pom:
Permission denied
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Tue Dec 12 19:07:38 GMT+00:00 2006
[INFO] Final Memory: 8M/324M
[INFO]
Running HostedQA test in Continuium?
What need to be done to run the HostedQA tests in Continuium? A) Determine what is to be tested: Some Options 1) Run the test against IE and FireFox clients. Pro: Tests both browser Con: Some functionality can not be tested. 2) Run the test against FireFox only. Pro: More functionality will be test. Con: We will not know if their is a problem in IE unless the test is manually run against IE. 3) Run 2 set of test, IE only and FireFox only. Pro: All test can be run. Con: Need to determine how to configure. The reason for the options is the current configuration support running one set of test against a set of client(s). Some of the test will fail on IE because of compatibility issues between IE and Selenium. These test are I am calling FireFox test. Currently their are no test that pass under IE and fail under Firefox. B) Continuium configuration Currently I do not have karma on the Continium sever, so I do not know what this entails. Paul Spencer
Re: [jira] Commented: (MYFACES-1510) h:form does not render accept-charset
Grant, I am getting the following error when running the tests or the examples: java.lang.NullPointerException at org.apache.myfaces.shared_impl.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:110) You added if(acceptCharset.compareTo()!=0) should it be if((acceptCharset != null) (acceptCharset.compareTo()!=0)) ? Paul Spencer Grant Smith (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-1510?page=comments#action_12457891 ] Grant Smith commented on MYFACES-1510: -- Hmm.. I don't see how MYFACES-1505 would cause accept-charset to be rendered in the form though. I do see how it is always now rendered with a blank value regardless of the acceptcharset value, but that seems to be a bug. I just committed a change that will prevent rendering the blank value, but it doesn't fix why the attribute isnt being recognized. I'll have to debug later when I have a bit more time. Meanwhile, it seems as if the tests are passing, did you change them perhaps ? (p.s. sorry I meant to say attribute instead of tag in my previous comment) h:form does not render accept-charset - Key: MYFACES-1510 URL: http://issues.apache.org/jira/browse/MYFACES-1510 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: n/a Reporter: Harlan Iverson Assigned To: Grant Smith Fix For: 1.1.5-SNAPSHOT Attachments: acceptcharset.patch The HtmlFormRendererBase class does not render the accept-charset attribute.
MyFaces 1.1.5 Release Status?
This is yet another release status request. Current open issue with a Fix Version = 1.1.5-SNAPSHOT MYFACES-1372h:messages not shown (- not working) ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1372h:messages not shown (- not working) is important, but it's been broken for 18 months. It's not a regression as far as I know. MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete MYFACES-1411Lifecycle phase executions repetitions ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1411 has I.P. issues. MYFACES-1506Translated messages in Messages.properties files ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, this is a Tomahawk issue, not a MyFaces one. Should be moved. Not sure how Messages.properties interacts with Tomahawk, though. None of the above issue are marked as blockers. Are any of the actually blockers to the 1.1.5 release? What is holding up this release? Paul Spencer
Re: svn commit: r483569 - in /myfaces: shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/ tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/ tomahawk/trunk
This broke the examples!
Specifically line 950 and 951 are throwing NPE when the attributes style and
styleClass are node defined.
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: mmarinschek
Date: Thu Dec 7 09:49:35 2006
New Revision: 483569
URL: http://svn.apache.org/viewvc?view=revrev=483569
Log:
added inBodyStart hook for overriding attributes of body (i.e. style and
styleClass)
Modified:
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlTableRenderer.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/taglib/html/ext/HtmlDataTableTag.java
Modified:
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
URL:
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java?view=diffrev=483569r1=483568r2=483569
==
---
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
(original)
+++
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
Thu Dec 7 09:49:35 2006
@@ -129,6 +129,7 @@
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TBODY_ELEM, component);
writer.writeAttribute(HTML.ID_ATTR,
component.getClientId(facesContext)+:tbody_element, null);
+inBodyStart(facesContext, (UIData) component);
encodeInnerHtml(facesContext, component);
@@ -316,8 +317,8 @@
* @param writer the codeResponseWriter/code.
* @param uiData the codeUIData/code being rendered.
* @param component the codeUIComponent/code to render.
- * @param columnStyleIterator the styleClass of the codeUIColumn/code or
codenull/code if
- * there is none.
+ * @param styles the styleClasses of rows and columns
+ * @param columnStyleIndex the index of the column
* @throws IOException if an exception occurs.
*/
protected void renderColumnBody(
@@ -342,7 +343,8 @@
* @param facesContext the codeFacesContext/code.
* @param writer the codeResponseWriter/code.
* @param uiData the codeUIData/code being rendered.
- * @param rowStyleIterator te styleClass of the row or codenull/code
if there is none.
+ * @param styles the styleClasses of rows and columns
+ * @param rowStyleIndex the index of the row
* @throws IOException if an exceptoin occurs.
*/
protected void renderRowStart(
@@ -392,6 +394,7 @@
*
* @param facesContext the codeFacesContext/code.
* @param uiData the codeUIData/code being rendered.
+ * @throws java.io.IOException
*/
protected void beforeTable(FacesContext facesContext, UIData uiData)
throws IOException
{
@@ -478,6 +481,17 @@
protected void afterColumnHeaderOrFooter(FacesContext facesContext, UIData
uiData, boolean header, int columnIndex) throws IOException
{
}
+
+/**
+ * Perform any operations necessary in the TBODY start tag.
+ *
+ * @param facesContext the codeFacesContext/code.
+ * @param uiData the codeUIData/code being rendered.
+ */
+protected void inBodyStart(FacesContext facesContext, UIData uiData)
throws IOException
+{
+}
+
/**
* Perform any operations necessary immediately after the TBODY end tag
* is output.
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java?view=diffrev=483569r1=483568r2=483569
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
Thu Dec 7 09:49:35 2006
@@ -95,6 +95,8 @@
private String _rowGroupStyle = null;
private String _rowGroupStyleClass = null;
private String _varDetailToggler = null;
+private String _bodyStyleClass = null;
+private String _bodyStyle = null;
private int _sortColumnIndex = -1;
@@ -769,7 +771,7 @@
{
boolean preserveSort = isPreserveSort();
-Object values[] = new Object[34];
+Object values[] = new Object[36];
values[0] = super.saveState(context);
values[1] = _preserveDataModel;
@@ -817,6 +819,8 @@
values[32] = new Integer(_newspaperColumns);
values[33
Re: svn commit: r483569 - TLD and Docs?
I do not see any related commits to the TLD.
Docs?
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: mmarinschek
Date: Thu Dec 7 09:49:35 2006
New Revision: 483569
URL: http://svn.apache.org/viewvc?view=revrev=483569
Log:
added inBodyStart hook for overriding attributes of body (i.e. style and
styleClass)
Modified:
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlTableRenderer.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/taglib/html/ext/HtmlDataTableTag.java
Modified:
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
URL:
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java?view=diffrev=483569r1=483568r2=483569
==
---
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
(original)
+++
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlTableRendererBase.java
Thu Dec 7 09:49:35 2006
@@ -129,6 +129,7 @@
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TBODY_ELEM, component);
writer.writeAttribute(HTML.ID_ATTR,
component.getClientId(facesContext)+:tbody_element, null);
+inBodyStart(facesContext, (UIData) component);
encodeInnerHtml(facesContext, component);
@@ -316,8 +317,8 @@
* @param writer the codeResponseWriter/code.
* @param uiData the codeUIData/code being rendered.
* @param component the codeUIComponent/code to render.
- * @param columnStyleIterator the styleClass of the codeUIColumn/code or
codenull/code if
- * there is none.
+ * @param styles the styleClasses of rows and columns
+ * @param columnStyleIndex the index of the column
* @throws IOException if an exception occurs.
*/
protected void renderColumnBody(
@@ -342,7 +343,8 @@
* @param facesContext the codeFacesContext/code.
* @param writer the codeResponseWriter/code.
* @param uiData the codeUIData/code being rendered.
- * @param rowStyleIterator te styleClass of the row or codenull/code
if there is none.
+ * @param styles the styleClasses of rows and columns
+ * @param rowStyleIndex the index of the row
* @throws IOException if an exceptoin occurs.
*/
protected void renderRowStart(
@@ -392,6 +394,7 @@
*
* @param facesContext the codeFacesContext/code.
* @param uiData the codeUIData/code being rendered.
+ * @throws java.io.IOException
*/
protected void beforeTable(FacesContext facesContext, UIData uiData)
throws IOException
{
@@ -478,6 +481,17 @@
protected void afterColumnHeaderOrFooter(FacesContext facesContext, UIData
uiData, boolean header, int columnIndex) throws IOException
{
}
+
+/**
+ * Perform any operations necessary in the TBODY start tag.
+ *
+ * @param facesContext the codeFacesContext/code.
+ * @param uiData the codeUIData/code being rendered.
+ */
+protected void inBodyStart(FacesContext facesContext, UIData uiData)
throws IOException
+{
+}
+
/**
* Perform any operations necessary immediately after the TBODY end tag
* is output.
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java?view=diffrev=483569r1=483568r2=483569
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/HtmlDataTable.java
Thu Dec 7 09:49:35 2006
@@ -95,6 +95,8 @@
private String _rowGroupStyle = null;
private String _rowGroupStyleClass = null;
private String _varDetailToggler = null;
+private String _bodyStyleClass = null;
+private String _bodyStyle = null;
private int _sortColumnIndex = -1;
@@ -769,7 +771,7 @@
{
boolean preserveSort = isPreserveSort();
-Object values[] = new Object[34];
+Object values[] = new Object[36];
values[0] = super.saveState(context);
values[1] = _preserveDataModel;
@@ -817,6 +819,8 @@
values[32] = new Integer(_newspaperColumns);
values[33] = _newspaperOrientation;
+values[34] = _bodyStyle;
+values[35] = _bodyStyleClass
Advice regarding a Proposal to switch MyFaces to a Tomcat style of release.
I would like to propose that MyFaces switch to a Tomcat style of release[1]. Specifically a release is cut when specific conditions are met, then the PMC sets its status, alpha/beta/stable. The conditions could include the following: 1) All tests pass. 2) All examples work. 3) Passed a functional milestone. (Yes, this subjective) As to the status of a release, the release is considered Alpha until updated by the PMC. The chart below describes each status. Status Description --- --- Alpha Same as Tomcat BetaSame as Tomcat + Passes TCK Stable Same as Tomcat. Only a stable release is patchable after it has been release. In addition upgrade paths would be from stable release to stable release. I am proposing this for the following reasons: 1) Eliminate the need to stage the release then perform an actual release. This can wreck havoc on a devaloper's Maven repository. 2) Lower the barrier to a release while NOT lowering the standard of a Stable release. 3) Display visible progress to the user community. 4) Minimize the dependencies on snapshots by application developers. My intent is to make the process better and improve MyFaces, not to stir up trouble or step on any bodies toes. Paul Spencer [1] http://tomcat.apache.org/whichversion.html
Re: MyFaces 1.1.5 Release Status?
Thomas, I sent a few posts relative to Revision: 483569 this morning. That revision has broken Tomahawk. I am hoping the commiter will resolve the problem quickly. Paul Spencer Thomas Spiegl wrote: tomahawk 1.1.4 branch is quite out of date by now. I'd like to skip this one, and start releasing core and tomahawk 1.1.5 asap. On 12/18/06, Paul Spencer [EMAIL PROTECTED] wrote: This is yet another release status request. Current open issue with a Fix Version = 1.1.5-SNAPSHOT MYFACES-1372h:messages not shown (- not working) ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1372h:messages not shown (- not working) is important, but it's been broken for 18 months. It's not a regression as far as I know. MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete MYFACES-1411Lifecycle phase executions repetitions ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1411 has I.P. issues. MYFACES-1506Translated messages in Messages.properties files ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, this is a Tomahawk issue, not a MyFaces one. Should be moved. Not sure how Messages.properties interacts with Tomahawk, though. None of the above issue are marked as blockers. Are any of the actually blockers to the 1.1.5 release? What is holding up this release? Paul Spencer
Missing package net.sf.maventaglib.checker causing Continuum Tomahawk build failure!
The Tomahawk Build by Continuuum is failing due to: [INFO] Compilation failure /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java:[22,34] package net.sf.maventaglib.checker does not exist I suspect their is missing dependency. Paul Spencer
Re: Missing package net.sf.maventaglib.checker causing Continuum Tomahawk build failure!
Dennis, Both, locally and on the Continuum server. Paul Spencer Dennis Byrne wrote: The dependency is in the pom and it runs fine locally. Are you having problems locally or is this just a problem on the Continuum server? Dennis Byrne -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Saturday, December 30, 2006 11:59 AM To: 'MyFaces Development' Subject: Missing package net.sf.maventaglib.checker causing Continuum Tomahawk build failure! The Tomahawk Build by Continuuum is failing due to: [INFO] Compilation failure /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java:[22,34] package net.sf.maventaglib.checker does not exist I suspect their is missing dependency. Paul Spencer
Re: Missing package net.sf.maventaglib.checker causing Continuum Tomahawk build failure!
Dennis, Both, locally and on the Continuum server. Paul Spencer Dennis Byrne wrote: The dependency is in the pom and it runs fine locally. Are you having problems locally or is this just a problem on the Continuum server? Dennis Byrne -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Saturday, December 30, 2006 11:59 AM To: 'MyFaces Development' Subject: Missing package net.sf.maventaglib.checker causing Continuum Tomahawk build failure! The Tomahawk Build by Continuuum is failing due to: [INFO] Compilation failure /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java:[22,34] package net.sf.maventaglib.checker does not exist I suspect their is missing dependency. Paul Spencer
Re: svn commit: r491266 - /myfaces/tomahawk/trunk/core/pom.xml
Dennis, Continuum did fail after you commit. The message is dated Sat, 30 Dec 2006 04:41:00 GMT Thanks for the commit, the build now works. Paul Spencer [EMAIL PROTECTED] wrote: Author: dennisbyrne Date: Sat Dec 30 10:23:24 2006 New Revision: 491266 URL: http://svn.apache.org/viewvc?view=revrev=491266 Log: forgot to commit dependency - why did Continuum fail on Paul's commit and not mine? Modified: myfaces/tomahawk/trunk/core/pom.xml Modified: myfaces/tomahawk/trunk/core/pom.xml URL: http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/pom.xml?view=diffrev=491266r1=491265r2=491266 == --- myfaces/tomahawk/trunk/core/pom.xml (original) +++ myfaces/tomahawk/trunk/core/pom.xml Sat Dec 30 10:23:24 2006 @@ -212,7 +212,12 @@ scopetest/scope /dependency - +dependency + groupIdmaven-taglib/groupId + artifactIdmaven-taglib-plugin/artifactId + version1.4.2/version + scopetest/scope +/dependency /dependencies
Re: Patch Branch?
Is their a reason NOT to release 1.1.5? Based on a Tomcat style release model I purposed earlier [1] we can label this release Alpha status and change it's status later. Assuming the current source is stable, which it appeared to be as of this weekend, we can release it meets the requirement for Alpha status. Advantages: 1) Mitigates the need for a 1.1.4.1 branch. 2) No need to run the TCK prior to the release. 3) A release is a sign of progress to the community. 4) Allows Maven based project currently using 1.1.5 functionality a version of MyFaces they can use in a release. (I am in this position) Paul Spencer [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg19257.html Stan Silvert wrote: Are we maintaining a service pack type of branch for MyFaces 1.1.4 core? There is a critical portlet bug that is fixed in 1.1.5, but I don't think we are planning a 1.1.5 release any time soon. What do you guys think of starting an SP branch for critical fixes (if we don't already have one)? Stan Silvert JBoss, a division of RedHat [EMAIL PROTECTED]
Re: Patch Branch?
Dennis Byrne wrote: Hi Paul, 1) Mitigates the need for a 1.1.4.1 branch. There is still some small value for orgs that want the one fix w/out the inherit risk that comes with a new release of any piece of software. I do agree with you that a 1.1.5 release would be a better use of resources though. I have no objections to a 1.1.4.1 bug fix release. 2) No need to run the TCK prior to the release. Why would we no longer need this? Did Thomas ever get this running automated? I have no idea if the TCK has been automated. If the TCK is, or can be run by Continuum, then that would be a great was of keeping bugs out of the source. BTW: I have been, slowly, adding unit and Selenium tests to Tomahawk. Paul Spencer Dennis Byrne
Re: Patch Branch?
Mike Kienenberger wrote: [release 1.1.5 now instead] 1) Mitigates the need for a 1.1.4.1 branch. Not really. In all likelihood, there are always going to be bugs in the latest release since new features are constantly being worked on. Users want to have access to a bug-fix release that does not add new features. Point taken. 2) No need to run the TCK prior to the release. We have to run the TCK on all releases, whether 1.1.5 or 1.1.4.1. I understand this for release we announce as stable, but can we cut a release we believe will pass the TCK, and only announce it as stable after it passes the TCK. Granted we may have gaps in the list of stable version number, but this is what tomcat does today. 3) A release is a sign of progress to the community. From the email I've received both on and off list, the community would consider bug fix releases a more practical sign of progress. Point taken. 4) Allows Maven based project currently using 1.1.5 functionality a version of MyFaces they can use in a release. (I am in this position) Irrelevent. Having a bug fix release of 1.1.4.1 should not impact a release of 1.1.5. Point taken. snip Paul Spencer
Status of Issue MYFACES-1411 (was Re: Patch Branch?)
Wendy, Is this a blocker or just one we really would like to have fixed prior to a 1.1.5 release? If it is a blocker, please update the issue accordingly. Paul Spencer Wendy Smoak wrote: On 1/4/07, Paul Spencer [EMAIL PROTECTED] wrote: Is their a reason NOT to release 1.1.5? Yes. There are still open issues for 1.1.5. MYFACES-1411 is the one that concerns me. I'm not familiar with the situation, I just flagged it as a contribution of new classes with no CLA on file.
Is the border attribute missing from h:selectManyCheckbox ?
Is the border attribute missing from h:selectManyCheckbox ? The selenium test case /myfaces-example-simple/testSuite/hFormWithSelects.jsf passes under with Sun's RI, but fails with MyFaces because the border attribute is missing from h:selectManyCheckbox Paul Spencer
Re: [VOTE] dojo upgrade 0.4.1
+1 to upgrade dojo to 0.4.1 Paul Spencer Werner Punz wrote: I just opened an official vote thread since this is an upgrade on the Tomahawk core. I ran some tests to test dojo 0.4.1, and I think we can move the codebase from 0.4.0. to 0.4.1 Since this is a major upgrade on the Tomahawk core. I wanted to open this official vote thread. So if no one has objections we could now push the 0.4.1 bugfix release in. Werner
Re: [INFO] myfaces core release 1.1.5 procedure started
:) Thank You Paul Spencer Manfred Geiler wrote: FYI I have just started preparing the core release 1.1.5. See http://wiki.apache.org/myfaces/CoreRelease115#diary for details on the proceedings. --Manfred
Comments/questions about the use of snapshot dependencies during the release process.
Should the versions of maven-project be set to 1.0.5 for all projects, not 1.0.6-SNAPSHOT? I have a similar same question for all dependent projects. IMHO we should not add a SNAPSHOT dependency until their their is a change from the released version of the dependency. This will minimize the number of projects to released. Thus at the end of the release process, only the following SNAPSHOT dependencies should exist: shared-core myfaces-impl tomahawk-impl any project dependent on the above In addition the snapshot dependency should not be add until AFTER the release is cut. Paul Spencer
Re: Question regarding adding a new verification task
I believe this is what Martin is referring to the Tomahawk test MyFacesTagLibTestCase[1]. BTW: It looks like the verification of the sandbox taglibs was commented out. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java?view=markup Martin Marinschek wrote: There was someone who wrote an automatic test to check for this - I don't remember who and when that was, though. Can you have a look into the test directories and check? Maybe you can extend one of the test-classes instead of writing a new utility? regards, Martin On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it.
Re: Question regarding adding a new verification task
IMHO Tomahawk should NOT require the sandbox tld passes the test, thus 1) do not uncomment the line 2) do remove the TODO 3) Configure tomahawk's maven to create at test jar 4) Configure sandbox's maven to use tomahawk's test jar. 5) Create an sandbox test that extends AbstractTagLibTestCase Please wait until after the 1.1.5 release to do this! Paul Spencer [1]http://maven.apache.org/guides/mini/guide-attached-tests.html Dennis Byrne wrote: When it came time to commit it, including the sandbox wasn't realistic. There were a lot of failures. Dennis Byrne On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: I believe this is what Martin is referring to the Tomahawk test MyFacesTagLibTestCase[1]. BTW: It looks like the verification of the sandbox taglibs was commented out. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/MyFacesTagLibTestCase.java?view=markup Martin Marinschek wrote: There was someone who wrote an automatic test to check for this - I don't remember who and when that was, though. Can you have a look into the test directories and check? Maybe you can extend one of the test-classes instead of writing a new utility? regards, Martin On 2/6/07, Werner Punz [EMAIL PROTECTED] wrote: Hi Since I am currently working on fixing a lot of missing references in the sandbox Taglib classes. (Some people including me used a lot of includes from entities resulting in several missing attribute implementations) I am going to write, since this seems to be the most obvious way, a program which checks the generated component tlds via introspection against the taglib classes for those references. If anyone is willing, to integrate it into maven once I am done please drop a note here. Otherwise is there maybe already a check in maven which does this test? Tomcat is unable to check it as it seems, although I turned on tldValidation it did not report errors which were there. Also most other app server skip it, but weblogic does not and it is correct that it does not skip it.
Re: Comments/questions about the use of snapshot dependencies during the release process.
Manfred Geiler wrote: On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: snip IMHO we should not add a SNAPSHOT dependency until their their is a change from the released version of the dependency. This will minimize the number of projects to released. Thus at the end of the release process, only the following SNAPSHOT dependencies should exist: See above. There are no officially available non-SNAPSHOT releases for maven-project or shared or core yet. In addition the snapshot dependency should not be add until AFTER the release is cut. Same problem and additional danger here: Imagine a developer changes something and forgets to increase the version number of the artifact from x.y.z to x.y.z-SNAPSHOT. If he does a mvn install (or a mvn deploy!!!) he will have a total version chaos in his local repo: He will have local artifacts with version x.y.z that differ to the official released artifacts with the same version number! See description of the maven release plugin [1] for best practice and to learn how others are doing. The version of the artifact should be a SNAPSHOT for the above reason. I am referring to how the artifact is used. As an example, Tomahawk v1.1.5 will be dependent on maven-project v2.0.5. My comment was related to Tomahawk v1.1.6-SNAPSHOT. Should it be dependent on maven-project v2.0.5 or v2.0.6-SNAPSHOT? --Manfred [1] http://maven.apache.org/plugins/maven-release-plugin/ Paul Spencer
Re: Comments/questions about the use of snapshot dependencies during the release process.
Manfred, See below. Manfred Geiler wrote: inline On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: Manfred Geiler wrote: On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: snip IMHO we should not add a SNAPSHOT dependency until their their is a change from the released version of the dependency. This will minimize the number of projects to released. Thus at the end of the release process, only the following SNAPSHOT dependencies should exist: See above. There are no officially available non-SNAPSHOT releases for maven-project or shared or core yet. In addition the snapshot dependency should not be add until AFTER the release is cut. Same problem and additional danger here: Imagine a developer changes something and forgets to increase the version number of the artifact from x.y.z to x.y.z-SNAPSHOT. If he does a mvn install (or a mvn deploy!!!) he will have a total version chaos in his local repo: He will have local artifacts with version x.y.z that differ to the official released artifacts with the same version number! See description of the maven release plugin [1] for best practice and to learn how others are doing. The version of the artifact should be a SNAPSHOT for the above reason. I am referring to how the artifact is used. As an example, Tomahawk v1.1.5 will be dependent on maven-project v2.0.5. My comment was related to Tomahawk v1.1.6-SNAPSHOT. Should it be dependent on maven-project v2.0.5 or v2.0.6-SNAPSHOT? My feeling is that it should depend on maven-project v2.0.6-SNAPSHOT because it seems safer in case someone checks in something into the maven-project that is incompatible to tomahawk. This will be detected then during continuum nightly build at the latest. Well, and as mentioned before, there does not exist an official maven-project v2.0.5 yet. Do you mean, we should freeze tomahawks dependencies to maven-project (and shared) until some new feature or fix is added to these artifacts that is needed in tomahawk? Hmm. My feeling is that it makes more problems than it solves. I think the best thing is to keep all MyFaces intra dependencies on the trunk(s) at the latest ie. every subproject uses the latest snapshot version of each other. Upon releasing there is still a chance to turn back the dependency to an artifact that has not changed since the last release. That means: When we release a new tomahawk version in a few weeks and the dependency to maven-project v2.0.6-SNAPSHOT there will be two possibilities: - there is NO diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT -- voila, we can release tomahawk with a dependency to maven-project v2.0.5 - there is A diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT -- we must publish an official maven-project v2.0.6 release first and then release tomahawk with a dependency to maven-project v2.0.6 Thoughts? Their is a balance here. If a dependent project is likely to change then by all means depend on the SNAPSHOT, otherwise depend on the released version. Dependency on maven-project-2.0.6-SNAPSHOT: Pro: o Dependent project will not have to update their dependency after the first commit to maven-project. Con: o More work during the release process if their is not change to maven-project. I.e. the release manage has to either release maven-project 2.0.6 or update the dependent projects to use 2.0.5 o Maven 2.0.4 has some issues around retrieving snapshot that are dependencies of a snapshot. If their is no difference between maven-project (or shared) between MyFaces and Tomahawk, then the same version of maven-project should be used. From a developers stand point the minimized issues like what version of this artifact should I be using and what has changed. I am not advocating a freeze since a freeze may prevent, or unnecessarily complicate, a fix to Tomahawk. In short my preferences is to keep the dependency on snapshots to a minimum, but I understand their are occasion when they are necessary. --Manfred Paul Spencer
Re: Comments/questions about the use of snapshot dependencies during the release process.
Manfred, First off, regardless of the outcome this discussion should not hold up the current release process. In fact, lets wait until it is done. Thank you for working on the release. Paul Spencer Manfred Geiler wrote: inline-- On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: Manfred, See below. Manfred Geiler wrote: inline On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: Manfred Geiler wrote: On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: snip IMHO we should not add a SNAPSHOT dependency until their their is a change from the released version of the dependency. This will minimize the number of projects to released. Thus at the end of the release process, only the following SNAPSHOT dependencies should exist: See above. There are no officially available non-SNAPSHOT releases for maven-project or shared or core yet. In addition the snapshot dependency should not be add until AFTER the release is cut. Same problem and additional danger here: Imagine a developer changes something and forgets to increase the version number of the artifact from x.y.z to x.y.z-SNAPSHOT. If he does a mvn install (or a mvn deploy!!!) he will have a total version chaos in his local repo: He will have local artifacts with version x.y.z that differ to the official released artifacts with the same version number! See description of the maven release plugin [1] for best practice and to learn how others are doing. The version of the artifact should be a SNAPSHOT for the above reason. I am referring to how the artifact is used. As an example, Tomahawk v1.1.5 will be dependent on maven-project v2.0.5. My comment was related to Tomahawk v1.1.6-SNAPSHOT. Should it be dependent on maven-project v2.0.5 or v2.0.6-SNAPSHOT? My feeling is that it should depend on maven-project v2.0.6-SNAPSHOT because it seems safer in case someone checks in something into the maven-project that is incompatible to tomahawk. This will be detected then during continuum nightly build at the latest. Well, and as mentioned before, there does not exist an official maven-project v2.0.5 yet. Do you mean, we should freeze tomahawks dependencies to maven-project (and shared) until some new feature or fix is added to these artifacts that is needed in tomahawk? Hmm. My feeling is that it makes more problems than it solves. I think the best thing is to keep all MyFaces intra dependencies on the trunk(s) at the latest ie. every subproject uses the latest snapshot version of each other. Upon releasing there is still a chance to turn back the dependency to an artifact that has not changed since the last release. That means: When we release a new tomahawk version in a few weeks and the dependency to maven-project v2.0.6-SNAPSHOT there will be two possibilities: - there is NO diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT -- voila, we can release tomahawk with a dependency to maven-project v2.0.5 - there is A diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT -- we must publish an official maven-project v2.0.6 release first and then release tomahawk with a dependency to maven-project v2.0.6 Thoughts? Their is a balance here. If a dependent project is likely to change then by all means depend on the SNAPSHOT, otherwise depend on the released version. Dependency on maven-project-2.0.6-SNAPSHOT: Pro: o Dependent project will not have to update their dependency after the first commit to maven-project. Con: o More work during the release process if their is not change to maven-project. I.e. the release manage has to either release maven-project 2.0.6 or update the dependent projects to use 2.0.5 o Maven 2.0.4 has some issues around retrieving snapshot that are dependencies of a snapshot. If their is no difference between maven-project (or shared) between MyFaces and Tomahawk, then the same version of maven-project should be used. From a developers stand point the minimized issues like what version of this artifact should I be using and what has changed. I am not advocating a freeze since a freeze may prevent, or unnecessarily complicate, a fix to Tomahawk. In short my preferences is to keep the dependency on snapshots to a minimum, but I understand their are occasion when they are necessary. Paul, I agree with most of your arguments. And you are right, there must be a tradeoff between the likelyhood of a subproject to change and dependent projects. But there is one more Pro for a dependency on maven-project-2.0.6-SNAPSHOT that just came to my mind and that might be the cause for my feeling that intra project dependencies should always be the latest snapshots: When people check out the current meta-project and do a complete build they expect to have a clean compile of every artifact and that there are no dependencies to old artifacts. That's one of the major pitfalls of maven: When you build
Attributes enabledOnUserRole and visibleOnUserRole being deprecated?
Per the comment the attributes enabledOnUserRole and visibleOnUserRole
will be deprecated and replaced by rendered='#{securityContext..}' on
TOMAHAWK-885[1], I am not sure I like this. Granted securityContext
provides a lot more control, but the attributes are easier to use and
document for the simple stuff.
Why are the attributes being deprecated?
When are the attribute scheduled to be deprecated?
Should their be an Jira issue for the deprecation?
If you would prefer to continue this discussion after the release of
MyFaces 1.1.5, I have no objections.
Paul Spencer
[1]https://issues.apache.org/jira/browse/TOMAHAWK-885
Re: Attributes enabledOnUserRole and visibleOnUserRole being deprecated?
Mike,
I found the thread title s:secure around 16-aug-2006 [1]. I also found
the wiki documentation [2].
1) The wiki page should be move into Tomahawk's documentation. I will
create a JIRA if you like.
2) Deprecation of the attributes enabledOnUserRole and visibleOnUserRole
need to be documented. This includes the TLDs, a Deprecation section
on Tomahawk's website, and the release notes. I will create a JIRA if
you like.
3) I will close TOMAHAWK-885 as wontfix with an explanation.
Paul Spencer
[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg16445.html
[2] http://wiki.apache.org/myfaces/SecurityContext
Mike Kienenberger wrote:
Because attributes have to be documented and maintained for every
component. They also don't work for non-Tomahawk components.
A securityContext approach is more flexible, maintainable, and
all-encompassing. We had a long discussion on this a long time ago
on the dev list. You could probably find it in the archives.
On 2/7/07, Paul Spencer [EMAIL PROTECTED] wrote:
Per the comment the attributes enabledOnUserRole and visibleOnUserRole
will be deprecated and replaced by rendered='#{securityContext..}' on
TOMAHAWK-885[1], I am not sure I like this. Granted securityContext
provides a lot more control, but the attributes are easier to use and
document for the simple stuff.
Why are the attributes being deprecated?
When are the attribute scheduled to be deprecated?
Should their be an Jira issue for the deprecation?
If you would prefer to continue this discussion after the release of
MyFaces 1.1.5, I have no objections.
Paul Spencer
[1]https://issues.apache.org/jira/browse/TOMAHAWK-885
Re: [jira] Commented: (TOMAHAWK-885) Add support for the attribute visibleOnUserRole to t:column
Cagatay, When will variable-property resolver be promoted out of the sandbox? Paul Spencer Cagatay Civici (JIRA) wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471520 ] Cagatay Civici commented on TOMAHAWK-885: - Just a note; security context is not a bean but a variable-property resolver located in sandbox. Add support for the attribute visibleOnUserRole to t:column - Key: TOMAHAWK-885 URL: https://issues.apache.org/jira/browse/TOMAHAWK-885 Project: MyFaces Tomahawk Issue Type: Improvement Components: Column Affects Versions: 1.1.1, 1.1.2, 1.1.3 Reporter: Paul Spencer Fix For: 1.1.5-SNAPSHOT Please add support for the attribute visibleOnUserRole to the tag t:column. I have the following reasons for this request: 1) This will allows a column to be displayed base on a users role. As example, a table that displays employee information can be configured to display only sensitive information, like home phone number, to managers. 2) Consistency with other Tomahawk tags.
Re: [jira] Commented: (TOMAHAWK-885) Add support for the attribute visibleOnUserRole to t:column
Cagatay, When will variable-property resolver be promoted out of the sandbox? Paul Spencer Cagatay Civici (JIRA) wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471520 ] Cagatay Civici commented on TOMAHAWK-885: - Just a note; security context is not a bean but a variable-property resolver located in sandbox. Add support for the attribute visibleOnUserRole to t:column - Key: TOMAHAWK-885 URL: https://issues.apache.org/jira/browse/TOMAHAWK-885 Project: MyFaces Tomahawk Issue Type: Improvement Components: Column Affects Versions: 1.1.1, 1.1.2, 1.1.3 Reporter: Paul Spencer Fix For: 1.1.5-SNAPSHOT Please add support for the attribute visibleOnUserRole to the tag t:column. I have the following reasons for this request: 1) This will allows a column to be displayed base on a users role. As example, a table that displays employee information can be configured to display only sensitive information, like home phone number, to managers. 2) Consistency with other Tomahawk tags.
Compilation failure on HtmlFormRenderer in the sandbox.
[INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\svn_apache_org\myfaces-061205\tomahawk\sandbox\core\src\main\java\org\apache\myfaces\renderkit\html\ext\HtmlFormRenderer.java:[32,71] cannot resolve symbol symbol : class HtmlFormRenderer location: package html C:\svn_apache_org\myfaces-061205\tomahawk\sandbox\core\src\main\java\org\apache\myfaces\renderkit\html\ext\HtmlFormRenderer.java:[41,8] cannot resolve symbol symbol : variable super location: class org.apache.myfaces.renderkit.html.ext.HtmlFormRenderer C:\svn_apache_org\myfaces-061205\tomahawk\sandbox\core\src\main\java\org\apache\myfaces\renderkit\html\ext\HtmlFormRenderer.java:[45,8] cannot resolve symbol symbol : variable super location: class org.apache.myfaces.renderkit.html.ext.HtmlFormRenderer
