[jira] Commented: (TOBAGO-228) css classes for tree are missing after renaming tree to treeOld
[ https://issues.apache.org/jira/browse/TOBAGO-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462166 ] Volker Weber commented on TOBAGO-228: - for a workarround in 1.0.9 you can use the attached files: put the file html_scarborough_mozilla_style_style.css as style.css in a directory html/scarborough/mozilla/style and the file html_scarborough_standard_style_style.css as style.css in a directory html/scarborough/standard/style into the tobago resource directory of your application css classes for tree are missing after renaming tree to treeOld --- Key: TOBAGO-228 URL: https://issues.apache.org/jira/browse/TOBAGO-228 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.9 Reporter: Volker Weber Assigned To: Udo Schnurpfeil Fix For: 1.0.10 Attachments: html_scarborough_mozilla_style_style.css, html_scarborough_standard_style_style.css the renaming to TreeOldRenderer results in rendering tobago-treeOld-default as css class name. this class is not found in style.css -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-225) tc:box with height on tree display was not able to display scroable body anymore.
[
https://issues.apache.org/jira/browse/TOBAGO-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462167
]
Volker Weber commented on TOBAGO-225:
-
see TOBAGO-228 for a workarround
tc:box with height on tree display was not able to display scroable body
anymore.
-
Key: TOBAGO-225
URL: https://issues.apache.org/jira/browse/TOBAGO-225
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 1.0.9
Environment: JBoss 4
IE Browser
JAVA 1.5
Reporter: Sam Wong
Assigned To: Volker Weber
Fix For: 1.0.10
Attachments: noScrollTabago1.0.9.JPG, ScrollTabago1.0.8.JPG
I have a tree with a lot of nodes and leafs, It works on tobago 1.0.8 when
the tree nodes expanded and reached the max of 200px, it display a vertical
scroll bar. Now it does not work anymore on tobago 1.0.9.
tc:box height=200px label=tree structure
tc:panel
tc:tree value=#{riskIdentifyController.categoriesTree}
state=#{riskIdentifyController.selectedCategories}
id=categoriesTree idReference=userObject.id
nameReference=userObject.name showIcons=true
showJunctions=true
showRootJunction=true showRoot=true
selectable=multiLeafOnly
mutable=false
/tc:tree
/tc:panel
/tc:box
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-229) AJAX-reload of scrollable Sheets resets scrollbar to top position
AJAX-reload of scrollable Sheets resets scrollbar to top position
-
Key: TOBAGO-229
URL: https://issues.apache.org/jira/browse/TOBAGO-229
Project: MyFaces Tobago
Issue Type: Bug
Reporter: Dennis Hauser
A workaround could be to store the scrollbar position before reloading and to
set it to the original after the reload is completed ( see attached code
fragment exchange-energy-trade_win.js)
This does work theoretically, but the marked lines in the second code fragment
(tobago-sheet.js) are resetting the sheet completely again.
-
exchange-energy-trade_win.js
function eetReloadOverviewWin() {
// neu von hier
var dataDiv = Tobago.element(marketPage:overviewSheet_data_div);
var scrollTop = dataDiv.scrollTop;
var scrollLeft = dataDiv.scrollLeft;
// bis hier
var options = {
insertion: function(receiver, response) {
if (response.substring(0, 20) == status code=\304\/) {
// no update needed, do nothing
receiver.skipUpdate = true;
} else if (response.substring(0, 11) == input id=\) {
// update content
Element.update(receiver, response);
// neu von hier
var dataDiv2 = Tobago.element(marketPage:overviewSheet_data_div);
dataDiv2.scrollTop = scrollTop;
dataDiv2.scrollLeft = scrollLeft;
// bis hier
} else {
// unknown response do full page reload
LOG.debug(initiating full reload);
var mos = Tobago.element(marketPage:overviewSheet);
if (mos != null) {
Tobago.submitAction(marketPage:overviewSheet);
}
}
if (eetOverviewTimeoutWin) {
clearTimeout(eetOverviewTimeoutWin);
}
eetOverviewTimeoutWin = setTimeout(eetReloadOverviewWin,
eetGetConfigWin().overviewSheetReloadTimeout);
},
createOverlay: false
};
Tobago.reloadComponent(marketPage:overviewSheet,
marketPage:overviewSheet, options);
}
-
resources/html/standard/standard/script/tobago-sheet.js
Tobago.Sheet.prototype.setup = function() {
...
// Problematisches Codefragment, dessen Sinn mir sich nicht erschließt,
// dessen Auskommentierung jedoch das Problem löst. :-)
// von hier
// ToDo: find a better way to fix this problem
// IE needs this in case of ajax loading of style classes
var outerDiv = Tobago.element(this.outerDivId);
outerDiv.className = outerDiv.className;
outerDiv.innerHTML = outerDiv.innerHTML;
// bis hier
...
}
-
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-228) css classes for tree are missing after renaming tree to treeOld
[ https://issues.apache.org/jira/browse/TOBAGO-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-228. - Resolution: Fixed css classes for tree are missing after renaming tree to treeOld --- Key: TOBAGO-228 URL: https://issues.apache.org/jira/browse/TOBAGO-228 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.9 Reporter: Volker Weber Assigned To: Volker Weber Fix For: 1.0.10 Attachments: html_scarborough_mozilla_style_style.css, html_scarborough_standard_style_style.css the renaming to TreeOldRenderer results in rendering tobago-treeOld-default as css class name. this class is not found in style.css -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-225) tc:box with height on tree display was not able to display scroable body anymore.
[
https://issues.apache.org/jira/browse/TOBAGO-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Weber resolved TOBAGO-225.
-
Resolution: Fixed
tc:box with height on tree display was not able to display scroable body
anymore.
-
Key: TOBAGO-225
URL: https://issues.apache.org/jira/browse/TOBAGO-225
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 1.0.9
Environment: JBoss 4
IE Browser
JAVA 1.5
Reporter: Sam Wong
Assigned To: Volker Weber
Fix For: 1.0.10
Attachments: noScrollTabago1.0.9.JPG, ScrollTabago1.0.8.JPG
I have a tree with a lot of nodes and leafs, It works on tobago 1.0.8 when
the tree nodes expanded and reached the max of 200px, it display a vertical
scroll bar. Now it does not work anymore on tobago 1.0.9.
tc:box height=200px label=tree structure
tc:panel
tc:tree value=#{riskIdentifyController.categoriesTree}
state=#{riskIdentifyController.selectedCategories}
id=categoriesTree idReference=userObject.id
nameReference=userObject.name showIcons=true
showJunctions=true
showRootJunction=true showRoot=true
selectable=multiLeafOnly
mutable=false
/tc:tree
/tc:panel
/tc:box
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-228) css classes for tree are missing after renaming tree to treeOld
[ https://issues.apache.org/jira/browse/TOBAGO-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462199 ] Udo Schnurpfeil commented on TOBAGO-228: Yes, the tobago-tree- must be replaced by tobago-treeOld-. But the files must be copied before that into the sandbox, to keep the new tree working. css classes for tree are missing after renaming tree to treeOld --- Key: TOBAGO-228 URL: https://issues.apache.org/jira/browse/TOBAGO-228 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.9 Reporter: Volker Weber Assigned To: Volker Weber Fix For: 1.0.10 Attachments: html_scarborough_mozilla_style_style.css, html_scarborough_standard_style_style.css the renaming to TreeOldRenderer results in rendering tobago-treeOld-default as css class name. this class is not found in style.css -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-230) Exception when using umlauts in confirm component
Exception when using umlauts in confirm component - Key: TOBAGO-230 URL: https://issues.apache.org/jira/browse/TOBAGO-230 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.9 Reporter: Volker Weber Assigned To: Volker Weber Priority: Critical Fix For: 1.0.10 ButtonRenderer throws an IllegalStateException: Cannot write attribute when start-tag not open. name = 'style'value = 'null'property = 'style' (ButtonRenderer.java:82) when confirm text contains characters which must be encoded e.g. german umlauts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-230) Exception when using umlauts in confirm component
[ https://issues.apache.org/jira/browse/TOBAGO-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-230. - Resolution: Fixed Exception when using umlauts in confirm component - Key: TOBAGO-230 URL: https://issues.apache.org/jira/browse/TOBAGO-230 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.9 Reporter: Volker Weber Assigned To: Volker Weber Priority: Critical Fix For: 1.0.10 ButtonRenderer throws an IllegalStateException: Cannot write attribute when start-tag not open. name = 'style'value = 'null'property = 'style' (ButtonRenderer.java:82) when confirm text contains characters which must be encoded e.g. german umlauts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-218) tobago throws an exception after validation form in not English locale
[ https://issues.apache.org/jira/browse/TOBAGO-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-218. - Resolution: Fixed Fix Version/s: 1.0.10 tobago throws an exception after validation form in not English locale --- Key: TOBAGO-218 URL: https://issues.apache.org/jira/browse/TOBAGO-218 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: tobago 1.0.8 facelets 1.1.11 validation the form fields Reporter: Yuri Ivanov Assigned To: Volker Weber Fix For: 1.0.10 when Tobago validates the form fields it tries to write title attribute in not English locale and throws an exception. Facelets calls renderKit.createResponseWriter(NullWriter.Instance, contentType, encoding); with null encoding, and then HtmlWriterUtil.writeEncodedValue calls TobagoResponseWriter.write I think TobagoRenderKit should validate encoding and set it to UTF-8 if it's null. full stack trace. java.lang.IllegalStateException: Cannot write attribute when start-tag not open. name = 'style'value = 'null'property = 'style' (InRenderer.java:105) at org.apache.myfaces.tobago.webapp.TobagoResponseWriter.writeAttribute(TobagoResponseWriter.java:361) at org.apache.myfaces.tobago.webapp.TobagoResponseWriter.writeAttribute(TobagoResponseWriter.java:314) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.InRenderer.encodeEndTobago(InRenderer.java:105) at org.apache.myfaces.tobago.renderkit.RendererBase.encodeEnd(RendererBase.java:108) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:90) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:286) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:72) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:261) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:44) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:82) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:286) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:72) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:261) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:44) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:82) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:55) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:72) at org.apache.myfaces.tobago.renderkit.RenderUtil.encodeChildren(RenderUtil.java:61) at org.apache.myfaces.tobago.renderkit.html.speyside.standard.tag.TabGroupRenderer.encodeContent(TabGroupRenderer.java:68) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.TabGroupRenderer.renderTabGroupView(TabGroupRenderer.java:294) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.TabGroupRenderer.encodeEndTobago(TabGroupRenderer.java:152) at org.apache.myfaces.tobago.renderkit.RendererBase.encodeEnd(RendererBase.java:108) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536) at org.apache.myfaces.tobago.component.UITabGroup.encodeEnd(UITabGroup.java:90) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:90) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:55) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:72) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:44) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:82) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:286) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:72) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:261) at
[jira] Resolved: (TOMAHAWK-805) Move sandbox selectItems to Tomahawk
[ https://issues.apache.org/jira/browse/TOMAHAWK-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cagatay Civici resolved TOMAHAWK-805. - Resolution: Fixed Fix Version/s: 1.1.5-SNAPSHOT Move sandbox selectItems to Tomahawk Key: TOMAHAWK-805 URL: https://issues.apache.org/jira/browse/TOMAHAWK-805 Project: MyFaces Tomahawk Issue Type: Task Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Cagatay Civici Assigned To: Cagatay Civici Priority: Minor Fix For: 1.1.5-SNAPSHOT Promote s:selectItems -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-841) Problem when t:popup is into t:div with IE
Problem when t:popup is into t:div with IE -- Key: TOMAHAWK-841 URL: https://issues.apache.org/jira/browse/TOMAHAWK-841 Project: MyFaces Tomahawk Issue Type: Bug Components: Popup Affects Versions: 1.1.3 Environment: Windows Xp pro Reporter: Kevin Boucherez There is a bug with IE 6 and 7 when the popup component is into the div component. Indeed the rendered parameter of div component does not interpret the javascript. But with Mozilla it's ok the popup appears. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-228) css classes for tree are missing after renaming tree to treeOld
[
https://issues.apache.org/jira/browse/TOBAGO-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462223
]
Sam Wong commented on TOBAGO-228:
-
I replace the html_scarborough_mozilla_style_style.css and named style.css
into the org\apache\myfaces\tobago\renderkit\html\scarborough\mozilla\style
directory
and i replace the html_scarborough_standard_style_style.css and named
style.css into the
org\apache\myfaces\tobago\renderkit\html\scarborough\standard\style directory
It does not work on 1.0.9
I also tried another way by puting the
/* treeOld*/
.tobago-treeOld-default {
overflow: auto;
}
into the exisiting
org\apache\myfaces\tobago\renderkit\html\scarborough\standard\style\style.css
and do a search to see any tobago-tree- and replaced by tobago-treeOld-
and still does not work. Any suggetions? thanks.
css classes for tree are missing after renaming tree to treeOld
---
Key: TOBAGO-228
URL: https://issues.apache.org/jira/browse/TOBAGO-228
Project: MyFaces Tobago
Issue Type: Bug
Components: Themes
Affects Versions: 1.0.9
Reporter: Volker Weber
Assigned To: Volker Weber
Fix For: 1.0.10
Attachments: html_scarborough_mozilla_style_style.css,
html_scarborough_standard_style_style.css
the renaming to TreeOldRenderer results in rendering tobago-treeOld-default
as css class name.
this class is not found in style.css
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-186) inputCalendar - how to change the first day of week
[ https://issues.apache.org/jira/browse/TOMAHAWK-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462253 ] Paul Pogonyshev commented on TOMAHAWK-186: -- Set `locale' attribute on f:view tag. inputCalendar - how to change the first day of week --- Key: TOMAHAWK-186 URL: https://issues.apache.org/jira/browse/TOMAHAWK-186 Project: MyFaces Tomahawk Issue Type: New Feature Components: Calendar Reporter: Rumiana Panova How can I change the first day of week from Sunday to Monday in the inputCalendar ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-842) popup is active for disabled calendar components
popup is active for disabled calendar components Key: TOMAHAWK-842 URL: https://issues.apache.org/jira/browse/TOMAHAWK-842 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.3 Reporter: Paul Pogonyshev Priority: Minor When the calendar is disabled, its text entry is rendered as inacessible to user (correct), but calendar popup can still be opened and operated (incorrect.) This should be easily fixable by adding a check for disabled text entry into _popUpCalendar() JavaScript function. I.e. if entry is disabled, don't show popup in any case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-107) tc:page should use a reasonable default width+height and state
[ https://issues.apache.org/jira/browse/TOBAGO-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-107. -- Resolution: Fixed tc:page should use a reasonable default width+height and state -- Key: TOBAGO-107 URL: https://issues.apache.org/jira/browse/TOBAGO-107 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Udo Schnurpfeil Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.10 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-217) Create a popup ref tag
[ https://issues.apache.org/jira/browse/TOBAGO-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-217. -- Resolution: Fixed Create a popup ref tag -- Key: TOBAGO-217 URL: https://issues.apache.org/jira/browse/TOBAGO-217 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.9 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.10 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Patch Branch?
We don't have one. It's frequently requested. +1 on creating a 1.1.4.1 maintenance branch. On 1/4/07, Stan Silvert [EMAIL PROTECTED] 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?
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?
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. 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? Paul Spencer Dennis Byrne
Re: Patch Branch?
[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. 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. 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. 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. On 1/4/07, Paul Spencer [EMAIL PROTECTED] wrote: 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?
Hello, is the new copyright policy a blocker for a 1.1.4.1 release? See: http://www.apache.org/legal/src-headers.html Regards Bernd Paul Spencer wrote: 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
[jira] Created: (TOMAHAWK-843) myfaces not releasing memory gracefully?
myfaces not releasing memory gracefully? Key: TOMAHAWK-843 URL: https://issues.apache.org/jira/browse/TOMAHAWK-843 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.3 Environment: tomcat 5.5.12 Reporter: Dez Hi, I've been using Myfaces implementation of JSF for couple of months and just noticed that memory usage is pretty high - many times I got out of memory error. It works fine for simple pages, but when the page is large and complex, it doesn't seem to release the memory used by component states. Here is the scenario: I'm using t:datatable for rendering employees info. Each row corresponds to a employee object, the row has 10 columns. It works fine in terms of memory footprint and CPU, when the dataset the table renders is small, but when the size of the datasets is large(talking about 500 or more), I get Out of memory error even though the Managed Bean is request-scoped. No pagination being employed(that's the last resort). So when the number of user increases, this leads to a serious issues of server crash, hang etc. On profiling using yourtoolkit, I found that faces context never releases the memory used by UI Components and the behaviour is erratic. The GC kicks in after certain stage which is not very useful. Even for a table of small data rows(20-30), it doesn't seem to release the memory, in fact it accumulates the memory. So even the pagination doesn't seem to solve the out- of- memory issue as the web site will be used by large number of users. FYI, I'm using the client STATE_SAVING_METHOD. context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param Has anyone faced similar issues? Is this a bug or known issues of myfaces? No one seem to have resolved this issues, I did see similar issues being posted in different forums. Would appreciate your help in this regard. thanks Dezmax -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-231) Problem with input validation and tab group
Problem with input validation and tab group --- Key: TOBAGO-231 URL: https://issues.apache.org/jira/browse/TOBAGO-231 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.9, 1.0.10 Environment: Win XP/2000, Tomcat 5.5.15, Firefox 2.0 Reporter: Helmut Swaczinna Priority: Minor Fix For: 1.0.10 I've got a problem with input validation in a tabGroup with switchType=reloadTab. When I enter an invalid value in an input field on a tab, I can switch to another tab. The validation of the field is excuted and failes, but switching tabs is not blocked. When I switch back to the tab with the invalid field, the field is not marked as invalid. With switchType=reloadPage, I cannot switch to another tab and the field is marked as invalid. This is, what I'm expecting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Patch Branch?
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. -- Wendy
Re: Patch Branch?
On 1/4/07, Bernd Bohmann [EMAIL PROTECTED] wrote: is the new copyright policy a blocker for a 1.1.4.1 release? See: http://www.apache.org/legal/src-headers.html Yes, but it's fairly simple to fix. I think the Maven developers have been using an IDEA plugin to do it, and there are some scripts around (though I haven't tried them.) Stan, do you have the JIRA issue and svn revision(s) for the portlet bug fix? I need to know if it affects Shared or just Core. -- Wendy
