[jira] [Commented] (MYFACES-3574) Update of 'javax.faces.ViewState' input elements fails
[ https://issues.apache.org/jira/browse/MYFACES-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965038#comment-13965038 ] John Redwood commented on MYFACES-3574: --- Hi Werner, Just giving you an update - thanks for your help. This turns out it wasn't the issue. The issue was that PrimeFaces wasn't finding the ViewState in the children dom of the form object. This is because some clever fellar who built WCEM 2.0 (SAP) decided that in the form.begin.vm file there should be a div /div with the following comment: ## The div is required because a form may only contain block elements and input is not a block element Now aside from the fact it makes absolutely NO SENSE... removing this div fixed all the issues. The viewstate was inside a child div not a child itself in the form. Thankyou for your help. Cheers John Update of 'javax.faces.ViewState' input elements fails -- Key: MYFACES-3574 URL: https://issues.apache.org/jira/browse/MYFACES-3574 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.7, 2.1.8 Environment: Internet Explorer 7 Reporter: Mircea Toma Assignee: Leonardo Uribe Fix For: 2.0.15, 2.1.9 Attachments: MYFACES-3574.patch The issue resides in the JS code that is responsible for updating javax.faces.ViewState key in the hidden input elements. In IE7 during the second update the lookup for the 'javax.faces.ViewState' named input element fails. The element[name] syntax is used for the lookup which is known to fail for elements with complex names (such as 'javax.faces.ViewState'). When the lookup fails to find the input element a second input element is created which will contain the new javax.faces.ViewState value. The next submit will send two 'javax.faces.ViewState' parameters but only the first one (the oldest) is read by the server state manager . This old key is not known to the server anymore and this causes a ViewExpired exception to be thrown on the server. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3574) Update of 'javax.faces.ViewState' input elements fails
[ https://issues.apache.org/jira/browse/MYFACES-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911502#comment-13911502 ] John Redwood commented on MYFACES-3574: --- I tested on chrome and on IE9/10 and same issues happening, Just not sure if the problem was only for IE7 (reported issue) - If it effects others then yes definitely look to upgrade our version but it is a long and tedious process to get that done. If there is a programmatic way to do it quicker would be great.. At the moment It's looking like jQuery to update the forms input field even though a second field has been added to the requests. Doesn't seem to be the truncation issue though. Thanks heaps Update of 'javax.faces.ViewState' input elements fails -- Key: MYFACES-3574 URL: https://issues.apache.org/jira/browse/MYFACES-3574 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.7, 2.1.8 Environment: Internet Explorer 7 Reporter: Mircea Toma Assignee: Leonardo Uribe Fix For: 2.0.15, 2.1.9 Attachments: MYFACES-3574.patch The issue resides in the JS code that is responsible for updating javax.faces.ViewState key in the hidden input elements. In IE7 during the second update the lookup for the 'javax.faces.ViewState' named input element fails. The element[name] syntax is used for the lookup which is known to fail for elements with complex names (such as 'javax.faces.ViewState'). When the lookup fails to find the input element a second input element is created which will contain the new javax.faces.ViewState value. The next submit will send two 'javax.faces.ViewState' parameters but only the first one (the oldest) is read by the server state manager . This old key is not known to the server anymore and this causes a ViewExpired exception to be thrown on the server. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (MYFACES-3574) Update of 'javax.faces.ViewState' input elements fails
[ https://issues.apache.org/jira/browse/MYFACES-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910921#comment-13910921 ] John Redwood commented on MYFACES-3574: --- Is this an issue for other browsers? I am experiencing this exact issue with Chrome 32.0.1700.107 - MyFaces 2.1.7, Primefaces 3.5 - WCEM2.0 I'm trying to get them to upgrade to see if that fixes, but how many SAP consultants does it take to push a basic upgrade... too many.. Update of 'javax.faces.ViewState' input elements fails -- Key: MYFACES-3574 URL: https://issues.apache.org/jira/browse/MYFACES-3574 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.7, 2.1.8 Environment: Internet Explorer 7 Reporter: Mircea Toma Assignee: Leonardo Uribe Fix For: 2.0.15, 2.1.9 Attachments: MYFACES-3574.patch The issue resides in the JS code that is responsible for updating javax.faces.ViewState key in the hidden input elements. In IE7 during the second update the lookup for the 'javax.faces.ViewState' named input element fails. The element[name] syntax is used for the lookup which is known to fail for elements with complex names (such as 'javax.faces.ViewState'). When the lookup fails to find the input element a second input element is created which will contain the new javax.faces.ViewState value. The next submit will send two 'javax.faces.ViewState' parameters but only the first one (the oldest) is read by the server state manager . This old key is not known to the server anymore and this causes a ViewExpired exception to be thrown on the server. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (MYFACES-3768) FacesMessage Severity ordinal values are not consistent with Mojarra RI
John Yeary created MYFACES-3768:
---
Summary: FacesMessage Severity ordinal values are not consistent
with Mojarra RI
Key: MYFACES-3768
URL: https://issues.apache.org/jira/browse/MYFACES-3768
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.12, 2.1.11, 2.1.10, 2.1.9, 2.1.8, 2.1.7
Reporter: John Yeary
The ordinal values for the Severity levels in Mojarra use values starting from
0 while MyFaces uses values starting from 1. This results in inconsistent
behavior between implementations. I suggest aligning the values starting with 0
since this is consistent with general programming expectations.
*Mojarra*
{noformat}
INFO(0), WARN(1), ERROR(2), and FATAL(3)
{noformat}
*MyFaces*
{noformat}
INFO(1), WARN(2), ERROR(3), and FATAL(4)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOMAHAWK-1661) dataTable value evaluated if parent component not rendered if preserveDataModel is true
John Smith created TOMAHAWK-1661:
Summary: dataTable value evaluated if parent component not
rendered if preserveDataModel is true
Key: TOMAHAWK-1661
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1661
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.14
Reporter: John Smith
If a t:dataTable's parent component's rendered attribute evaluates to false,
the dataTable's value attribute is still evaluated if the dataTable has the
preserveDataModel attribute set to true.
While I don't think this strictly violates the spec (it says under 2.2.6: 'If
the isRendered() method of a component returns false, the renderer for that
component must not generate any markup, and none of its facets or children (if
any) should be rendered.'), it is at the very least inconsistent with other JSF
components, which do not evaluate the value if not rendered
Example:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:t=http://myfaces.apache.org/tomahawk;
h:head /
h:body
h:form
h:panelGroup rendered=false
t:dataTable value=#{bean.list} var=list
preserveDataModel=true
h:column#{list}/h:column
/t:dataTable
/h:panelGroup
/h:form
/h:body
/html
-
@RequestScoped
@ManagedBean
public class Bean {
public ListString getList(){
throw new RuntimeException(this should not be called);
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOMAHAWK-1572) CLONE - t:panelTabbedPane breaks commandLinks
CLONE - t:panelTabbedPane breaks commandLinks - Key: TOMAHAWK-1572 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1572 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Reporter: John Yeary Assignee: Thomas Spiegl When a commandLink is nested inside a panelTab as part of a panelTabbedPane, the resulting commandLink does not work because its form gets nested in the 'autoform' generated by the panelTabbedPane. The result is a Javascript error when the link is clicked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1572) CLONE - t:panelTabbedPane breaks commandLinks
[ https://issues.apache.org/jira/browse/TOMAHAWK-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009416#comment-13009416 ] John Yeary commented on TOMAHAWK-1572: -- The original remarks on the closing of the issue indicated that autoform is not used on the latest release. This is not correct. I am using MyFaces Tomahawk 1.1.10 for JSF 1.2 and it still uses autoform. The issue should still be open as it is broken. form name=panelTabbedPane1.autoform style=display:inline method=post action=/adminmgr/faces/index.xhtml CLONE - t:panelTabbedPane breaks commandLinks - Key: TOMAHAWK-1572 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1572 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Reporter: John Yeary Assignee: Thomas Spiegl When a commandLink is nested inside a panelTab as part of a panelTabbedPane, the resulting commandLink does not work because its form gets nested in the 'autoform' generated by the panelTabbedPane. The result is a Javascript error when the link is clicked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1572) CLONE - t:panelTabbedPane breaks commandLinks
[ https://issues.apache.org/jira/browse/TOMAHAWK-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009423#comment-13009423 ] John Yeary commented on TOMAHAWK-1572: -- The workaround as noted in the other issue is to add a dummy h:form/ tag to the panelTab before the real form. CLONE - t:panelTabbedPane breaks commandLinks - Key: TOMAHAWK-1572 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1572 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Reporter: John Yeary Assignee: Thomas Spiegl Labels: commandLink, panelTabbedPane Attachments: AutoformVisible.jpg When a commandLink is nested inside a panelTab as part of a panelTabbedPane, the resulting commandLink does not work because its form gets nested in the 'autoform' generated by the panelTabbedPane. The result is a Javascript error when the link is clicked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2012) showDetailItem: Allow styleClass attribute to apply to the text attribute
showDetailItem: Allow styleClass attribute to apply to the text attribute - Key: TRINIDAD-2012 URL: https://issues.apache.org/jira/browse/TRINIDAD-2012 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.0.13-core Environment: MyEclipse 8; Tomcat 6 Reporter: John Banister showDetailItem styleClass attribute is only applied to the expanded content. The showDetailItem styleclass attribute is not applied to the text attribute contents. We would like this feature so that the text in the text attribute in the showDetailItem can change color dynamically to indicate the status of a given accordian item as we iterate through an ArrayList within the panelAccordion component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-981) tr:table rowSelection attribute expressions not able to change the value
tr:table rowSelection attribute expressions not able to change the value Key: TRINIDAD-981 URL: https://issues.apache.org/jira/browse/TRINIDAD-981 Project: MyFaces Trinidad Issue Type: Bug Environment: Tomcat 6 on windows xp Reporter: John Banister Priority: Minor Not able to change the value using an expression in the rowSelection attribute of the tr:table tag. The table value will always resolve to 'single' regardless of the String value of the expression used in the rowSelection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1811) cannot set enctype on h:form with el
cannot set enctype on h:form with el
Key: MYFACES-1811
URL: https://issues.apache.org/jira/browse/MYFACES-1811
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.2
Environment: Windows, Tomcat 6.0.14, facelets 1.1.14
Reporter: John Singleton
I have the following code in a facelets composition
h:form onsubmit=return submitForm() id=main enctype=#{(empty
encoding) ? 'application/x-www-form-urlencoded' : encoding}
Depending on how the form is used the enctype might need to be
multipart/form-data
I use the composition like so:
ui:decorate xmlns=http://www.w3.org/1999/xhtml;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
template=#{pqfn:absoluteStyle('homeTemplate.xhtml')}
ui:param name=encoding value=multipart/form-data /
This worked prior to MyFaces 1.2. It doesn't work in 1.2+ Looking at
HtmlForm.java :
// Property: enctype
private String _enctype = application/x-www-form-urlencoded;
/**
* Gets The content type used to submit this form to the server.
*
* @return the new enctype value
*/
public String getEnctype()
{
if (_enctype != null)
{
return _enctype;
}
ValueExpression expression = getValueExpression(enctype);
if (expression != null)
{
return (String)expression.getValue(getFacesContext().getELContext());
}
return application/x-www-form-urlencoded;
}
As enctype is initialized in it's declaration it is never null. Therefore the
ValueExpression is never evaluated. This means the enctype cannot be set using
an EL Expression in the page.
I'm not sure if this is a bug against HtmlForm, or the maven-faces-plugin that
is generating this class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1691) beforeUnload event handler breaks form submission
beforeUnload event handler breaks form submission
-
Key: MYFACES-1691
URL: https://issues.apache.org/jira/browse/MYFACES-1691
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.5
Environment: Windows XP, IE7
Reporter: John Singleton
I am using the onBeforeUnload event to prevent the user leaving the page
without first saving their work.
If the user cancels the page navigation, further navigation in the page fails.
I tracked this down to this call in oamSubmitForm
document.forms[formName].submit();
In IE when the user cancels navigation of the page the form.submit method
throws an exception. This isn't caught in oamSubmitForm and so it doesn't
complete cleanly.
I fixed this by changing the 2 calls to form.submit too:
try { document.forms[formName].submit(); } catch (e) {}
oamSubmitForm now completes cleanly and further navigation in the page succeeds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-436) tc:sheet rowClick facet
[ https://issues.apache.org/jira/browse/TOBAGO-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511056 ] John Turner commented on TOBAGO-436: A single column would suit me fine also. Besides, all the columns could have the same action. So long as the selected row is highlighted as is currently the case and the sheet state object reflects the selected row index. tc:sheet rowClick facet --- Key: TOBAGO-436 URL: https://issues.apache.org/jira/browse/TOBAGO-436 Project: MyFaces Tobago Issue Type: Improvement Components: Core Environment: Win XP, Tomcat, WebFlow, Spring, TobagoProbably not relevant Reporter: John Turner I had a discussion on the forum about taking an action on click of a row within the sheet component. I can't find anything on the issues log that matches this requirement exactly so I wanted to raise it rather than it fall through the cracks. I'm using Spring WebFlow and Tobago to perform a search conversation in which the user is directed to a search screen and displayed search results etc. The search results are displayed using the rather handy tc:sheet component. This gives me the paging functionality , sheet state persistence etc for free which is great. However, I'm not able to determine how to (without going outside functionality provided by Tobago) react to a row click to submit an action. What I would like to see is a rowClick facet (or similar) that allows me to submit an action. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-436) tc:sheet rowClick facet
tc:sheet rowClick facet --- Key: TOBAGO-436 URL: https://issues.apache.org/jira/browse/TOBAGO-436 Project: MyFaces Tobago Issue Type: Improvement Components: Core Environment: Win XP, Tomcat, WebFlow, Spring, TobagoProbably not relevant Reporter: John Turner I had a discussion on the forum about taking an action on click of a row within the sheet component. I can't find anything on the issues log that matches this requirement exactly so I wanted to raise it rather than it fall through the cracks. I'm using Spring WebFlow and Tobago to perform a search conversation in which the user is directed to a search screen and displayed search results etc. The search results are displayed using the rather handy tc:sheet component. This gives me the paging functionality , sheet state persistence etc for free which is great. However, I'm not able to determine how to (without going outside functionality provided by Tobago) react to a row click to submit an action. What I would like to see is a rowClick facet (or similar) that allows me to submit an action. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [Proposal] Apache MyFaces commons
I'm currently developing non tomahawk taglibs, but the AddResource etc code in tomahawk (along with very much else) is very useful. It would, however, be nice to just import the jar files that I needed, rather than the whole of Tomahawk. Regards, John Grange -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthias Wessendorf Sent: 03 May 2007 17:08 To: MyFaces Development Subject: [Proposal] Apache MyFaces commons Greetings from the ApacheCon in Amsterdam. It was discussed a lot on the list and Bernd and I are now taking the time to layout a apache-myfaces-commons-[SUBSET]-VERSION.jar file. Commons: -What should go into a commons JAR? Non renderKit related things like -Converters and Validators -NonFacesRequestServlet from Tobago -FacesContextFactory from Tobago to ensure a kind of common layer for doing uploads -the selectItems component from Tomahawk -what are we missing ??? Build dependencies: - Trinidad's plugins/utils to generate stuff like the TagClass file. The vision: Why this is needed ? It is kind of hard to actually use only some common pieces of Tomahawk. At least to add a custom validator, the complete jar is needed. The vision is also to add some common pieces from Trinidad/tobago to it. For Tomahawk this will not mean, you have to introduce a new namespace for adding the converter/validator, the commons-jar can be a rt dependency so that the TLD file is only referencing to the classes w/in the commons.jar. What are you missing ? We will compile a list into the MyFaces wiki, based on your feedback/comments -Bernd/Matthias Thales UK Ltd (Wells) DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0) 1749 672081 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. A business of Thales UK Ltd. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX Registered in England No. 868273
[jira] Created: (TOMAHAWK-970) HtmlTabbedPane is not serializable
HtmlTabbedPane is not serializable -- Key: TOMAHAWK-970 URL: https://issues.apache.org/jira/browse/TOMAHAWK-970 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5 Environment: myfaces 1.1.5, tomahawk 1.1.5, facelets, java 5 Reporter: John Singleton HtmlTabbedPane does not implement Serializable, so I get exceptions like this when starting up and shutting down my webapp: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane This happens when the Session manager persists the session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1583) external resources in attributes (i.e. image in commandButton): doubleslash not working as expected, URL requires protocol
external resources in attributes (i.e. image in commandButton): doubleslash not
working as expected, URL requires protocol
--
Key: MYFACES-1583
URL: https://issues.apache.org/jira/browse/MYFACES-1583
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.4
Environment: MyFaces 1.1.4 and facelets on Websphere on Linux, AIX and
in RSA/RAD.
Reporter: John Elm
Consider for a moment the following image input. Let's say I have a
myfaces app, with a context root of my/context/root, with a domain
name of www.mycompany.com.
input
type=image
src=//www.mycompany.com/images/blah.gif
name=blah
value=Blah /
Notice that the src attribute starts with a doubleslash. When
authoring non-JSF tags (i.e. in non-JSF apps), this has been an effective way
to include
resources that are external to our app (typically hosted at a central
location somewhere in our enterprise).
Our web standards actually do
not allow us to include the protocol in the URL, but when we author
the attribute this way, the browser prepends the protocol (i.e. https://)
that was used to retrieve the page. This browser behavior seems the same with
all external resources, i.e. javascripts, css, etc.
Now, consider the JSF example for the same input:
h:commandButton
action=#{backingBean.someAction}
image=//www.mycompany.com/images/blah.gif /
MyFaces renders this:
input
type=image
src=my/context/root//www.mycompany.com/images/blah.gif
...
Of course, if I include the https: protocol in the URL, MyFaces
correctly interprets and renders it as a complete external URL.
When we supply an external resource, as when using the image attribute in a
commandButton, shouldn't MyFaces behave in the same way as when we point to an
external resource while composing non-JSF tags? In particular, when we begin
the URL with a doubleslash, shouldn't it interpret the URL as an external
resource and prepend the protocol that was used to retrieve the page? If
MyFaces merely rendered these attributes unmodified, I think the browser would
handle it correctly.
As it is, in order to avoid including the protocol in these URLs, I must
maintain local copies of these image resources in our web app, which is also
discouraged by our web standards.
I found this, it sounds like this may have been when the behavior was
introduced.
http://issues.apache.org/jira/browse/MYFACES-476
Perhaps also relevant:
http://issues.apache.org/jira/browse/MYFACES-52
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-536) Data from inputText within popup is not saved
[
https://issues.apache.org/jira/browse/TOMAHAWK-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469962
]
John Boardman commented on TOMAHAWK-536:
Move your form inside the popup and it will work. The div for the popup gets
moved to the bottom of the emitted html, outside the form in which it is
defined. I spent many an hour trying to figure out why values weren't being set
in popups and this turned out to be the problem. This still happens when using
version 1.1.5 of all components (myfaces, tomahawk, and sandbox).
Hope this helps!
John
Data from inputText within popup is not saved
-
Key: TOMAHAWK-536
URL: https://issues.apache.org/jira/browse/TOMAHAWK-536
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Popup
Affects Versions: 1.1.4-SNAPSHOT
Environment: JBoss 4.0.4.GA
MyFaces 1.1.3
Tomahawk+Sandbox 1.1.5.snapshot
Reporter: RD
When modifying the node description using the inputText (the one from the
popup) and pressing Submit, the description is not saved to the bean.
%@ page contentType=text/html; charset=ISO-8859-1 %
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
%@ taglib uri=http://myfaces.apache.org/sandbox; prefix=s%
%@ taglib uri=http://struts.apache.org/tags-tiles; prefix=tiles %
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
h:form id=treedemoForm
t:tree2 id=mytree value=#{treedemo.treeData}
var=node varNodeToggler=t clientSideToggle=true
f:facet name=normal
h:panelGroup id=mypanelgroup
t:popup styleClass=popup
closePopupOnExitingElement=true
closePopupOnExitingPopup=true
displayAtDistanceX=1
displayAtDistanceY=1
h:outputText
value=#{node.description}/
f:facet name=popup
h:panelGroup
h:panelGrid
columns=2 align=left
styleClass=gridTable
cellpadding=5 cellspacing=0
columnClasses=gridLabelColumn,gridInputColumn,gridErrorColumn
h:outputText
value=Descr/
h:inputText
value=#{node.description} /
h:outputFormat
value=Submit - /
h:commandButton value=Submit/
/h:panelGrid
/h:panelGroup
/f:facet
/t:popup
/h:panelGroup
/f:facet
/t:tree2
/h:form
I have removed the popup and placed the inputText directly on the form; the
description does get saved to the bean:
h:form id=treedemoForm
t:tree2 id=mytree value=#{treedemo.treeData}
var=node varNodeToggler=t clientSideToggle=true
f:facet name=normal
h:panelGroup id=mypanelgroup
h:outputText
value=#{node.description}/
h:panelGroup
h:panelGrid
columns=2 align=left
styleClass=gridTable
cellpadding=5
cellspacing=0
columnClasses=gridLabelColumn,gridInputColumn,gridErrorColumn
h:outputText
value=Descr/
h:inputText
value=#{node.description} id=descr/
h:outputFormat
value=Submit - /
h:commandButton value=Submit/
/h:panelGrid
/h:panelGroup
/h:panelGroup
/f:facet
/t:tree2
/h:form
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-90) t:panelTabbedPane breaks commandLinks
[ https://issues.apache.org/jira/browse/TOMAHAWK-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462852 ] John Boardman commented on TOMAHAWK-90: --- This fix worked perfectly for me. I put it just after t:panelTab in all my t:panelTabbedPane controls, and now my forms work in both Firefox and IE instead of just Firefox. Thanks for the tip! t:panelTabbedPane breaks commandLinks - Key: TOMAHAWK-90 URL: https://issues.apache.org/jira/browse/TOMAHAWK-90 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Reporter: Noah Sloan Assigned To: Thomas Spiegl When a commandLink is nested inside a panelTab as part of a panelTabbedPane, the resulting commandLink does not work because its form gets nested in the 'autoform' generated by the panelTabbedPane. The result is a Javascript error when the link is clicked. -- 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: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
Let me try the new release today first. I should have a definitive by EOW. Thanks, John -Original Message- From: Bernd Bohmann (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 12:35 PM To: John Subject: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 [ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_124 39949 ] Bernd Bohmann commented on TOBAGO-115: -- Can we close this issue with the latest changes in Tobago? myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 -- -- Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
[ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_12434210 ] John Allan commented on TOBAGO-115: --- (Partially Resolved - workaround). The problem was the use of the css/javascript behavior pngBehavior.htc, which modifies img components within the html, so Internet Explorer 6.0 can support PNG transparency. It was actually rewriting the viewId on the fly and assigning graphics and the PngBehavior.htc file itself, to the viewId. When I removed the pngBehavior.htc reference in the code, everything worked fine (even with Ajax). Workaround: I converted all the PNG images to JPG images and removed the behavior. We had used this behavior on our website for years and I've seen references in the myFaces users mailing list to its use with myFaces. I wouldn't have even known what the problem was, until I added a phase listener that displayed viewId after every phase. John myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
[ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_12432670 ] John Allan commented on TOBAGO-115: --- When the server error: Server Error: unable to serve request. Probably a session timeout! error displayed on webpage. Occurs: The following is on STDERR SEVERE: Ignoring AjaxRequest without valid component tree! myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
No I haven't, but I believe you if you say it works. I don't know how to begin to extrapolate that to our app though... It just doesn't work on any IE Win 2K,2003 machine. This has been confirmed by multiple customers, Microsoft tech support and us. We're not doing anything particularly fancy. Just tabs. Did you get the debug info in response to your request? Microsoft IE support insists that the server is sending the same data no matter which tab is clicked. John -Original Message- From: Volker Weber (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 12:20 AM To: John Subject: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 [ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_124 29629 ] Volker Weber commented on TOBAGO-115: - Have you tested the tobago-example-demo app? No Problems here on a Windows 2000 professional SP4 system here. myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 -- -- Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
[ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_12429826 ] John Allan commented on TOBAGO-115: --- Volker Asked: Have you tested the tobago-example-demo app? I tested the Tobago Demo from our Windows 2003 server using IE 6, as it sits on the web at Antanion. Seems to work fine. I don't know how to extrapolate that to our application though. Ours doesn't have the listener under the tabgroup defined, for instance. John myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1379) CLONE -commandLink actions ignored inside tree2
Hi,
In response to your post at http://www.mail-archive.com/dev@myfaces.apache.org/msg16259.html
Have you tried using immediate=true in your
command link?
I dont have any scientific basis for explaining
this.. all I know is that immediate=true skips the validation
phase? which I cant relate to the functioning of tree2.
However using immediate=true caused my events
to start working in this code here.
If I do not use immediate=true, events do not
fire.
An explanation for this would be welcome also!
t:tree2 id=userTeamTree value=#{treeMenu.treeModel} var=node showRootNode=false
!-- render
nodes of type root --
f:facet name=root
h:panelGroup
h:outputText value=All Teams and Users/
/h:panelGroup
/f:facet
%-- render nodes of
type team --%
f:facet name=team
h:panelGroup
t:graphicImage value=../images/teams.png/
h:commandLink immediate=true value=#{node.description} action=#{treeMenu.teamsInterface}
f:param name=team_id value=#{node.identifier}/
/h:commandLink
/h:panelGroup
/f:facet
!-- chosen
to render nodes of type user --
f:facet name=user
h:panelGroup
h:commandLink immediate=true action=#{treeMenu.usersInterface}
h:outputText value=#{node.description}/
f:param name=user_id value=#{node.identifier}/
/h:commandLink
/h:panelGroup
/f:facet
/t:tree2
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.2/422 - Release Date: 17/08/2006
[jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
[ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_12428796 ] John Allan commented on TOBAGO-115: --- I enabled ajax within tobago-config.xml (apparently the default is disabled - I had assumed the reverse). I connect from Windows 2003 server using IE 6 (the broken configuration). I get the login.jsp just fine I login just fine. Within main.jsp when I click on a tab (to exercise the broken behavior). I get the following reponse: Server Error: unable to serve request. Probably a session timeout! myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
[ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_12428844 ] John Allan commented on TOBAGO-115: --- Ok here is the result of all your requested tests... 1) Here is the output on STDERR with AJAX enabled with ReloadTab - this is the only condition where any error is thrown in STDERR Aug 17, 2006 5:47:27 PM org.apache.myfaces.tobago.ajax.api.AjaxPhaseListener beforePhase SEVERE: Ignoring AjaxRequest without valid component tree! 2) Assuming the tests were being run before without an ajax entry in tabago-config, here is the result with ajax disabled (not in config) ReloadTab = broken behavior as per original submission ReloadPage = broken behavior as per original submission 3) Ajax enabled ReloadTab Server Error: unable to serve request. Probably a session timeout! error displayed on webpage. 4) Ajax enabled ReloadPage broken behavior as per original submission Again all configs work in firefox. myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-592) panelTabbedPane: Duplicate class attributes
[ http://issues.apache.org/jira/browse/TOMAHAWK-592?page=all ]
John Singleton updated TOMAHAWK-592:
Status: Open (was: Patch Available)
panelTabbedPane: Duplicate class attributes
---
Key: TOMAHAWK-592
URL: http://issues.apache.org/jira/browse/TOMAHAWK-592
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.3
Environment: Tomcat 5.5, Java 5, Firefox
Reporter: John Singleton
The panelTabbedPane here:
t:panelTabbedPane
styleClass=subtab
rendered=#{configuration.configNetworkEntity.id != 0}
serverSideTabSwitch=true
activeTabStyleClass=activeTab
inactiveTabStyleClass=inactiveTab
disabledTabStyleClass=disabledTab
activeSubStyleClass=activeSub
inactiveSubStyleClass=inactiveSub
tabContentStyleClass=tabContent
is being rendered as
table id=main__id18 class=myFaces_panelTabbedPane cellspacing=0
class=subtab
The problem seems to be in HtmlTabbedPaneRenderer :
protected void writeTableStart(ResponseWriter writer,
FacesContext facesContext,
HtmlPanelTabbedPane tabbedPane)
throws IOException
{
String oldBgColor = tabbedPane.getBgcolor();
tabbedPane.setBgcolor(null);
writer.startElement(HTML.TABLE_ELEM, tabbedPane);
writer.writeAttribute(HTML.ID_ATTR,
getTableStylableId(tabbedPane,facesContext), null);
writer.writeAttribute(HTML.CLASS_ATTR, myFaces_panelTabbedPane,
null);
writer.writeAttribute(HTML.CELLSPACING_ATTR, 0, null);
HtmlRendererUtils.renderHTMLAttributes(writer, tabbedPane,
HTML.TABLE_PASSTHROUGH_ATTRIBUTES);
writer.flush();
tabbedPane.setBgcolor(oldBgColor);
}
this method is writing the class attribute, and then the
HtmlRendererUtils.renderHTMLAttributes method writes the class attribute
based on the 'styleClass' attribute from the panelTabbedPane tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-592) panelTabbedPane: Duplicate class attributes
[ http://issues.apache.org/jira/browse/TOMAHAWK-592?page=all ]
John Singleton updated TOMAHAWK-592:
Status: Patch Available (was: Open)
panelTabbedPane: Duplicate class attributes
---
Key: TOMAHAWK-592
URL: http://issues.apache.org/jira/browse/TOMAHAWK-592
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.3
Environment: Tomcat 5.5, Java 5, Firefox
Reporter: John Singleton
Attachments: HtmlTabbedPaneRenderer.java.patch
The panelTabbedPane here:
t:panelTabbedPane
styleClass=subtab
rendered=#{configuration.configNetworkEntity.id != 0}
serverSideTabSwitch=true
activeTabStyleClass=activeTab
inactiveTabStyleClass=inactiveTab
disabledTabStyleClass=disabledTab
activeSubStyleClass=activeSub
inactiveSubStyleClass=inactiveSub
tabContentStyleClass=tabContent
is being rendered as
table id=main__id18 class=myFaces_panelTabbedPane cellspacing=0
class=subtab
The problem seems to be in HtmlTabbedPaneRenderer :
protected void writeTableStart(ResponseWriter writer,
FacesContext facesContext,
HtmlPanelTabbedPane tabbedPane)
throws IOException
{
String oldBgColor = tabbedPane.getBgcolor();
tabbedPane.setBgcolor(null);
writer.startElement(HTML.TABLE_ELEM, tabbedPane);
writer.writeAttribute(HTML.ID_ATTR,
getTableStylableId(tabbedPane,facesContext), null);
writer.writeAttribute(HTML.CLASS_ATTR, myFaces_panelTabbedPane,
null);
writer.writeAttribute(HTML.CELLSPACING_ATTR, 0, null);
HtmlRendererUtils.renderHTMLAttributes(writer, tabbedPane,
HTML.TABLE_PASSTHROUGH_ATTRIBUTES);
writer.flush();
tabbedPane.setBgcolor(oldBgColor);
}
this method is writing the class attribute, and then the
HtmlRendererUtils.renderHTMLAttributes method writes the class attribute
based on the 'styleClass' attribute from the panelTabbedPane tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-592) panelTabbedPane: Duplicate class attributes
panelTabbedPane: Duplicate class attributes
---
Key: TOMAHAWK-592
URL: http://issues.apache.org/jira/browse/TOMAHAWK-592
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.3
Environment: Tomcat 5.5, Java 5, Firefox
Reporter: John Singleton
The panelTabbedPane here:
t:panelTabbedPane
styleClass=subtab
rendered=#{configuration.configNetworkEntity.id != 0}
serverSideTabSwitch=true
activeTabStyleClass=activeTab
inactiveTabStyleClass=inactiveTab
disabledTabStyleClass=disabledTab
activeSubStyleClass=activeSub
inactiveSubStyleClass=inactiveSub
tabContentStyleClass=tabContent
is being rendered as
table id=main__id18 class=myFaces_panelTabbedPane cellspacing=0
class=subtab
The problem seems to be in HtmlTabbedPaneRenderer :
protected void writeTableStart(ResponseWriter writer,
FacesContext facesContext,
HtmlPanelTabbedPane tabbedPane)
throws IOException
{
String oldBgColor = tabbedPane.getBgcolor();
tabbedPane.setBgcolor(null);
writer.startElement(HTML.TABLE_ELEM, tabbedPane);
writer.writeAttribute(HTML.ID_ATTR,
getTableStylableId(tabbedPane,facesContext), null);
writer.writeAttribute(HTML.CLASS_ATTR, myFaces_panelTabbedPane, null);
writer.writeAttribute(HTML.CELLSPACING_ATTR, 0, null);
HtmlRendererUtils.renderHTMLAttributes(writer, tabbedPane,
HTML.TABLE_PASSTHROUGH_ATTRIBUTES);
writer.flush();
tabbedPane.setBgcolor(oldBgColor);
}
this method is writing the class attribute, and then the
HtmlRendererUtils.renderHTMLAttributes method writes the class attribute based
on the 'styleClass' attribute from the panelTabbedPane tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1359) PortletExternalContextImpl.encodeNamespace called during portlet ActionRequest
[ http://issues.apache.org/jira/browse/MYFACES-1359?page=all ]
John Singleton updated MYFACES-1359:
Status: Open (was: Patch Available)
PortletExternalContextImpl.encodeNamespace called during portlet ActionRequest
--
Key: MYFACES-1359
URL: http://issues.apache.org/jira/browse/MYFACES-1359
Project: MyFaces Core
Type: Bug
Components: Portlet_Support
Versions: 1.1.5-SNAPSHOT
Environment: Facelets + Liferay 4.0.0
Reporter: John Singleton
Theis portlet fragment renders one of 2 components depending on the selection
in the selectOneMenu:
div xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
h:form
h:outputLabel for=listfoo/h:outputLabel
h:selectOneMenu value=${booleanTest.choice}
id=listf:selectItems value=#{booleanTest.selectList}//h:selectOneMenu
h:commandButton action=#{booleanTest.doIt}/
/h:form
h:outputText rendered=#{empty booleanTest.list} value=Empty/
h:dataTable rendered=#{! empty booleanTest.list}
value=#{booleanTest.list} var=l border=1
h:column
f:facet name=headerh:outputText value=Column//f:facet
h:outputText value=#{l}/
/h:column
/h:dataTable
/div
It's using this simple bean:
public class BooleanTest {
private ListString list = new ArrayListString();
private ListString emptyList = new ArrayListString();
private String choice = Foo;
private ListSelectItem selectList = null;
public ListString getList() {
if (choice.equals(Foo)) {
return emptyList;
} else {
if (list.isEmpty()) {
list = new ArrayListString();
list.add(Hello);
list.add(World);
list.add(!);
}
return list;
}
}
public String doIt() {
return success;
}
public ListSelectItem getSelectList() {
if (selectList == null) {
selectList = new ArrayListSelectItem();
selectList.add(new SelectItem(Foo, Foo));
selectList.add(new SelectItem(bar, bar));
}
return selectList;
}
public String getChoice() {
return choice;
}
public void setChoice(String choice) {
this.choice = choice;
}
}
When I first add this portlet to a page, I get the drop down list, the submit
button and the empty message. If I select the 'bar' entry in the list and
click submit I get the error, Can not call encodeNamespace() during a
portlet ActionRequest
It seems to be because MyFacesGenericPortlet.processAction calls
lifecycle.execute, which in turn starts createing components for the table
(which wasn't in the first call to the page). This calls encodeNamespace for
the new componenet IDs and thats when it falls over.
I fixed this by changing PortletExternalContextImpl.encodeNamespace to return
null instead of throwing an IllegalStateException. My application seems to be
working well with this solution, but I don't know if it might have any knock
on effects?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1359) PortletExternalContextImpl.encodeNamespace called during portlet ActionRequest
[ http://issues.apache.org/jira/browse/MYFACES-1359?page=all ]
John Singleton updated MYFACES-1359:
Status: Patch Available (was: Open)
PortletExternalContextImpl.encodeNamespace called during portlet ActionRequest
--
Key: MYFACES-1359
URL: http://issues.apache.org/jira/browse/MYFACES-1359
Project: MyFaces Core
Type: Bug
Components: Portlet_Support
Versions: 1.1.5-SNAPSHOT
Environment: Facelets + Liferay 4.0.0
Reporter: John Singleton
Theis portlet fragment renders one of 2 components depending on the selection
in the selectOneMenu:
div xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
h:form
h:outputLabel for=listfoo/h:outputLabel
h:selectOneMenu value=${booleanTest.choice}
id=listf:selectItems value=#{booleanTest.selectList}//h:selectOneMenu
h:commandButton action=#{booleanTest.doIt}/
/h:form
h:outputText rendered=#{empty booleanTest.list} value=Empty/
h:dataTable rendered=#{! empty booleanTest.list}
value=#{booleanTest.list} var=l border=1
h:column
f:facet name=headerh:outputText value=Column//f:facet
h:outputText value=#{l}/
/h:column
/h:dataTable
/div
It's using this simple bean:
public class BooleanTest {
private ListString list = new ArrayListString();
private ListString emptyList = new ArrayListString();
private String choice = Foo;
private ListSelectItem selectList = null;
public ListString getList() {
if (choice.equals(Foo)) {
return emptyList;
} else {
if (list.isEmpty()) {
list = new ArrayListString();
list.add(Hello);
list.add(World);
list.add(!);
}
return list;
}
}
public String doIt() {
return success;
}
public ListSelectItem getSelectList() {
if (selectList == null) {
selectList = new ArrayListSelectItem();
selectList.add(new SelectItem(Foo, Foo));
selectList.add(new SelectItem(bar, bar));
}
return selectList;
}
public String getChoice() {
return choice;
}
public void setChoice(String choice) {
this.choice = choice;
}
}
When I first add this portlet to a page, I get the drop down list, the submit
button and the empty message. If I select the 'bar' entry in the list and
click submit I get the error, Can not call encodeNamespace() during a
portlet ActionRequest
It seems to be because MyFacesGenericPortlet.processAction calls
lifecycle.execute, which in turn starts createing components for the table
(which wasn't in the first call to the page). This calls encodeNamespace for
the new componenet IDs and thats when it falls over.
I fixed this by changing PortletExternalContextImpl.encodeNamespace to return
null instead of throwing an IllegalStateException. My application seems to be
working well with this solution, but I don't know if it might have any knock
on effects?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
RE: [jira] Commented: (TOBAGO-84) Could we please have a sheetSelectionListener
submit a patch. I wouldn't even know where to start within the project source, to provide an additional listener. Apparently, the component's renderer outputs html which ties the surface onclick=Tobago.submitAction to the backend. But then: ??? John -Original Message- From: Matthias Weßendorf (JIRA) [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 9:12 PM To: John Subject: [jira] Commented: (TOBAGO-84) Could we please have a sheetSelectionListener [ http://issues.apache.org/jira/browse/TOBAGO-84?page=comments#action_12416654 ] Matthias Weßendorf commented on TOBAGO-84: -- would be great if you submit a patch for this. thx, matthias Could we please have a sheetSelectionListener - Key: TOBAGO-84 URL: http://issues.apache.org/jira/browse/TOBAGO-84 Project: MyFaces Tobago Type: New Feature Components: Core Environment: Cross Reporter: John Allan It's particularly difficult to code sheet-based screens of any complexity, without the basic capability to react when row selection changes, without the need to hand-fire an action before reading sheetState info for selections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-84) Could we please have a sheetSelectionListener
Could we please have a sheetSelectionListener - Key: TOBAGO-84 URL: http://issues.apache.org/jira/browse/TOBAGO-84 Project: MyFaces Tobago Type: New Feature Components: Core Environment: Cross Reporter: John Allan It's particularly difficult to code sheet-based screens of any complexity, without the basic capability to react when row selection changes, without the need to hand-fire an action before reading sheetState info for selections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-83) Would like basic text alignment functionality for text components
Would like basic text alignment functionality for text components - Key: TOBAGO-83 URL: http://issues.apache.org/jira/browse/TOBAGO-83 Project: MyFaces Tobago Type: New Feature Components: Core Versions: 1.0.7 Reporter: John Allan I was surprised to learn that text components, such as tx:in tc:out, etc did not provide basic horizontal text alignment capability. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-69) t:image does not support a png image with a transparent background - displays background as mid-grey
t:image does not support a png image with a transparent background - displays background as mid-grey Key: TOBAGO-69 URL: http://issues.apache.org/jira/browse/TOBAGO-69 Project: MyFaces Tobago Type: Bug Versions: 1.0.7 Environment: Tomcat 5.15 - IE Reporter: John Allan Priority: Minor Pretty much summed up in the summary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: future vision for MyFaces commons
On 3/10/06, Manfred Geiler [EMAIL PROTECTED] wrote: Pong!;-):-) Let's focus on shared and current release process now. After release is out we start the initiation of the new commons-jsflib and continue the discussion. Ok?No problem, let's make sure not to lose the progress already made in this thread. Kind Regards,John Fallows. On 3/10/06, John Fallows [EMAIL PROTECTED] wrote: Ping? On 3/2/06, John Fallows [EMAIL PROTECTED] wrote: On 3/1/06, Manfred Geiler [EMAIL PROTECTED] wrote: On 3/1/06, John Fallows [EMAIL PROTECTED] wrote:We need to define the meaning of with more caution. Terms for future commons utils and helpers: * stable API+1. :-) * downward compatibility within major version numbers +1. Backwards compatible at runtime, compile time or both? * separation between API and Impl (to achieve the latter two) +1. Separated by different packages, JARs, or both? * not MyFaces specific+1.These APIs might become candidates for inclusion in future versions of the JSF specification. Would the compilation dependency graph look something like this? [myfaces-commons-api] --depends-on-- [jsf-api] [myfaces-commons-impl] --depends-on-- [myfaces-commons-api, jsf-api] [myfaces-tomahawk] --depends-on-- [myfaces-commons-api, jsf-api] Would the following compilation dependency be avoided? [myfaces-tomahawk] --depends-on-- [myfaces-commons-impl] * make sense for all or many JSF component authors and/or app developers +1. More? Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress-- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: The annual MyFaces JavaOne party/dinner
Count me in - it was great fun last year!tc,-john.On 3/9/06, Jonas Jacobi [EMAIL PROTECTED] wrote: Hi All, Its getting close to JavaOne and it is time to add the MyFaces JavaOne Party to your calendar. As we did last year, there is no set date this early on, but we need to know now how many are interested in coming to a MyFaces night out during JavaOne (May 16th - 19th, 2006). With this information we can plan and book the right venue for the party/dinner. Last year ~20 MyFaces fans met at the Thirst Bear for a dinner and a few beers (http://myfaces.apache.org/community/javaone2005_cometogether.html), and, of course, lot of interesting discussions about JSF and web frameworks in general. This year we hope that more fans will come and join us for a night out. Please let us know if you are interested in joining up at the MyFaces party as soon as possible. Note: JavaOne is a month early compared to last year and that is why you see this invite now :) Last year Oracle sponsored the evening, and they sure will this year :), but we would love to see more sponsors contribute to ensure that this will be a very memorable happening. Thanks, Jonas -- Author: Pro JSF and Ajax: Building Rich Internet Components Blog: http://www.orablogs.com/jjacobi -- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: future vision for MyFaces commons
Ping?On 3/2/06, John Fallows [EMAIL PROTECTED] wrote: On 3/1/06, Manfred Geiler [EMAIL PROTECTED] wrote: On 3/1/06, John Fallows [EMAIL PROTECTED] wrote: We need to define the meaning of with more caution.Terms for future commons utils and helpers: * stable API+1. :-) * downward compatibility within major version numbers +1.Backwards compatible at runtime, compile time or both? * separation between API and Impl (to achieve the latter two)+1.Separated by different packages, JARs, or both? * not MyFaces specific+1. These APIs might become candidates for inclusion in future versions of the JSF specification.Would the compilation dependency graph look something like this? [myfaces-commons-api] --depends-on-- [jsf-api][myfaces-commons-impl] --depends-on-- [myfaces-commons-api, jsf-api][myfaces-tomahawk] --depends-on-- [myfaces-commons-api, jsf-api]Would the following compilation dependency be avoided? [myfaces-tomahawk] --depends-on-- [myfaces-commons-impl] * make sense for all or many JSF component authors and/or app developers +1. More? Kind Regards, John Fallows.-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress -- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: future vision for MyFaces commons
On 3/1/06, Manfred Geiler [EMAIL PROTECTED] wrote: On 3/1/06, John Fallows [EMAIL PROTECTED] wrote: We need to define the meaning of with more caution.Terms for future commons utils and helpers: * stable API+1. :-) * downward compatibility within major version numbers +1.Backwards compatible at runtime, compile time or both? * separation between API and Impl (to achieve the latter two)+1.Separated by different packages, JARs, or both? * not MyFaces specific+1. These APIs might become candidates for inclusion in future versions of the JSF specification.Would the compilation dependency graph look something like this? [myfaces-commons-api] --depends-on-- [jsf-api][myfaces-commons-impl] --depends-on-- [myfaces-commons-api, jsf-api][myfaces-tomahawk] --depends-on-- [myfaces-commons-api, jsf-api]Would the following compilation dependency be avoided? [myfaces-tomahawk] --depends-on-- [myfaces-commons-impl] * make sense for all or many JSF component authors and/or app developers +1. More?Kind Regards, John Fallows.-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: future vision for MyFaces commons
On 2/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: On 2/23/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote: In response to #1 I would say we do not need to be in the business of ensuring developers can rely on our public API's.From my perspective we are in the business of providing a JSF implementation and a series of components and addons for use in any JSF implementation. And how are we going to develop components?By reinventing the wheel every time? There's certainly a class of common building blocks that can and should be considered a public API. Why should every single component developer have to reinvent fetching localized messages? Or evaluating value bindings in a consistent manner? No, this is exactly the reason why there will still be a (new)myfaces-commons lib in the future. Now, closer looks at the code andcurrent state of the myfaces commons subproject have shown that thelegitimate expectations (stable API, clear separation of API and impl) cannot be fulfilled now. We had some discussions before on callingthis subproject commons or shared. We decided wrong at first. Iadmit that I did participate in this wrong decision as well. But we have learned our lesson and now go back to the start. What is now incommons will be moved to myfaces-shared. Myfaces-commons will beflushed. What is worth will be moved back to commons ASAP. But withmore caution and not before 1.1.2 release.Hope, everyone feels ok with this plan.We need to define the meaning of with more caution.Kind Regards,John Fallows.-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: future vision for MyFaces commons
On 2/22/06, Adam Winer [EMAIL PROTECTED] wrote: Definitely.I think we need to extract a few issues here,and consider them separately.(1) Do we need to be in the practice of identifying APIs that external developers can depend on, and are not subject to change. If so, how?(2) Do we consider Tomahawk, Tobago, and ADF as purelyinternal codebases that therefore can depend on anything,or do we define explicit contracts between the various partsof the overall MyFaces codebase?In particular, do we define subparts of the architecture as internal even within the project?(3) Do we split up JARs, and if so what do we name them?#3 is pretty minor, and not the big deal here - I'd rather Johnhadn't even mentioned it, since it's very easy to get sidetracked on what is a relatively minor sidepoint.Needs to get talkedabout at some point, but until we've decided that there shouldeven be two JARs or what they'd contain, doesn't make muchsense to talk about what they should be called! You're totally right Adam - I was getting ahead of myself. :-)Let's focus on #1 and #2 for now. #1 is something that's very important.I'm deeply uncomfortablewith the notion of just identifying internal classes with Javadoc,for two main reasons:- Developers will have no rigorous approach to marking such classes, and will almost certainly routinely fail to do soproperly.The quantity of code in MyFaces with little or noJavadoc is a bit discouraging.(Total digression:if there isn'tsuch a rule already, nothing should get out of Sandbox without complete Javadoc.)- End users have no quick way to look at their code and audit itthey're using illicit code.Contrast that to the ease of sayingam I using javax.faces or com.sun.faces /org.apache?The current reality of the MyFaces codebase is that such distinctionsaren't made at all.In the Tomahawk components, the componentclass, the Renderer, and the Tag are all public classes in the same package, with no Javadoc indication of public or private status.Are these all really public APIs that can be freely relied on?The approach we've used in the ADF Faces codebase - andbeen very happy with - is to separate out the API and IMPL by using different Java packages and JARs.That makes ittrivial for end users to audit their code, or even better toprevent such dependencies from ever creeping in by onlyadding a compile dependency on the API jar. #2 may not seem important yet, but as the MyFaces codebasegrows in size, it will become really, really important to makingprogress.Without well-defined and minimal dependencies ofthe external projects on commons, it will become difficult to make interesting changes to commons.For example, takethe script-injection code in AddResource;why the dependencieson Servlet APIs?If I wanted to tackle this, how much code inthe rest of the codebase do I have to analyze and possibly re-code?I see three potential levels:- Totally public APIs.- APIs that are public *within* MyFaces, but private externally- APIs that are private even *within* MyFaces, that is,only a very limited set of closely related code can depend on it.The middle of these intuitive seems the least desirable - as Manfredpoints out, why should code that is acceptable for use by allcomponent libraries be unacceptable for general use? But as I understand the current approach, that's what the myfaces-commonswould in fact be.-- AdamOn 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote: I agree with Manfred that we should not rename the implementation jars (myfaces-impl.jar and myfaces-api.jar) for the reasons he has stated. Even if you take Maven out of the picture you don't want to clash with jar names the RI is using. Naming is only a small part of what John is suggesting, however.I think he is onto something here even though I don't necessarily agree with all of the proposed solutions to the issue. The issue that John raises that interests me is the future inclusion of Tobago and ADF.There may be code that could be shared between these two projects and Tomahawk that has nothing to do with impl.So essentially we are talking about another core for components. I'm not sure how much overlap there is although on the surface there seems to be a lot.I will need to dive deeper into the two projects before I could say for sure.Lets take the tree case since I am not familiar with the file upload component and presumably John is familiar with the ADF tree.Is it possible to have a single component shared between Tomahawk and ADF and only have different renderers in the separate subprojects?That would be interesting and probably more realistic then an outright merger of the two trees. If something like this is possible then maybe we could have a tomahawk-core.jar with the components and tomahawk-impl.jar with the tags, renderers and config files? Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: On 2/21/06, John Fallows [EMAIL PROTECTED] wrote: Folks, There seems to be increasing discussion lately regarding MyFaces
Re: Refactor Commons to org.apache.myfaces.commons ?
Maven2 is even smarter that you might realize. :-)(see below)On 2/20/06, Sean Schofield [EMAIL PROTECTED] wrote:Wow that seems really complicated.I have serious concerns about last minute search and replace on the source code.There's got to be aeasier solution.Until we started down the maven path we were finewith the way it is.Lets re-examine why we are considering this inthe first place. Manfred's scenario ...Scenario:1. We release commons-1.1.2 + core 1.1.2 (core 1.1.2 depends on commons-1.1.2)2. days go by...3. We release commons-1.1.3 (because there where significant changes) + tomahawk 1.1.3 (which depends on commons-1.1.3)So, there are now the following official releases out there:commons-1.1.2commons-1.1.3core-1.1.2tomahawk-1.1.3User happy starts his brandnew Maven project unlucky, decides to use the latest stable releases of everything and defines the followingdependencies:XY depends on myfaces-api 1.1.2 (scope compile)XY depends on myfaces-impl 1.1.2 (scope runtime)XY depends on tomahawk 1.1.3 (scope compile)Now he builds the WAR. Guess what he ends up with?WEB-INF/lib/myfaces-api-1.1.2.jarWEB-INF/lib/myfaces-commons-1.1.2.jarWEB-INF/lib/myfaces-commons-1.1.3.jarWEB-INF/lib/myfaces- impl-1.1.2.jarWEB-INF/lib/myfaces-tomahawk-1.1.3.jarOnly one version of commons will be selected, so either commons-1.1.2 or commons-1.1.3 but not both, as long as both versions have the same groupId and artifactId in the Maven2 repository. I'm not totally certain of the exact selection algorithm used by Maven2 to choose the winning version, but I believe selecting the latest version makes the most sense. Kind Regards,John Fallows.I think we can solve this usecase without resorting to last minute code refactoring by maven, or even worse, changing bytecode around.Ijust don't think those solutions are necessary.One solution could be is that we make the scope of the commonsdependency in core and tomahawk to be provided.That way its not transitive and you don't end up with two versions of the commons jarin your WAR.What that means is that you need to declare explicitly acommons dependency in your project as well as core and/or tomahawk. In this case you would just say your project depends on commonsversion 1.1.3.Everything will be fine as long as 1.1.3 does notbreak backwards compatability with an earlier version of the core.Wecan easily test this when we release tomahawk and if it does break backwards compatability, we can release a newer version of the core aswell.Its not ideal but its much better then the other alternatives we areconsidering.I think we carefully document and explain this on the website and include instructions and considerations for those buildingwith maven or using myfaces implementation in their J2EE containers.SeanOn 2/18/06, Manfred Geiler [EMAIL PROTECTED] wrote: As Martin already has mentioned, I'm more and more convinced too, that repackaging commons for impl is the only solution that will make as carefree in the long run. Though, I do not agree that it is necessary or advantageous to repackage commons for all component libs (tomahawk, tobago, adffaces). This would bring commons far away from the original idea of having a Jakarta commons like JSF library with goodies and convenient base classes for custom components. Yes, people will probably have conflicts. But the release cycles of our component libs should be fast enough and commons should become stable enough, so that this is no longer a problem. MyFaces-Core (ie. impl) is different insofar as* we want to keep release cycles at a minimum * it will become integrated part of containers (already shipped with JBoss 4.x), or* people make them part of their containers by sharing myfaces-api.jar and myfaces-impl.jar in the containers common/lib or shared/lib dir. The last two points also will have influence on how people will configure their own Maven projects: provided dependency on myfaces-api.jar and myfaces-impl.jar of the version that was shipped with (or is integrated in) the container. People will behave conservative in changing their container environment and behave liberal when using the newest component lib. However, as soon as we have a repackaging solution, it is easy enough to use it not only for impl. So, let's discuss repackaging in general first and postpone the question of using repackaged commons lib for tomahawk et al. for a while, ok? Here is my idea for a (not-so-high-sophisticated but) easy repackaging solution: 1. First of all we refactor Commons to org.apache.myfaces.commons.* (we already have an agreement on this) 2. Next we create a sub-project in commons. Working title intermediate-commons-impl. = This project's outcome will be the intermediate-commons-impl.jar file with all commons classes auto-repackaged to org.apache.myfaces.commons.impl.* (like proposed by Simon). = This jar file will not be shipped or included in any assembly (therefore intermediate). It only serves as the Maven-way medium
future vision for MyFaces commons
Folks,There seems to be increasing discussion lately regarding MyFaces Commons and how it relates to both MyFaces Core and MyFaces Tomahawk. Adding Tobago and ADF Faces to the discussion makes it even more critical that we come up with a useful way to share reusable code between the various projects. So, I thought it might be helpful to the current discussion if I shared my thoughts about this for the future. Right now, we tend to think of MyFaces Commons as a dumping ground for common utility code that is reused between the Core and Tomahawk, and AFAIK, none of this code has been vetted for its suitability as a consistently backwards-compatible public API. In future, we'll need to provide common code to all component libraries developed as part of the MyFaces effort (and outside MyFaces too), and due to the independent upgrade requirements for individual component libraries, that common codebase will need to provide a guarantee of backwards compatiblilty. One example of such shared code for the future might be a common strategy for the FileUpload feature. It would be a real shame if all of the internal implementation code for this FileUpload feature became part of a public API just because it was added to Commons. So, I propose a split in Commons between public API and private implementation. In fact, I think it shouldn't be called Commons either. :-) [groupId = org.apache.myfaces]myfaces-api-x.y.z.jarmyfaces-impl-x.y.z.jarDependent projects should be free to create compile-time dependencies against myfaces-api, but not myfaces-impl. The code currently in Commons will need an overhaul to prepare it for such backwards compatibility strictness. We should take a hard look at the codebase in there and decide how best to trim it to a managable size that can realisticly be kept compatible across releases. Now, this raises the point about the naming for the current API and implementation for the specification. How about the following?[groupId = org.apache.myfaces] jsf-api-a.b.c.jarjsf-impl-a.b.c.jarI think this makes two things very clear.MyFaces spec api and impl do not contain any non-spec related code (i.e. no non-portable extensions to the spec) MyFaces spec api and impl are equivalents of the reference api and impl from Sun In addition, we might need to break the dependency between jsf-impl-x.y.z.jar and myfaces-api-x.y.z.jar/my-faces-impl.x.y.z.jar above. This may still involve inlining commons into the jsf-impl JAR to avoid potential problems with JavaEE containers vs. webapp ClassLoaders. It certainly feels better to have a directed dependency from the MyFaces API / Impl - standard JSF API / Impl rather than the reverse. :-)Btw, do JavaEE containers, e.g. Tomcat, properly isolate the Webapp ClassLoader from the container's own ClassLoader, preventing visibility of jsf-impl and only exposing jsf-api to the Webapp ClassLoader? This should be perfectly possible using appropriate ClassLoader parentage, but I'm not certain if it is commonly done or mentioned in the JavaEE specification. For Tomahawk, Tobago and ADF Faces, we can have the following.[groupId = org.apache.myfaces]tomahawk-api-d.e.f.jartomahawk-impl-d.e.f.jar tobago-api-g.h.i.jartobago-impl-g.h.i.jaradf-faces-api-j.k.l.jar*adf-faces-impl-j.k.l.jar* where each has a compile time dependeny on both jsf-api and myfaces-api but only a runtime dependency on the internal implementation details of jsf-impl and myfaces-impl.*adf-faces to be renamed during incubation. When any of these projects need to be upgraded, and it depends on a newer version of myfaces-api / myfaces-impl, the upgrade can proceed with confidence because the newer version guarantees backwards compatibilty at compile-time for myfaces-api and at runtime for myfaces-impl. Thoughts?Kind Regards,John Fallows.-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: JSF 1.2 in a Maven 1 Repo
On 2/20/06, Martin Marinschek [EMAIL PROTECTED] wrote: one / zero = infinity ;-)you talk about the configuration of the ExtensionsFilter there, right?;)no line - no mailsone line - infinite amount of mailsPrecisely. ;-) regards,MartinOn 2/21/06, John Fallows [EMAIL PROTECTED] wrote: On 2/18/06, Ed Burns [EMAIL PROTECTED] wrote: On Fri, 17 Feb 2006 21:05:40 -0800, John Fallows [EMAIL PROTECTED] said: JF Wendy is exactly right.Of course, it would be much more convenient JF if the JSF 1.2 jars were on ibiblio.org to avoid the extra JF configuration to pick up the java.netrepository. much, I don't know about that.How hard is one line? one / zero = infinity ;-) I agree though, at least there is only one line in the pom.xml shared by all users as opposed to one line of extra configuration *per user* as originally posted. JF I believe there is work already underway to establish an automatic JF sync for some of the java.net artifacts to ibiblio.org. There are legal issues that must be resolved to make this happen. Believe me, I had to work with lawyers just to enable getting the jars out on java.net. Yep, guessed as much - that's why I was wondering if any additional progress had been made on this front at the same time. Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress-- http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: FactoryFinder.releaseFactories() - was [continuum] BUILD FAILURE: API
fyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed by ContextClassLoader (including FactoryFinder internal state), we created a trivial wrapper ClassLoader to provide a unique ContextClassLoader in setUp() and restore it back to the original in tearDown(). Kind Regards,John Fallows.On 2/20/06, Sean Schofield [EMAIL PROTECTED] wrote: The call is required in the setUp() method to make things work correctly on the *first* test, when you have the MyFaces implementation in the classpath of the tests.Calling it in tearDown() doesn't hurt anything, but protects test developers who try to subvert the JUnit test lifecycle stuff.Exactly.I don't think its necessary in the teardown but it won't hurt.Its *defnitely* needed in the setup for the reason youmentioned. CraigSean-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: JSF 1.2 in a Maven 1 Repo
On 2/18/06, Ed Burns [EMAIL PROTECTED] wrote: On Fri, 17 Feb 2006 21:05:40 -0800, John Fallows [EMAIL PROTECTED] said:JF Wendy is exactly right.Of course, it would be much more convenient JF if the JSF 1.2 jars were on ibiblio.org to avoid the extraJF configuration to pick up the java.netrepository.much, I don't know about that.How hard is one line? one / zero = infinity ;-)I agree though, at least there is only one line in the pom.xml shared by all users as opposed to one line of extra configuration *per user* as originally posted. JF I believe there is work already underway to establish an automaticJF sync for some of the java.net artifacts to ibiblio.org.There are legal issues that must be resolved to make this happen.Believe me, I had to work with lawyers just to enable getting the jars out on java.net.Yep, guessed as much - that's why I was wondering if any additional progress had been made on this front at the same time.Kind Regards,John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: FactoryFinder.releaseFactories() - was [continuum] BUILD FAILURE: API
Hi Dennis,On 2/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: Do you guys have anything fancy for ThreadLocal references of FacesContext?Did you set this to null per TestSuite? per TestCase? per test method ?Yes, IIRC there is a TestFacesContextFactory implicitly registered with the FactoryFinder by controlling the ContextClassLoader.getResource(), and that TestFacesContextFactory manages the ThreadLocal FacesContext reference to make sure it gets cleaned up during FacesTestCase.tearDown().Kind Regards,John Fallows. Dennis Byrne-Original Message-From: John Fallows [mailto: [EMAIL PROTECTED]]Sent: Tuesday, February 21, 2006 12:07 AMTo: 'MyFaces Development'Subject: Re: FactoryFinder.releaseFactories() - was [continuum] BUILD FAILURE: APIfyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed byContextClassLoader (including FactoryFinder internal state), we created atrivial wrapper ClassLoader to provide a unique ContextClassLoader in setUp() and restore it back to the original in tearDown().Kind Regards,John Fallows.On 2/20/06, Sean Schofield [EMAIL PROTECTED] wrote: The call is required in the setUp() method to make things work correctly on the *first* test, when you have the MyFaces implementation in the classpath of the tests.Calling it in tearDown() doesn't hurt anything, but protects test developers who try to subvert the JUnit test lifecycle stuff. Exactly.I don't think its necessary in the teardown but it won't hurt.Its *defnitely* needed in the setup for the reason you mentioned. Craig Sean-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: JSF 1.2 in a Maven 1 Repo
Wendy is exactly right.Of course, it would be much more convenient if the JSF 1.2 jars were on ibiblio.org to avoid the extra configuration to pick up the
java.net repository.I believe there is work already underway to establish an automatic sync for some of the java.net artifacts to ibiblio.org.
Kind Regards,John Fallows.On 2/15/06, Ed Burns [EMAIL PROTECTED] wrote:
On Tue, 14 Feb 2006 13:00:38 -0500, Sean Schofield [EMAIL PROTECTED] said:SS Are there plans for maven2 artifacts?I've heard it's possible to access an m1 repo from m2.
We'll try to update the plugin to m2 and take it from there.Ed--| [EMAIL PROTECTED]| {home: 407 869 9587, office: 408 884 9519 OR x31640}| homepage: |
http://purl.oclc.org/NET/edburns/| aim: edburns0sunw | iim: [EMAIL PROTECTED]| 63 Business Days until JavaOne SF 2006
-- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: ADF Faces
Thanks for stepping up Craig. :-)tc,-john.On 2/15/06, Jonas Jacobi [EMAIL PROTECTED] wrote:Fantastic!Thanks a lot CraigBest regards,Jonas -- Forwarded message --From: Adam Winer [EMAIL PROTECTED]To: MyFaces Development dev@myfaces.apache.org Date: Wed, 15 Feb 2006 08:05:55 -0800Subject: Re: ADF FacesExcellent news - thanks, Craig!-- AdamOn 2/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/14/06, Adam Winer [EMAIL PROTECTED] wrote: Thanks, Martin. :)Though I like to think of myself as the Godfather of JSF (I've made Ed some offers he couldn't refuse).Hans Bergsten is JSF's uncle who doesn't write anymore.Jacob Hookom married into the JSF family.I'd go further but I'd get myself into trouble. Too late :-). I happen to qualify for the mentor role for ADF Faces (Apache Member), and I was the mentor for MyFaces when it first joined.I've also done some negotiating with my day job friends at Sun, and would be happy to accept the role of mentor, if you guys will have me. -- Adam Craig-- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: Re: Bookmarking, History and JSF
Maybe I'm missing something, but I don't understand why state saving and bookmarking are related.Isn't a bookmark something you would potentially paste into an email and send to your friend? There doesn't seem to be any assosicated state present in the URL or on the server, so why do we need encryption?
Perhaps this is related to traversing the same bookmarkable link while navigating within the application in the same browser session?Kind Regards,John Fallows.On 1/30/06,
Martin Marinschek [EMAIL PROTECTED] wrote:
As for the security of proposal2)if we do client-side state-saving, we do encryption, right? Would wehave to do encryption here, too, to make this more secure?Would that run against the notion of readable, nice bookmarks? Probably yes...
regards,MartinOn 1/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi John, ok - so you agree with me that the renderer has to take care of that?
Cause I still don't get that getURL stuff from the navigation-handler - It would be great if you could elaborate on that. as for saving parameters, I see three approaches cristalizing out now:
1) configure in the navigation rules what the URL will look like (which parameters are to be added, which beans they refer to) (John) 2) add parameters to the link, configure a saveState as bookmarkable,
etc.. and write the renderer as such that this data is automatically added to the link and can be automatically applied by the faces backend (this is potentially insecure as you might be able to pass in
any parameter, and set any bean property to any, potentially insecure value) (Matze al) 3) try to get faces to do automatically the stuff it usually does (Jacob, Mario al) - I haven't heard for this approach how partial
state saving is supposed to be done - just have a partial state rendered, which is then applied to the URL?) is this listing somewhat correct? Please repost differently if you see something different.
regards, Martin On 1/30/06, John Fallows [EMAIL PROTECTED] wrote: Thanks Adam! ;-)
I've been thinking about this a bit more recently. One of the JSF's strengths is it's clean separation between agent-specific details in the renderers, and it's more general component and event model
abstraction that can easily be leveraged by application developers. In the case of navigation and bookmarkability, I believe there is a danger of getting caught up in the web application use case, and failing to
maintain this abstraction.For example, there has been some discussion of consuming URL request parameters directly in the application definition. Some folks might say that bookmarking only applies to web applications
anyway, so what's the big deal with breaking the abstraction here.Thinking about this point helped me to realize that that although you might not explicitly bookmark a dialog in your favorite Java development tool for
example, you would expect it to re-open the last project you were editing when you next open that tool.I think this is a very similar feature to bookmarking, just a bit more implicit, eg. auto-bookmark-on-exit.
So, what are the properties of a bookmark?Well, I believe it defines an entry-point for a flow, rather than a single page, with arbitrary initialization requirements.For the web application case, this is
obviously an HTTP GET request with some request parameters, that need to be pushed into a backing bean so they can be accessed during initialization of the flow. Similar to the concept of a Converter together with UIInput processing
model in JSF, I think we need a bidirectional mapping for generation of the bookmarkable URL and later initialization of the flow.As with all agent-specific features in JSF, this should be routed through an API on the
RenderKit to maintain the appropriate abstraction layering, and an event should be raised on the Flow/Page to allow initialization processing to occur prior to initial rendering.
The context in which the bookmarkable URL is defined would require access to potentially locally scoped JSF variables, like row, so the attachment of bookmark parameters would need to be defined logically close to the
component hierarchy. h:commandButton action="" f:param name=id value=#{row.id} /
/h:commandButton One can imagine the CommandButtonRenderer generating a bookmark URL with an id parameter, due to the bookmark definition below.
Later processing of the bookmark request has no component hierarchy available, so this needs to be defined in the context of the navigation rules. navigation-rule
outcomebookmarkShowRow/outcome to-view-idshowRow.jspx/to-view-id bookmark param param-nameid/param-name
param-value#{showRowBean.rowId}/param-value /param actionshowRowBean.onVisitBookmark/action /bookmark
/navigation-rule On initial render of showRow.jspx, the RenderKit can consume the id request parameter to push it into the showRowBean's rowId property before processing
the initialization logic in the s
Re: Re: Bookmarking, History and JSF
Thanks Adam! ;-)
I've been thinking about this a bit more recently.
One of the JSF's strengths is it's clean separation between
agent-specific details in the renderers, and it's more general
component and event model abstraction that can easily be leveraged by
application developers.
In the case of navigation and bookmarkability, I believe there is a
danger of getting caught up in the web application use case, and
failing to maintain this abstraction. For example, there has been
some discussion of consuming URL request parameters directly in the
application definition. Some folks might say that bookmarking
only applies to web applications anyway, so what's the big deal with
breaking the abstraction here. Thinking about this point helped
me to realize that that although you might not explicitly bookmark a
dialog in your favorite Java development tool for example, you would
expect it to re-open the last project you were editing when you next
open that tool. I think this is a very similar feature to
bookmarking, just a bit more implicit, eg. auto-bookmark-on-exit.
So, what are the properties of a bookmark? Well, I believe it
defines an entry-point for a flow, rather than a single page, with
arbitrary initialization requirements. For the web application
case, this is obviously an HTTP GET request with some request
parameters, that need to be pushed into a backing bean so they can be
accessed during initialization of the flow.
Similar to the concept of a Converter together with UIInput processing
model in JSF, I think we need a bidirectional mapping for generation of
the bookmarkable URL and later initialization of the flow. As
with all agent-specific features in JSF, this should be routed through
an API on the RenderKit to maintain the appropriate abstraction
layering, and an event should be raised on the Flow/Page to allow
initialization processing to occur prior to initial rendering.
The context in which the bookmarkable URL is defined would require
access to potentially locally scoped JSF variables, like row, so the
attachment of bookmark parameters would need to be defined logically
close to the component hierarchy.
h:commandButton action=""
f:param name=id value=#{row.id} /
/h:commandButton
One can imagine the CommandButtonRenderer generating a bookmark URL
with an id parameter, due to the bookmark definition below.
Later processing of the bookmark request has no component hierarchy
available, so this needs to be defined in the context of the navigation
rules.
navigation-rule
outcomebookmarkShowRow/outcome
to-view-idshowRow.jspx/to-view-id
bookmark
param
param-nameid/param-name
param-value#{showRowBean.rowId}/param-value
/param
actionshowRowBean.onVisitBookmark/action
/bookmark
/navigation-rule
On initial render of showRow.jspx, the RenderKit can consume the id
request parameter to push it into the showRowBean's rowId property
before processing the initialization logic in the showRowBean
onVisitBookmark method.
Notice that there a no direct references to any request parameters,
this is implicitly managed by the RenderKit. The showRowBean is
also defined by the application developer, with no dependencies on the
request.
Now let's see what happens when this design is reused in the context of a non-web application, say Telnet. ;-)
Suppose we login to the telnet-based application and are presented with
a menu of options, with a list of user-defined shortcuts including
your most recently filed expense report. At the time this
shortcut (bookmark) was captured, only the expense report number was
used, much like the above example of row identifier. When the
expense report shortcut is selected, the application logic to
initialize state is captured inside the showRowBean as before. No
changes are necessary in the application logic due to a change in
RenderKit, which is internally managing the rendering and decoding of
these bookmarkable shortcuts, and may choose any convenient strategy to
capture bookmark parameters.
Anyway, just thinking out loud... ;-)
Kind Regards,
John Fallows.
On 1/27/06, Adam Winer [EMAIL PROTECTED] wrote:
BTW, a credit-where-it's-due:I should be clear that my idea'salways been... completely omits that this idea is very muchdue to John Fallows!-- AdamOn 1/27/06, Adam Winer
[EMAIL PROTECTED] wrote: My idea's always been something like an optional NavigationHandler interface: public interface BookmarkableNavigationHandler { /*** Return an URL if the MethodExpression can be handled purely
* as a GET request, or null if it cannot be done.*/ public String getUrl(FacesContext, MethodExpression) } This would enable a NavigationHandler to turn constant MethodExpressions,
like action="" into simple GET URLs.(The optional interface idea does run into serious problems with any decorating NavigationHandlers; ADF Faces uses a Service API kinda like the old MS OLE IUnknown
QueryInterface approach, if you've had the misfortune of developing any OLE
RE: FW: Common submit button not working in IE 5
Point taken - I have started looking and will submit to JIRA by EOW -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 3:33 PM To: MyFaces Development Subject: Re: FW: Common submit button not working in IE 5 I think you're the best person to address this! This is clearly a problem with the generated HTML/javascript, and that's all in the generated page. This means that you can do view source, save the resulting page then test in IE to find out what is wrong with the generated code. Once you figure that out (ie what html/javascript changes are needed to make this work in IE) please submit a JIRA entry. With that info available, it will be reasonably simple for a MyFaces maintainer to make the necessary change. Regards, Simon On Tue, 2006-01-24 at 14:52 -0500, Miller, John wrote: Has anyone addressed this? __ From: Miller, John [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 1:07 PM To: MyFaces Discussion Subject: Common submit button not working in IE 5 The Common Submit button does not seem to work in the Faces examples for IE5. This can be seen by going to the tabbedPane.jsf page of the sample and clicking the Common Submit button and nothing happen. The Code seems to work fine in Firefox. I am also noticing this same behavior in my own app, and is causing major problems with my JSF migration. If anyone has seen this and/or has the workaround, that would be great. NOTICE: This message, including all attachments transmitted with it, is for the use of the addressee only. It may contain proprietary, confidential and/or legally privileged information belonging to Litle Co. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, you must not, directly or indirectly, use, disclose, distribute, print or copy any part of this message. If you believe you have received this message in error, please delete it and all copies of it from your system and notify the sender immediately by reply e-mail. Thank you. NOTICE: This message, including all attachments transmitted with it, is for the use of the addressee only. It may contain proprietary, confidential and/or legally privileged information belonging to Litle Co. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, you must not, directly or indirectly, use, disclose, distribute, print or copy any part of this message. If you believe you have received this message in error, please delete it and all copies of it from your system and notify the sender immediately by reply e-mail. Thank you.
Re: Client-ID
Folks, On 1/25/06, Adam Winer [EMAIL PROTECTED] wrote: The intention of clientId is to provide an identifier that can beused in markup and therefore to refer to elements on the client.The point of findComponent() is find UIComponents on the server,generally given known (that is, explicitly set) IDs (and I mean id, setId(), getId()) on various waypoints between the sourcecomponent and the target component. I think this is the key point for the discussion. There's no reason to expect findComponent to work with client id. Kind Regards, John Fallows. It's not obvious to me why you'd want to go from one to the other;they're basically totally different roles. It's also somewhat meaningless to have row identifers applyto scoped-id:what you get out the other end is a UIComponent,and that's it:how could the row identifier meaningfully applyto that return value? -- AdamOn 1/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: Yes, ok. but then, the scoped-id is something which should also work with row identifiers. And - there should be a way to lookup a scoped identifier from a client-id and the other way round. If both are unique - why take away the possibility of converting them into each other from the user? regards, Martin On 1/24/06, John Fallows [EMAIL PROTECTED] wrote: Folks, AFAIK, UIComponent.findComponent(String) receives a scoped id rather than a client id, since it just traverses the component hierarchy, rather than factoring in any current row for cases such as UIData. So, although the exact structure of client id is privately controlled by the Renderer as an implementation detail, the syntax of the scoped id passed to findComponent is well-defined.In certain cases, the a component's client id and scoped id may happen to have the same value, but that does not imply that client id is supposed to work with findComponent in all cases. Kind Regards, John Fallows. On 1/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi guys, I'm opening a can of worms here - I just discussed with John for quite some time, and now there is a new point that represents a problem to me. So a short question to the spec-gurus - how are findComponent and Renderer.convertClientId supposed to work together? findComponent makes assumptions on the structure of a passed clientId, convertClientId has no restrictions whatsoever (as for the spec) on what it is allowed to do with the client-id. Doesn't that represent a problem? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
FW: Common submit button not working in IE 5
Has anyone addressed this? From: Miller, John [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 1:07 PM To: MyFaces Discussion Subject: Common submit button not working in IE 5 The Common Submit button does not seem to work in the Faces examples for IE5. This can be seen by going to the tabbedPane.jsf page of the sample and clicking the Common Submit button and nothing happen. The Code seems to work fine in Firefox. I am also noticing this same behavior in my own app, and is causing major problems with my JSF migration. If anyone has seen this and/or has the workaround, that would be great. NOTICE: This message, including all attachments transmitted with it, is for the use of the addressee only. It may contain proprietary, confidential and/or legally privileged information belonging to Litle Co. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, you must not, directly or indirectly, use, disclose, distribute, print or copy any part of this message. If you believe you have received this message in error, please delete it and all copies of it from your system and notify the sender immediately by reply e-mail. Thank you.
Re: [maven] We need to make a decision
In reality, the code in the public myfaces-commons codebase is nowhere
close to being locked down in the same way as the various Apache
Commons public APIs.
For example, it contains code in many identical packages to
myfaces-tomahawk, that needs to be fixed before this API could be
considered public.
It also contains MyfacesConfig (MyFacesConfig would be a better name?)
that provides access to some set of configuration parameters. Why
is this in commons? Where is the code that reacts to these
configuration parameter values? Tomahawk?
The ResponseWriterAdapter is a good example of something that should be
included in this kind of commons API. In fact, there should be
adapters for all the classes supporting the decorator pattern as
well. These classes are part of the specification in JSF 1.2,
emphasizing their need.
The SimpleActionMethodBinding is another good example, although I'm not
crazy about the name, perhaps FixedOutcomeMethodBinding would be more
descriptive.
The renderkit package really does need to be removed, as it is not a
public API in any way - this is simply internal implementation details
that have been promoted into a shared location to support reuse across
Tomahawk and the Runtime. The main reason for doing this, is to
support some protected hooks that can leverage things like
UserRoleUtils.isEnabledOnUserRole(...) and
UserRoleUtils.isVisibleOnUserRole(...), when EL expressions such as
rendered=#{myFaces.userRoles.role} could have been used by the page
author instead of visibleOnUserRole=role to achieve the desired
effect without the need for special APIs that then force the
implementation internals into a shared public API.
Similarly, the taglib package needs to be removed from myfaces-commons
as well. In ADF Faces, we generate all our tag code during the
build, so there is no need to promote internal implementation details
into a shared public API.
This is a real issue that should be addressed *before* releasing the
myfaces-commons JAR. Could we have a serious discussion about
cleaning this up?
Btw, no one has yet commented on whether JavaEE 5 will solve this for
us for the case where the MyFaces JSF 1.2 Runtime is on the main JavaEE
Container ClassLoader, while MyFaces JSF 1.2 Tomahawk component library
is on the web app ClassLoader. Any thoughts?
Kind Regards,
John Fallows.On 1/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
2006/1/17, Sean Schofield [EMAIL PROTECTED]: Hmm..good point. If myfaces-commons is deployed at the container level, but a new version of tomahawk wants a later myfaces-commons that's a
problem. It's very bad style to require a container's libs to be upgraded in order to deploy a webapp, even if the new myfaces-commons jarfile is supposed to be binary-compatible with the old one.
Yes but its the best solution we've come up with so far.John had some ideas in a thread several weeks ago.I'm going to go back an re-read them to see if I can't understand his proposal better.
We need to get an update release out within the next few weeks and we're not likely to reach a better solution by then. My 2 cents,Here I agree with Sean.We should also keep in mind that the commons classes we are speaking
of really (should) have commons nature. That means: The same problemapply as it does for EVERY commons library. Many containers alreadyuse commons libraries for their own implementation. So, as a real life
example: Tomcat is shipped with a version of commons-el.jar. Now, whatif MyFaces needs a newer version for some reason? Should we as wellrepackage commons-el classes for our MyFaces implementation to solve
problems before they even arise? What about all the other commonslibs: commons-collections, commons-digester, commons-fileupload,commons-logging, commons-validator, ...And in the end we repackage (i.e. refactor) every third-party lib that
MyFaces Impl (or Tomahawk) is using?You might say: But all this commons stuff is stable and almost neverchanges! Yes, they have stable APIs, but No, they are bugfixed andenhanced all the time. This is the path that we should strike. Come to
a stable commons jsf API that remains compatible over the time. And ifwe fix bugs or enhance this lib: What's the problem with replacing thecontainer shipped version with a new version?No need to overreact in this issue, IMO.
Manfred-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] We need to make a decision
On 1/16/06, Sean Schofield [EMAIL PROTECTED] wrote: OK,We have been discussing a few important maven-related decisions thesepast few days.Its time to make a decision and move on.Here is myproposal.I'd like to see a couple of +1's and then we can get back to business.Everything is held up by this matter so lets bring it toa close.1.) Make the master pom an official artifact of myfaces.Its a littleweird to have a POM only artifact in the public maven repository but who cares?Its not a big deal. Everything is downloadedautomatically.This seems to make more sense then hiding it inapi/pom.xml (where it is now.)The master pom is needed my allmodules therefore its a dependency.It could sit in myfaces/pom.xml except each of the modules is releasable on its own schedule so IMOthere is no other logical alternative. I know it sounds weird at first, but having a POM dependency is not that strange in the land of Maven. :-) 2.) Directory names vs. artifiact names.Bernd has suggested apreference for the two matching but this is definitely not a requirement for maven.I propose core/trunk/api instead ofcore/trunk/myfaces-api.There is no *technical* reason for doing this*either way.*My personal preference is to keep the directory namesas short as possible.The final product will be call myfaces-api.jareither way. I agree with Bernd, my preference would be for these to match as well. When you svn checkout with TortoiseSVN, the local directory name defaults to the last part of the checkout path. So, if folks are checking out just api, then there's not enough context in the api name for their default local directory name. Similarly, if folks are checking out trunk, and leave the default name trunk for the local directory, then subdirectories of api, impl, etc do not provide sufficient context. I've seen this trunk checkout technique many times among my colleagues, especially as they were starting out with SVN. ADF Faces uses the following directory structure: trunk/ pom.xml adf-faces-api/ adf-faces-impl/ adf-faces-demo/ adf-faces-build/ Note: this last module, adf-faces-build contains metadata that is used at build time, so it's a little different from the build module in MyFaces. 3.) Establish a core module.So we have myfaces/core/trunk/api andmyfaces/core/trunk/impl.Bernd and I had started down this road and stopped at his request.I think the issues that concerned us then canbe addressed now.So can we agree to do this? What is the purpose of having such a core module? I would be concerned about releasing code in the same package for both the runtime and the component libraries, where each is versioned and released independently. Upgrading to a new version of a component library needs to guarantee zero impact on the runtime and having code in overlapping packages violates that principle when both are executed in the context of the same ClassLoader, as only one copy of the overlapping packages can take precedence. Does this problem get any better or worse in JavaEE 5, where the container is required to include a JSF 1.2 implementation? Would the ClassLoader of the JSF 1.2 implementation be sufficiently isolated from the ClassLoader of each Web Application to not be impacted by having two versions of the overlapping packages? Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] We need to make a decision
On 1/16/06, Simon Kitching [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 11:50 -0800, John Fallows wrote: Sorry, I meant what is the purpose of having a core module at all? (not, why is it structured in this way) In other words, who is going to use this module.Why does it need to exist? I'll try to clarify.I think what Sean's core is meant to be is simply an assemblyproject, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar get bundled into a myfaces.tar.gz or myfaces.zip file.I don't quite know why this can't be done in the myfaces-impl.jarproject but I guess there's some technical maven reason. I think this is a stylistic reason rather than a technical reason. This is *not* like the old share module which contained java classes that was then inserted into multiple jars; as you say that causes nastyissues when the jars are deployed via different classloaders. The commoncode now goes into myfaces-commons.jar, which must be deployed *once only* in the classpath.There is a slight gotcha with the myfaces-commons.jar approach.Imaging someone preparing a webapp using tomahawk that may be deployedon a container that bundles Sun RI, or may be deployed on a container that bundles myfaces-commons.jar and myfaces-api.jar. If they don'tbundle myfaces-commons.jar, then the app won't work on Sun RI. If theydo, then on the myfaces-based container they have duplicatedmyfaces-commons.jar , and therefore (if child-first classloading isselected) will get the ClassCastException problem. However it's not tooserious a problem and I can't see any better solution other than some ofthe early complicated proposals that included automated renaming of all the commons classes so they could be bundled with both impl andtomahawk without conflict. The problem has been repackaged, but the only difference between the old share module approach and this commons approach is that now you can choose which version of the overlapping code takes precedence. Btw, what makes you say that this type of ClassCastException problem is not too serious? When the application developer encounters this problem, what are his options? a) upgrade the container version of myfaces-commons.jar and hope it is compatible with the runtime (assuming he is allowed do this) b) remove myfaces-commons.jar from his webapp and hope the container version is compatible c) switch to using the Sun RI Anyway, my question was more along the lines of JSF 1.2, as I was wondering if the ClassLoaders could be arranged in the Application Server to avoid the two different versions of myfaces-commons.jar from colliding. I don't think that Web Applications (should?) have access to every class used by the implementation of the Application Server, right? Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: ADF Source drop is available!
On 1/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: You might give it out to Jack ;)Ha ha! My 6 month old son, Jack, would undoubtedly love to bash on the keyboard as we put together this proposal. :-)I've started to recover from the flu a bit now, so I'll be available to help out with this. Kind Regards,John Fallows.On 1/10/06, Adam Winer [EMAIL PROTECTED] wrote: Sure, I'll talk to John today and see how he wants to split this up. He's down with the flu at the moment, but I'm on vaction for a week starting this weekend, so it ought to be fun deciding who can do it. :) -- Adam On 1/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, we can all start writing up the proposal. Maybe you and John want to take a first shot? regards, Martin On 1/10/06, Adam Winer [EMAIL PROTECTED] wrote: Thanks Bill! -- Adam On 1/10/06, Bill Dudney [EMAIL PROTECTED] wrote: http://people.apache.org/~bdudney/apache-drop.zip is the url of interest the old url should not work any more. Thanks for pointing that out Ted. TTFN, -bd- On Jan 10, 2006, at 9:05 AM, Bill Dudney wrote:Sorry Ted, I did not think of the 'sanctioned' idea. I'll move it to my home dir now. TTFN, -bd- On Jan 10, 2006, at 8:57 AM, Ted Husted wrote: On 1/10/06, Bill Dudney [EMAIL PROTECTED] wrote: Since Ted seems to be busy I went ahead and uploaded the file to our space. http://myfaces.apache.org/adf/apache-drop.zip If we are going to do this, it would be better to do it from a home account on people.apache.org. (All of us have one.) Putting it under MyFaces makes it seem too much like sanctioned code, which it is not. I also seem to recollect that we are not suppose to distribute files from the website server, only pages. As for the code donation, I do not see that the ASF secretary has recorded it yet. But, that would not prevent a proposal being brought to the Incubator, only whether the code can be brought into an ASF repository. Unfortunately, my work schedule is not going to allow me to work on this project at all in the month January. -Ted. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces --http://www.irian.atYour JSF powerhouse - JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: ADF Source drop is available!
On 1/9/06, Adam Winer [EMAIL PROTECTED] wrote: On 1/7/06, Martin Marinschek [EMAIL PROTECTED] wrote: I have started looking at the sources, and my first look was on the accompanying java-script code. Now, I hope Martin Cooper hasn't had the time to look so far, cause he wouldn't have been to happy ;) Issues I've seen so far: - no namespacing for class-names - global variables (not even namespaced) - global, not namespaced functionsYeah, known - when this code was written (it pretty much allcomes from UIX) we were very naive JS developers.Oneof the items already on our todo list is moving all the functions, classes, and variables inside a single top level object.Yes, that's right, and we're also looking forward to working with the rest of the Apache MyFaces community to make these and other useful improvements. :-) Kind Regards,John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/5/06, Bill Dudney [EMAIL PROTECTED] wrote: Do we really end up with everything from the top level in the lib dir? What I'm thinking is something like this being in a 'user' project. dependency groupidorg.apache.myfaces/groupId artifactIdtomahawk/artifactId /depdency This will cause the transitive dependency thing to pull in everything that tomahawk depends on but won't touch the top level pom as I understand it anyway. Am I wrong about this?I don't know for sure, I'd have to experiment with it.I think thatif Tomahawk inherits dependencies, then they belong to Tomahawk no matter where they originally came from.If your webapp depends onTomahawk, you're going to get all of them. I hate to repeat the info though...Lesser of two evils? :)My first experiences with m2 were fending off unwanted transitive dependencies and submitting patches for poms inthe repository so my own webapps would contain the right things.I'd rather do the work up front, and make sure that the users getclean poms that express exactly the right dependencies for each module.And so far the only duplication I'm seeing is from thedependencies that are not transitive (the ones with test or providedscope.) There is a significant difference in behavior between making everything a dependency of the parent pom, versus pre-defining each dependency in the dependencyManagement section of the parent pom, and then referencing each relevant entry as a dependency (by groupId + artifactId) in the child pom. Here's the quote from the Maven Dependency Mechanism documentation. The dependency management section is a mechanism for centralizing dependency information. When you have a set of projects that inherits a common parent it's possible to put all information about the dependency in the common POM and have simpler references to the artifacts in the child POMs. -- http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html @Wendy: Were you seeing problems when defining your common dependencies in the parent pom in the dependencies section, or in the dependencyManagement section? Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: ADF Source drop is available!
On 1/9/06, Adam Winer [EMAIL PROTECTED] wrote: On 1/7/06, Sean Schofield [EMAIL PROTECTED] wrote: John and Adam, Thanks for all of your hard work getting this ready.I'm looking forward to studying it.I'm a little busy with the Maven migration now but I will get to it.Once we are fully migrated to maven I suspect this will make things easier for the ADF code to use myfaces snapshots, etc. As for the current unavailability of a JSF impl in Maven ... there are myfaces jars on ibiblio[1]. I believe struts-shale (using m1) makes use of this now.We didn't really set them up ourselves.We just copied the jars to certain locations on an ASF server and they end up propogating there.I was looking in the maven2 subdirectory - is maven2 smart enoughto search both maven2 and maven1 repositories? AFAIK, since the Maven1 ibiblio.org repository came first, the Maven2 ibiblio.org repository started out by syncing from the Maven1 repository, but into the new repository directory and filename layout for Maven2. Sometimes, JARs would be uploaded to the Maven2 repository and never exposed via the Maven1 repository. Lately, the Maven1 repository has been removed as a separately maintained entity, and instead there are URL rewrites going on to expose the Maven2 repository as though it were in the Maven1 layout. This URL rewriting eliminates the inconsistencies between the logical contents of the Maven1 and Maven2 central repositories on ibiblio.org. Separately from that, Maven2 can consume dependencies from any Maven1 repository, if that repository is defined in (pom.xml or settings.xml) to have legacy layout. Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 1/9/06, Sean Schofield [EMAIL PROTECTED] wrote:How would it distinguish what was an actual dependency vs. what dependency was used in 4 out of 6 subprojects?Assuming you're talking about dependencyManagement, things in thatsection don't have any effect until they are declared independencies by a module.At that point, you can take advantage of the inheritance and leave out the version number and (I think) scope. That's right. So it would be safe to put things like Servlet API, JUnit (or anything else that didn't get picked up automatically as a transitive dependency) into the parent POM's dependencyManagement section. The child projects would then reference these dependencyManagement entries by groupId and artifactId, omitting the version for sure, and also scope, although inheriting the scope seemed broken in the lead-up to Maven 2.0 final but I think it's fixed now. :-) Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Packaging, public vs. private (was: ADF source drop is available)
+1, non-binding. :-)On 1/9/06, Martin Marinschek [EMAIL PROTECTED] wrote: +1if someone does the work ;)regards,MartinOn 1/10/06, Simon Kitching [EMAIL PROTECTED] wrote: Adam Winer wrote: @Matthias, I'd rather not have any wrappers - the plan here is to repackage in line with MyFaces rules.I would, however, strongly like to keep the high-level concept of separating our public APIs - like component classes - from private internal implementation details - like renderers and tag classes.We do this now with an oracle.adf package for public stuff and oracle.adfinternal for private stuff, much like Sun puts public APIs in javax.* and private in com.sun.*. What would others think about repackaging org.apache.myfaces.custom to separate the renderers, tags, and components? org.apache.myfaces already does this for the ext stuff.Or, more generally, separating further the things that are used internally in MyFaces from things we expect developers outside of MyFaces to rely on? +1 on putting components and renderers/tags into separate packages in tomahawk, just like myfaces does for api/impl. I don't believe it's as important as for the spec stuff, but it still helps to make it clear what is a change that affects *users* of tomahawk components, vs changes that break only *customisers* of tomahawk components (a much smaller community). It's a moderate amount of work, but not huge. And it can be done incrementally... Cheers, Simon--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development and Courses in English and GermanProfessional Support for Apache MyFaces-- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Maven Build (Ongoing Work Thread)
On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote: By the way, if you use windows you should consider tortoise-cvs.Itis an awesome client!Its so good that I don't mind that its notintegrated with my IDE.You mean TortoiseSVN of course, which was inspired by TortoiseCVS. :-) http://tortoisesvn.sourceforge.net/http://tortoisesvn.tigris.org/ Kind Regards, John Fallows-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Maven Build (Ongoing Work Thread)
Devs,On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Changes to the TLD files don't seem to be being picked up at build
time; this was a problem in the Ant build as well but 'ant clean'
fixed it there, but 'mvn clean' doesn't here.My situation: I editied tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'. My changes didn't take, so I did a 'mvn
clean' then a 'mvn install'. Changes still aren't picked up.
I suspect it's the cached intermediate file at tomahawk\src\main\resources\META-INF\tomahawk.tld that's causing the problem. It isn't deleted by a clean.[INFO]
[INFO] Building Tomahawk[INFO] task-segment: [install][INFO] [INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date: C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
All generated files should live in the target subdirectory, including generated resources such as .tld files.
In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld, and the
plugin automatically adds target/[plugin-name]src/main/resources to the
resource root set (similar to java source path for javac).
When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources
tree view. When either the xxx-base.tld file or other relevant
metadata is changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld, without
needing to do a clean build.
Since src/main/resources and target/[plugin-name]/src/main/resources
are both registered as resource roots, but src/main/conf is not, then
the xxx-base.tld is not included in the JAR, but xxx.tld is included,
as desired.
Kind Regards,
John Fallows.
-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
[jira] Updated: (MYFACES-829) h:selectManyCheckbox with value bound to an array of int fails
[ http://issues.apache.org/jira/browse/MYFACES-829?page=all ]
John R. Fallows updated MYFACES-829:
Attachment: myfaces-829-post-reorg.patch
Reworked the patch for post-reorg maven2 build.
Introduced a xx_TEST locale to serve up javax.faces.Messages bundle messages
during unit testing.
h:selectManyCheckbox with value bound to an array of int fails
Key: MYFACES-829
URL: http://issues.apache.org/jira/browse/MYFACES-829
Project: MyFaces
Type: Bug
Components: JSR-127
Versions: 1.1.0
Environment: Linux, JDK 1.5.0_05
Reporter: Craig McClanahan
Assignee: sean schofield
Priority: Critical
Fix For: 1.1.2
Attachments: myfaces-829-post-reorg.patch, myfaces-829.patch
The Shale use cases example includes a page where an h:selectManyCheckbox
component is bound to an array of int that represents selected values. A bug
was reported against this app:
http://issues/apache.org/bugzilla/show_bug.cgi?id=37361
However, further investigation shows that this case works correctly with the
JSF RI, leading to the belief that it represents an implementation error in
MyFaces. See the above bug report for more details.
For reference, the page includes the following component:
h:selectManyCheckbox id=categories layout=pageDirection
value=#{dialog.data.categories}
h:selectItems value=#{domains.supportedCategories}/
/h:selectManyCheckbox
where the binding expressions point at values of the following types:
* #{dialog.data.categories} points at an array of int representing
the currently selected categories
* #{domains.supportedCategories} points at an array of SelectItem,
where the value property of each is an Integer representing the
primary key for that category.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Maven Build (Ongoing Work Thread)
Hey Martin,
On 1/2/06, Martin Marinschek
[EMAIL PROTECTED] wrote:The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.The tld's cannot be created, as the target/classes/META-INF directorydoesn't exist.Solution anyone?
The plugin that creates the tlds should also ensure that the output
directory exists. This is good practice for Maven2 plugins in
general.
In addition, that plugin should be running during the
generate-resources phase, the output directory should be
target/[plugin-name]/src/main/resources (or similar), and the output
directory should be added as a dynamic resource root on the
MavenProject object.
Kind Regards,
John Fallows.
On 1/2/06, John Fallows
[EMAIL PROTECTED] wrote: Devs, On 1/1/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote: Changes to the TLD files don't seem to be being picked up at build time;
this was a problem in the Ant build as well but 'ant clean' fixed it there, but 'mvn clean' doesn't here. My situation:I editied tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'.My changes didn't take, so I did a 'mvn clean' then a 'mvn install'.Changes still aren't picked up. I suspect it's the cached intermediate file at tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem.It isn't deleted by a clean. [INFO] [INFO] Building Tomahawk [INFO]task-segment: [install]
[INFO] [INFO] [xslt:transform {execution: default}] [INFO] # of XML files: 1 [INFO] file up-to-date:
C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld All generated files should live in the target subdirectory, including
generated resources such as .tld files.In ADF Faces we merge together a base .tld from src/main/conf/META-INF/xxx-base.tld with other metadata to generate target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
and the plugin automatically adds target/[plugin-name]src/main/resources to the resource root set (similar to java source path for javac).When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources tree view.When either the xxx-base.tld file or other relevant metadata is changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld, without needing to do a clean build.Since src/main/resources and target/[plugin-name]/src/main/resources are both registered
as resource roots, but src/main/conf is not, then the xxx-base.tld is not included in the JAR, but xxx.tld is included, as desired.Kind Regards,John Fallows. --
Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
--
http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces--
Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
[jira] Updated: (MYFACES-829) h:selectManyCheckbox with value bound to an array of int fails
[ http://issues.apache.org/jira/browse/MYFACES-829?page=all ]
John R. Fallows updated MYFACES-829:
Attachment: myfaces-829.patch
Ensure that a value of type primitive array is validated correctly against the
select items.
UISelectManyTest verifies the correctness of the logic in
UISelectMany.validateValue, such as enforcing required, type support for
iterating over selected item values, and making sure that the selected values
are all in the set of available select item values. When executed against the
original code for UISelectMany, this test case passed all tests except
primitive int arrays. Now all the tests pass.
This patch was created against
https://svn.apache.org/repos/asf/myfaces/current, revision 359829.
h:selectManyCheckbox with value bound to an array of int fails
Key: MYFACES-829
URL: http://issues.apache.org/jira/browse/MYFACES-829
Project: MyFaces
Type: Bug
Components: JSR-127
Versions: 1.1.0
Environment: Linux, JDK 1.5.0_05
Reporter: Craig McClanahan
Assignee: sean schofield
Priority: Critical
Fix For: 1.1.2
Attachments: myfaces-829.patch
The Shale use cases example includes a page where an h:selectManyCheckbox
component is bound to an array of int that represents selected values. A bug
was reported against this app:
http://issues/apache.org/bugzilla/show_bug.cgi?id=37361
However, further investigation shows that this case works correctly with the
JSF RI, leading to the belief that it represents an implementation error in
MyFaces. See the above bug report for more details.
For reference, the page includes the following component:
h:selectManyCheckbox id=categories layout=pageDirection
value=#{dialog.data.categories}
h:selectItems value=#{domains.supportedCategories}/
/h:selectManyCheckbox
where the binding expressions point at values of the following types:
* #{dialog.data.categories} points at an array of int representing
the currently selected categories
* #{domains.supportedCategories} points at an array of SelectItem,
where the value property of each is an Integer representing the
primary key for that category.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
MYFACES-829 patch ready for review
MyFaces Devs, I've attached a patch to solve MYFACES-829. http://issues.apache.org/jira/browse/MYFACES-829 Could someone with the right permissions do a review and potentially a merge? Kind Regards, John Fallows-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: MYFACES-829 patch ready for review
On 12/31/05, Sean Schofield [EMAIL PROTECTED] wrote: John,I'm working on the SVN reorg at the moment.I will try to apply yourpatch shortly.Better yet, if you are willing, could you help to testthe reorg and provide a revised patch?(The source code layout is changing ever so slightly ...)I will let you know when the reorg is done .. should be within an hour or two. No problem - will wait for your reorg email and then revise the patch against the latest trunk. Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: SVN Reorg Underway
The api/pom.xml needs to set the parent project version to 1.1.2-SNAPSHOT. Could someone with the right permissions please make the change. Kind Regards, John Fallows.On 12/31/05, Sean Schofield [EMAIL PROTECTED] wrote: SVN Reorg is completed.There is a wiki[1] (see SVN Reorg section)documenting what was moved.Everything has been moved to a Mavenfriendly setup.The nightly builds (including website) will not workfor now but we can live with this for a week or so. I have just begun testing the build so there may be issues.We mayalso need to move a few more things around as we fine tune the script. For now it should be safe to commit, make patches, etc.Sean [1] http://wiki.apache.org/myfaces/Maven2_MigrationOn 12/31/05, Sean Schofield [EMAIL PROTECTED] wrote: Please do not commit anything for a few hours.I am in the process of moving the SVN stuff around to accomodate the new Maven build. Regards, Sean -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: SVN Reorg Underway
None of the unit tests are running. api/src/test/javax should be moved to api/src/test/java/javax A similar change is needed for each of the other modules as well. Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Moving forward on the Oracle donation
Btw, after the code becomes publicly available, I'm convinced that it needs to spend some time in the Apache Incubator rather than trying to fast track it out of there too aggressively.Obviously we'll need to refactor the ADF Faces codebase to meet Apache MyFaces packaging requirements, but more importantly, there'll be an opportunity to gain insights from the wider MyFaces community to better prepare our exit from the Incubator. No one wants ADF Faces to get stuck in the Incubator, but when it does exit, we will all benefit from having the whole MyFaces community behind it.Kind Regards,John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Unit tests broken during ant build?
Sounds good, Sean. That's what I'll do then.tc,-john.-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Fixing issues as a non-committer
MyFaces Devs, I am working on http://issues.apache.org/jira/browse/MYFACES-829 for JSR-127 compliance. What is the best way to indicate that this fix is in progress on JIRA (as a non-committer)? After the fix is completed, I plan to attach the patch file to the issue. Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Maven(2) work
Folks, I'd like to volunteer to help out with the Maven(2) build work for MyFaces as we recently migrated the ADF Faces to use Maven2. Kind Regards, John Fallows-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Fixing issues as a non-committer
Yes Matthias, I'd be interested to know the general strategy for this too. Kind Regards, John Fallows.On 12/29/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: I assigned it to myself and marked it in progress.I'm looking forward to the fix for this one!maybe this issue is already taken, but is it possible to asign bugs to yourself,even, when you are not a committer? (have no idea on howto configure Jira.)-Matthias sean On 12/29/05, John Fallows [EMAIL PROTECTED] wrote: MyFaces Devs, I am working on http://issues.apache.org/jira/browse/MYFACES-829 for JSR-127 compliance. What is the best way to indicate that this fix is in progress on JIRA (as a non-committer)? After the fix is completed, I plan to attach the patch file to the issue. Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044--Matthias WessendorfZülpicher Wall 12, 23950674 Kölnhttp://www.wessendorf.netmwessendorf-at-gmail-dot-com -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Unit tests broken during ant build?
Devs,
There seems to be a problem with running the unit tests via ant
unit-test-all (top level build) or ant unit-test) (api build).
Don't worry about the UISelectManyTest breakage, that is expected and
will be used to verify the bugfix once completed.
unit-test:
[junit] Running javax.faces.FacesExceptionTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.093 sec
[junit] Running javax.faces.FactoryFinderTest
[junit] Tests run: 9, Failures: 0, Errors: 7, Time elapsed: 0.078 sec
[junit] Test javax.faces.FactoryFinderTest FAILED
[junit] Running javax.faces.application.FacesMessageTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
[junit] Running javax.faces.application.StateManagerTest
[junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.453 sec
[junit] Test javax.faces.application.StateManagerTest FAILED
[junit] Running javax.faces.component.UIComponentBaseTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Test javax.faces.component.UIComponentBaseTest FAILED
[junit] Running javax.faces.component.UISelectManyTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.078 sec
[junit] Test javax.faces.component.UISelectManyTest FAILED
[junit] Running javax.faces.component._AttachedListStateWrapperTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.093 sec
[junit] Running javax.faces.component._AttachedStateWrapperTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.063 sec
[junitreport] Transform time: 843ms
Looks like UIComponentMock.java, MockStateManager.java and
MockApplicationFactory.java are not being compiled during the test
build, possibly due to the following in build/build.xml at the top
level.
target name=unit-test depends=compile if=test.src.dir
description=build and run subproject unit tests
...
javac srcdir=${test.src.dir}
destdir=${test.classes.dir}
optimize=${javac.optimize}
debug=${javac.debug}
classpathref=test.classpath
include name=${test.suffix}/
exclude name=${cactus.suffix}/
/javac
...
/target
Looks like files with ${test.suffix} pattern will be included for
test compilation. However, I couldn't find the definition of this
ant variable, can anyone point me in the right direction?
Thanks in advance.
Kind Regards,
John Fallows.
-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Fixing issues as a non-committer
+1. This sounds like a very good plan, Sean. Kind Regards, John Fallows On 12/29/05, Sean Schofield [EMAIL PROTECTED] wrote: It may be a while though since its not yet been released.Then thereis the issues of convincing infra to upgrade.Certainly this featuremakes a very compelling case to upgrade though!seanOn 12/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote: Great! I'm definitely +1 for treating resolved (fixed in nightly) and closed (fixed in public release) differently, and I'm glad to hear it'll soon be possible. On 12/29/05, Sean Schofield [EMAIL PROTECTED] wrote: Right.I'm hoping that eventually we can change that policy once the following two issues are resolved: 1.) JIRA fixes an outstanding bug/limitation where you cannot bulk close issues.Once that is done we could just change all resolved to closed in one step.Apparently this very popular JIRA features (198 votes!) has been fixed in the upcoming release.[1] 2.) We change the notification rule so that closed issues do not result in emails (just resolved.) sean [1] http://jira.atlassian.com/browse/JRA-2427 On 12/29/05, Mike Kienenberger [EMAIL PROTECTED] wrote: On 12/29/05, Sean Schofield [EMAIL PROTECTED] wrote:Another example of a change I would like to see is that all users canreopen a bug that is not yet closed.We have a lot of people whoreport that a fix did not work, etc. and it would be nice to just reopen with comments. Unfortunately, that won't help since our current policy is to mark a bug as closed whenever it's resolved. -- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: Proposal: Switch to Maven(2)
+1I'm definitely up for helping out with this.Kind Regards,John Fallows.On 12/29/05, Bruno Aranda [EMAIL PROTECTED] wrote:+1 As I've told in previous e-mails, everything seems to be working ok in the maven build. It only remains to be migrated the currentdocumentation and the tests. There is some basic information in thesite being generated with maven and I've started to move somedocumentation and to play with it. I am happy with the maven build now.Regards,Bruno2005/12/29, Sean Schofield [EMAIL PROTECTED]: I am proposing we switch to Maven2.I think we now have enough people who are ready willing and able to sustain the Maven effort.In the interest of time I will not go into why I think Maven is better then Ant (I'm probably not the best person for that anyways.) Here are the details of my proposal: 1.) Minor changes to the svn structure to become more Maven friendly. These are minor changes to the directory layout and the result will be something similar to what we have in the test repository.[1] Changes will be made to the trunk only.We will also backup the current structure (like we did before the last reorg) so nothing will be lost and we can go back to the old if things don't work. 2.) Abandon (but do not remove) the current Ant scripts.I don't think they're worth changing.It will be much simpler to focus on the maven script and just push through the pain. 3.) Temporarily abandon the nightly builds.Make an announcement on the user list that nightly builds will be unavailable for the next week or two while we get the new infrastructure setup.The nightly builds rely on the Ant scripts. 4.) New Mavenized website.Slowly migrate to a Maven generated website.At first only the essential pieces will be there (basic overview, mailing list and jira info, etc.)Once the site is being automated and published it will be easy to add pieces back each day. 5.) Move to a solaris zone for building the nightlies and publishing the website. I think the best way to proceed with this is to jump right in and push through.Bruno has offered to help and the Tobago team has already provided some assistance.Wendy and James from the Struts team have offered to help when possible and now John Fallows is offering his assistance. I will go ahead with the reorg in the next few days if I get enough +1.Keep in mind that the existing maven script already builds the jar files so developers will continue to have access to the latest and greatest.Also keep in mind that I have done one SVN reorg for MyFaces already and that with SVN its easy to roll back if we aren't happy with the results. Thoughts? Sean [1] http://svn.apache.org/repos/test/myfaces/-- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Moving forward on the Oracle donation
On 12/29/05, Ted Husted [EMAIL PROTECTED] wrote: Right now, I don't know how any of the ADF developers feel. To moveforward, we need to hear from the individual developers, who mightbecome committers some day. If this is going to be a situation whereone of the ADF developers can speak for the others, then we need to stop this right now. We need each and every ADF developer to speak forhimself or herself. And we need to them to speak on the list, and nowhere else.That's my cue, I guess. :-) I'm highly motivated to see the ADF Faces code successfully donated to Apache and bring significant benefits to both the Apache MyFaces project specifically, and the wider JavaServer Faces community more generally. We really need to strengthen JSF to deliver more practically useful web applications. Once the ADF Faces source code becomes publicly available, we'll be able to discuss the design merits more effectively, and decide with an open mind how best to evolve the whole MyFaces / ADF Faces codebase over time. I'm very much looking forward to those discussions, and expect to participate extensively. I've started working on patches to MyFaces that are unrelated to the ADF Faces donation in an effort to increase karma the old-fashioned way.Working on this stuff in the community is going to be really fun. :-) Kind Regards, John Fallows.-- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Unit tests broken during ant build?
Just a quick follow-up - not only could I not find a definition of
${test.suffix} but removing the include name=${test.suffix}
line seemed to fix the problem.
I'll include this removal in my next patch unless someone has a better idea.
tc,
-john.On 12/29/05, John Fallows [EMAIL PROTECTED] wrote:
Devs,
There seems to be a problem with running the unit tests via ant
unit-test-all (top level build) or ant unit-
test) (api build).
Don't worry about the UISelectManyTest breakage, that is expected and
will be used to verify the bugfix once completed.
unit-test:
[junit] Running javax.faces.FacesExceptionTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.093 sec
[junit] Running javax.faces.FactoryFinderTest
[junit] Tests run: 9, Failures: 0, Errors: 7, Time elapsed: 0.078 sec
[junit] Test javax.faces.FactoryFinderTest FAILED
[junit] Running javax.faces.application.FacesMessageTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
[junit] Running javax.faces.application.StateManagerTest
[junit] Tests run: 5, Failures: 0, Errors: 5, Time elapsed: 0.453 sec
[junit] Test javax.faces.application.StateManagerTest FAILED
[junit] Running javax.faces.component.UIComponentBaseTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Test javax.faces.component.UIComponentBaseTest FAILED
[junit] Running javax.faces.component.UISelectManyTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.078 sec
[junit] Test javax.faces.component.UISelectManyTest FAILED
[junit] Running javax.faces.component._AttachedListStateWrapperTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.093 sec
[junit] Running javax.faces.component._AttachedStateWrapperTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.063 sec
[junitreport] Transform time: 843ms
Looks like UIComponentMock.java, MockStateManager.java and
MockApplicationFactory.java are not being compiled during the test
build, possibly due to the following in build/build.xml at the top
level.
target name=unit-test depends=compile if=test.src.dir
description=build and run subproject unit tests
...
javac srcdir=${test.src.dir}
destdir=${test.classes.dir}
optimize=${javac.optimize}
debug=${javac.debug}
classpathref=test.classpath
include name=${test.suffix}/
exclude name=${cactus.suffix}/
/javac
...
/target
Looks like files with ${test.suffix} pattern will be included for
test compilation. However, I couldn't find the definition of this
ant variable, can anyone point me in the right direction?
Thanks in advance.
Kind Regards,
John Fallows.
-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044
Re: [ANNOUNCEMENT] JavaPolis
Great idea Martin! Definitely count me in for a few beers. :-) tc, -john. On 11/25/05, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *,all of you who go to the JavaPolis this year: I'd like to invite youto come to the session in Room 1, 9:30-12:30, 12th December 2005:J2EE Web Apache MyFaces, by Martin Marinschek, John Fallows and Jonas Jacobi and to the BOF in the evening at 21:30-22:30:JSF and Apache MyFaces - User Feedbackif you guys want, we might head out for a beer afterwards. Anyone interested?regards,Martin
[jira] Created: (MYFACES-845) quote in html link causes javascript error
quote in html link causes javascript error -- Key: MYFACES-845 URL: http://issues.apache.org/jira/browse/MYFACES-845 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Reporter: John Tinetti a single quote in the value argument to org.apache.myfaces.renderkit.html.HtmlLinkRendererBase.renderLinkParameter gets written directly to the output stream. It should be escaped with a backslash. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-845) quote in html link causes javascript error
[ http://issues.apache.org/jira/browse/MYFACES-845?page=all ] John Tinetti updated MYFACES-845: - Attachment: HtmlLinkRendererBase.patch patch quote in html link causes javascript error -- Key: MYFACES-845 URL: http://issues.apache.org/jira/browse/MYFACES-845 Project: MyFaces Type: Bug Components: Implementation Versions: Nightly Reporter: John Tinetti Attachments: HtmlLinkRendererBase.patch a single quote in the value argument to org.apache.myfaces.renderkit.html.HtmlLinkRendererBase.renderLinkParameter gets written directly to the output stream. It should be escaped with a backslash. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Issues with duplicate IDs - maybe a MyFaces problem but not sure
Yep. Same problem. Does the code work for anyone else? It's an ArrayList of
Message objects that I'm using.
java.lang.IllegalStateException: Client-id : _id6 is duplicated in the faces
tree.
Thanks,
John
Bruno Aranda wrote:
And does it work if you remove the id attribute from your graphicImage
component in the facet? (id=theproblem)
Regards,
Bruno
2005/11/2, John Sherwood [EMAIL PROTECTED]:
I've been having a heap of trouble getting the DataScroller object
working. It simply refuses to allow me to have facets. It works
perfectly fine in the examples but not in my page so perhaps it's a
config problem. I'd really appreciate it if anyone can help me out. This
thing has been bothering me for days.
I'm new to JSF so any other hints about how I should write it would be
nice for future reference. You know, things like you should make sure
these tags are before these ones and that.
The code that causes the error (messages.jsp):
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
f:view
HTML
HEADTITLESome thing/TITLE
BODY
CENTER
h:panelGroup id=group
h:panelGrid columns=1 id=grid
t:dataTable id=messagedata
var=message
value=#{listMessage.messages}
rows=10
t:column
f:facet name=header
h:outputText value=Time Transferred /
/f:facet
h:outputText value=#{message.timeTransferred} /
/t:column
t:column
f:facet name=header
h:outputText value=Purpose /
/f:facet
h:outputText value=#{message.actionPerformed} /
/t:column
/t:dataTable
t:dataScroller id=scrollnice
for=messagedata
fastStep=10
pageCountVar=pageCount
pageIndexVar=pageIndex
paginator=true
paginatorMaxPages=9
paginatorActiveColumnStyle=font-weight:bold;
f:facet name=first
t:graphicImage id=theproblem url=images/arrow-first.gif
border=1 /
/f:facet
/t:dataScroller
/h:panelGrid
/h:panelGroup
/CENTER
/BODY
/HTML
/f:view
and the error page:
*exception*
javax.servlet.ServletException: Client-id : theproblem is duplicated in the
faces tree.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:109)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:112)
*root cause*
java.lang.IllegalStateException: Client-id : theproblem is duplicated in the
faces tree.
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:241)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:204)
org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122)
org.apache.jsp.messages_jsp._jspx_meth_f_view_0(org.apache.jsp.messages_jsp:132)
org.apache.jsp.messages_jsp._jspService(org.apache.jsp.messages_jsp:81)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:112)
Thanks in advance for any help.
Re: myfaces-share (was RC3...)
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote: Yes, this is another option.make myfaces-share something like a common-jsf-utils or so.Thing is that changes should not happen very often in there, then. Andincompatible changes never. Right. This requires that the shared code be promoted to a public API, which reduces it's ability to change/refactor over time. That's a big decision. In general, it is usually best to keep the public API as small as reasonably possible, so that the least number of constraints are placed on the implementation. Perhaps we can implement the common code once (to avoid maintenance headaches), but not actually share it in the same package across project implementations (to avoid unnecessary package overlap). It should be possible to automate this process as part of the build. This would allow the trunk to have a single source of truth, while deployed implementation versions could still vary independently as they would for any combination of standard runtime / extension to the standard. I think it would also be useful to do a thorough review of the actual integration points between the shared codebase and the two different implementations, with a goal of reducing the amount of shared code, especially the RendererBase classes and their supporting classes. I can look into this and report back to the group. If anyone else wants to help, please let me know. Suppose we don't solve this problem. Out of all the component libraries available for JavaServer Faces, do we really want to have to explain to end users why the MyFaces Tomahawk project doesn't always work so well with the MyFaces Runtime? Kind Regards, John Fallows. On 11/2/05, Bill Dudney [EMAIL PROTECTED] wrote: Hi John, On Nov 1, 2005, at 10:25 PM, John Fallows wrote: If you want to use a version of tomahawk that is incompatible with your MyFaces implementation on the web server, just upgrade the MyFaces version.Yes its a pain but it certainly doesn't seem to be insurmountable. This just proves that we depend on something other than the APIs in the specification to integrate the two projects together.That indicates that we haven't ensured proper isolation between the projects. Am I misssing something here?Is the problem more significant then upgrading your MyFaces implementation? I think you might be missing the point of having a standard. :-) The implementation of the standard runtime stands alone.The implementation of any extensions to the standard also stand alone. The current shared code approach breaks the guarantee that any combination of standard runtime implementation and standard extension implementation can work together. The fact that a certain combination of these implementations are provided by a common set of developers should be entirely irrelevant to the end user. I think you might be missing something here. The standard does not provide sufficient definition of how the components will be implemented (and perhaps that is a good thing). There is a ton of common code between all components that is not defined in the standard. We can choose to re-implement that functionality in tomahawk, copy and repackage or put it in a separate jar. Perhaps it would be better to have more detail in the API for the component classes and perhaps it would not be, either way the 1.1 and 1.2 versions of the spec don't have the detail needed to reuse complex code across components. With the current spec its better IMO to implement everything once and share it. I think the bottom line is that myfaces-share.jar is something like commons-logging.jar. No one decries the fact that we depend on logging (well perhaps 'no one' is a strong statement :-) so why should we be put out by dependence on myfaces-share.jar. It could just as easily be called html-utils.jar or jsf-component-building- made-easy.jar or whatever. As far as separation of the projects goes. myfaces-impl.jar and tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should not depend on myfaces-impl.jar of course but could depend on myfaces- api.jar. The last time I checked the dependency tree was as described here so I think we are in good shape to make things look like this. Anyway my $0.02 on this. TTFN, -bd--- http://www.irian.atYour JSF powerhouse -JSF Trainings in English and German
Issues with duplicate IDs - maybe a MyFaces problem but not sure
I've been having a heap of trouble getting the DataScroller object
working. It simply refuses to allow me to have facets. It works
perfectly fine in the examples but not in my page so perhaps it's a
config problem. I'd really appreciate it if anyone can help me out. This
thing has been bothering me for days.
I'm new to JSF so any other hints about how I should write it would be
nice for future reference. You know, things like you should make sure
these tags are before these ones and that.
The code that causes the error (messages.jsp):
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
f:view
HTML
HEADTITLESome thing/TITLE
BODY
CENTER
h:panelGroup id=group
h:panelGrid columns=1 id=grid
t:dataTable id=messagedata
var=message
value=#{listMessage.messages}
rows=10
t:column
f:facet name=header
h:outputText value=Time Transferred /
/f:facet
h:outputText value=#{message.timeTransferred} /
/t:column
t:column
f:facet name=header
h:outputText value=Purpose /
/f:facet
h:outputText value=#{message.actionPerformed} /
/t:column
/t:dataTable
t:dataScroller id=scrollnice
for=messagedata
fastStep=10
pageCountVar=pageCount
pageIndexVar=pageIndex
paginator=true
paginatorMaxPages=9
paginatorActiveColumnStyle=font-weight:bold;
f:facet name=first
t:graphicImage id=theproblem url=images/arrow-first.gif
border=1 /
/f:facet
/t:dataScroller
/h:panelGrid
/h:panelGroup
/CENTER
/BODY
/HTML
/f:view
and the error page:
*exception*
javax.servlet.ServletException: Client-id : theproblem is duplicated in the
faces tree.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:109)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:112)
*root cause*
java.lang.IllegalStateException: Client-id : theproblem is duplicated in the
faces tree.
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:241)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255)
org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:204)
org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122)
org.apache.jsp.messages_jsp._jspx_meth_f_view_0(org.apache.jsp.messages_jsp:132)
org.apache.jsp.messages_jsp._jspService(org.apache.jsp.messages_jsp:81)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:112)
Thanks in advance for any help.
Re: RC3: dependency on commons-lang
On 10/25/05, Sean Schofield [EMAIL PROTECTED] wrote: I don't think we will enjoy keeping some 100+ classes in sync acrosstwo different packages.Nor will I think that users who try to supplya patch who enjoy this.We couldn't use svn externals either b/c thefiles need to have different package statements. That's why this code would need to either be repackaged automatically, or eliminated from the current design altogether. The whole point of the shared code is to cut down on this type ofheadache.The RI has the luxury of just providing an implementation. They do not provide components so they don't have to share code.AsManfred put it, this code is shared between projects for a reason. Agreed. However, the reason is out of date because the projects are now separated (as they should be). I agree the current situation is not ideal and I'm open to your ideaand anyone elses but so far this solution seems even worse. I agree that your description of the proposed approach is worse, but I don't think anyone was suggesting what you described. :-) If you want to use a version of tomahawk that is incompatible withyour MyFaces implementation on the web server, just upgrade the MyFaces version.Yes its a pain but it certainly doesn't seem to beinsurmountable. This just proves that we depend on something other than the APIs in the specification to integrate the two projects together. That indicates that we haven't ensured proper isolation between the projects. Am I misssing something here?Is the problem more significant thenupgrading your MyFaces implementation? I think you might be missing the point of having a standard. :-) The implementation of the standard runtime stands alone. The implementation of any extensions to the standard also stand alone. The current shared code approach breaks the guarantee that any combination of standard runtime implementation and standard extension implementation can work together. The fact that a certain combination of these implementations are provided by a common set of developers should be entirely irrelevant to the end user. Kind Regards, John Fallows. On 10/24/05, John Fallows [EMAIL PROTECTED] wrote: Hey Sean, On 10/24/05, Sean Schofield [EMAIL PROTECTED] wrote: I agree the shared classes is the most important issue to focus on.I also agree -1 on repackaging them.We would live to regret that decision. Your current position is clear, but not your rationale.Can you please elabotate so that we can better understand the perceived downside of using this approach? Kind Regards, John Fallows.
Re: RC3: dependency on commons-lang
Hey Sean, On 10/24/05, Sean Schofield [EMAIL PROTECTED] wrote: I agree the shared classes is the most important issue to focus on. I also agree -1 on repackaging them. We would live to regret that decision. Your current position is clear, but not your rationale. Can you please elabotate so that we can better understand the perceived downside of using this approach? Kind Regards, John Fallows.
Re: RC3: dependency on commons-lang
On 10/22/05, Martin Marinschek [EMAIL PROTECTED] wrote: It is a realistic scenario if you think about JBoss including MyFaces (the implementation) 1.1.0 as a standard somewhere in the server - and you want to upgrade to 1.1.1 in your webapp for the newest and best in the tomahawk components. IMHO, I believe this general scenario to be both realistic and extremely important to the success of the MyFaces project. MyFaces Runtime consumers expect a stable implementation of the JSF specification that competes on performance with other implementations of the specification. It is expected that this part would stabilize fairly quickly for each version of the JSF specification. MyFaces Tomahawk consumers expect innovation via new features and components, that can be plugged into any faithful implementation of the JSF specification. It is expected that this part would continue to evolve over a much longer timeframe than the MyFaces Runtime. Since MyFaces Runtime is a producer of the the standard and MyFaces Tomahawk is a consumer of the standard, these two deliverables should be released and versioned independently, using only the JSF specification as an interface to communicate between them. This will reduce the coupling between the two subprojects which is a good design principle. Any approach involving a restriction on special versions that are required to work together (beyond JSF specification compliance) is likely to reduce confidence in both MyFaces Runtime and MyFaces Tomahawk, and could easily lead to a customer preference to run MyFaces Tomahawk on the RI instead, where no such version restriction exists. However, the solution is simple. Eliminate all shared code between implementation and components, and release each subproject with independent versioning. Kind Regards, John Fallows.
Re: RC3: dependency on commons-lang
On 10/22/05, ir. ing. Jan Dockx [EMAIL PROTECTED] wrote: Here are some humble suggestions from our experience: 1) Split the release schedules for the different parts myfaces-api, myfaces-impl, and indeed, myfaces-shared, and tomahawk, need to be on different release tracks, and have different version numbers. You are now in a situation that one release is waiting for the other, almost in deadlock. This poses no difficulties for developers. This makes it easier for developers. This also makes it easy to make different contributors responsible for the releases and other issues of the different parts, distributing the work and responsibility. +1 2) Drop the combined package This again makes releases harder, and there is no need for that. Tomahawk is a separate product anyway: it also works (or should work in the near future) with other JSF implementations. Developers will appreciate the clarity. +1 (customers will also appreciate this) 3) Automate the release procedure; use maven Yes, I know this was discussed 3 months ago. But it is clear that the release procedure is manual now, that there are problems automating it. With maven, most of the work is done already, and you will be able to spend the time you spend now on duplicating maven functionality in ant, to automate the missing parts, like running the JSF compatibility tests. +1 (use Maven2) 4) Don't be afraid of a new release. E.g., take 1.1.0. This release is obviously broken, and there are over 80 fixes in the repo since then already. But, no release. _Each_ of those 80 fixes warranted a new release. _Each_ of those releases would have helped a number of people that were fighting a bug in 1.1.0. If this means that there is a new release every day, in the extreme, that's ok. If the release procedure is automatic, that doesn't take any effort, and it is feasible for developers to track progress (is my bug fixed in this release or not). Now, everybody in development is working with nightlies, which introduces terrible uncertainty which is almost impossible to defend to project managers or clients. And it doesn't stay that way. In the first days after 1.1.0, it would have meant a daily bugfix release, yes. After a week, it would go down to a release every 3 days, and by now, we would probably have 1.1.21. That's ok. Developers _can_ count past 10. If this goes to far for you, for bugfix releases (kudos for the separate 1.1 branch), reverse the issue: in the first weeks, set a release schedule: a new release every friday 00:00h. The fixes that are in the branch make the release, the rest is for next week. If there are blocking issues at that time, branch the branch, and fix them asap. Again, this stabilizes after a while, when there simply are no new commits in the branch since last friday. I promise it does! Developers see the trend in the release schedule. After a while, the curve flattens, and we all know that we reached a certain stability. We don't want to use a .0 version in deployment; we know there are bugs in .0 versions of _every_ product. If we have a feeling about the release schedule, we will use earlier versions, if our deadline is far enough in the future, so you will have testers. +1 If trains leave often enough, missing the train is not a big deal. Trains will also arrive more frequently. :-) 5) Forget the RC-approach. For one, given the experience of the last few weeks, this approach obviously isn't working. Just depend on the stabilising nature of frequent, consecutive bugfix releases. You will have more testers this way than with the RC's which are impossible to find (e.g., no maven repo release). I know of nobody in production that will go through the effort of working with an RC. +0.5 :-) RC makes sense for dot-zero release, like 1.0, 2.0 and maybe for a dot-N release like 1.1, 2.1, etc, but not for bugfix releases. Subsequent bugfix releases definitely do not require an RC, but they do require thorough (automated) testing. Kind Regards, John Fallows.
Re: RC3: dependency on commons-lang
Hi Everyone, On 10/19/05, Martin Marinschek [EMAIL PROTECTED] wrote: Well, if we could do b) somewhat automatically, this would be great. John Fallows had proposed something like this for the shared classes of Apache MyFaces - to make sure that Tomahawk and the impl always use the correct implementation of the shared classes. John - I think this is the time at which you could convince us of your suggestion ;) Thanks for the segue, Martin. :-) The Apache MyFaces shared codebase is currently duplicated in both MyFaces runtime implementation and the MyFaces Tomahawk extensions. The major reason for duplicating is to allow the MyFaces Tomahawk extensions to have all the classes they need when executing on a non-MyFaces Runtime, such as the RI. Otherwise, MyFaces Tomahawk would only run in MyFaces Runtime, which would be a non-starter. However, since there is duplication, then upgrading either of these (Runtime / Tomahawk) in a deployed environment independently would cause the shared classes to be upgraded as well, for both of the projects. This assumes the classpath is setup to place the newest JAR last, which might not be the case. This problem leads to a version conflict for the duplicated shared code. It seems there are at least two possible resolutions to this problem. 1) repackage the shared code in each project to eliminate the impact of independent upgrades 2) require a specific version combination of MyFaces Runtime / MyFaces Tomahawk to ensure the same shared code is present in both projects, making classpath ordering unimportant As far as I know, we currently use #2. However, this places MyFaces Runtime at an unnecessary disadvantage compared to the RI. For example, any version of MyFaces Tomahawk can run on any version of the RI (assuming TCK passes!) However, each version of MyFaces Tomahawk is guaranteed to run on (and not adversely impact) exactly one version of the MyFaces Runtime. Therefore, I would recommend that we investigate solution #1 in the short term to eliminate these concerns. The same approach can be applied for other dependencies that we decide to duplicate in our codebase as discussed in this thread. In general, we should minimize (not eliminate) dependencies, and (automatically?) duplicate code only when we decide that a particular dependency has shown a track record of being sufficiently incompatible across releases. Once that dependency stabilizes, we can stop the duplication and establish the (now reliable) dependency. As far as reporting dependencies is concerned, it might be useful to deliver a built-in MyFaces ViewHandler that can serve an XML document describing the Classpath and other useful debugging information. Then end-users can include that information when filing issues in JIRA, or by request on the mailing list. Kind Regards, John Fallows. On 10/19/05, Werner Punz [EMAIL PROTECTED] wrote: Simon Kitching wrote: Hi guys, Well, you should check out some of the email discussions held on commons-dev about this. The general conclusion was that even commons components should avoid dependencies on other commons components where feasable. Well commons are absolute base libs, but there always is a huge issue if you have too much deps, because other stuff has those deps as well and you might end up in a conflict once you try to merge myfaces into other subsystems. Even commons does not manage it to be outside of commons deps. But as others have stated, there is no sanity in having a copy paste of commons classes into the core codebase, because you end up in a maintenment mess bigger than Mount Everest. There are two ways: a) Try to keep the number of deps as small as possible and restricted to the absolut core libs. Commons Lang is probably save, while commons-httpclient would be probably a different issue. b) Push the commons stuff into its own safe namespace so that it does not conflict with external namespaces of the same namespace. (I did that recently by pushing a httpclient and its dependency into a supportive.org.apache.xxx namespaces) This can be done relatively easy via refactoring tools but it is a huge codeupdate. Sun for instance did that as well with their own Xerces bundle which they have bundled with JDK 5.0. (They pushed it into sun.org.apache.xerces or something similar) A total independence of external libs would be good bug only b) would allow that in a sane manner and still it is sort of a maintenance nightmare, because with every release you have to do the refactoring cycle all over again. -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[jira] Commented: (MYFACES-665) StartupServletContextListener crashes if all jars placed in webapp
[ http://issues.apache.org/jira/browse/MYFACES-665?page=comments#action_12331698 ] John Grange commented on MYFACES-665: - I have attached comments and work-around to http://opensource2.atlassian.com/projects/spring/browse/SPR-1348 I get the same problems on weblogic 7.0 sp6, so not Resin specific BTW: Spring say Won't Fix :-( StartupServletContextListener crashes if all jars placed in webapp -- Key: MYFACES-665 URL: http://issues.apache.org/jira/browse/MYFACES-665 Project: MyFaces Type: Bug Components: Implementation Environment: at least resin 3.0.14 (maybe other containers) Reporter: Thomas Timbul Priority: Critical This problem seems to be related to http://issues.apache.org/jira/browse/MYFACES-630 This also happens in the StartupServletContextListener. This problem occurs when BOTH jars are placed in the webapp classpath ONLY. (myfaces-api is NOT in the container classpath) The only working configuration seems to be myfaces-api in container classpath. myfaces-impl in webapp classpath. I previously posted this as an error in the wiki (#631), which of course shouldn't be posted here as was pointed out to me, but it seems to be an implementation problem(?) Alternatively I could suggest that this is a problem with Spring. The spring jar happens to be in the container classpath, but I am using spring's DelegatingVariableResolver in the application. So the issue could result from Spring (in container) to load faces (in webapp) ?? I do not know. Trace from resin 3.0.14: [09:29:29.453] Loading Spring root WebApplicationContext [09:29:36.171] java.lang.NoClassDefFoundError: javax/faces/el/VariableResolver [09:29:36.171] at java.lang.ClassLoader.defineClass1(Native Method) [09:29:36.171] at java.lang.ClassLoader.defineClass(ClassLoader.java:620) [09:29:36.171] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [09:29:36.171] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [09:29:36.171] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [09:29:36.171] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [09:29:36.171] at java.security.AccessController.doPrivileged(Native Method) [09:29:36.171] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [09:29:36.171] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [09:29:36.171] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [09:29:36.171] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [09:29:36.171] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [09:29:36.171] at java.lang.Class.forName0(Native Method) [09:29:36.171] at java.lang.Class.forName(Class.java:242) [09:29:36.171] at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1014) [09:29:36.171] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [09:29:36.171] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [09:29:36.171] at java.lang.Class.forName0(Native Method) [09:29:36.171] at java.lang.Class.forName(Class.java:242) [09:29:36.171] at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1014) [09:29:36.171] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [09:29:36.171] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [09:29:36.171] at java.lang.Class.forName0(Native Method) [09:29:36.171] at java.lang.Class.forName(Class.java:242) [09:29:36.171] at com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1014) [09:29:36.171] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [09:29:36.171] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [09:29:36.171] at java.lang.Class.forName0(Native Method) [09:29:36.171] at java.lang.Class.forName(Class.java:242) [09:29:36.171] at org.apache.myfaces.util.ClassUtils.classForName(ClassUtils.java:131) [09:29:36.171] at org.apache.myfaces.util.ClassUtils.simpleClassForName(ClassUtils.java:157) [09:29:36.171] at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:506) [09:29:36.171] at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:446) [09:29:36.171] at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:130) [09:29:36.171] at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) [09:29:36.171] at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) [09:29:36.171] at com.caucho.server.webapp.Application.start(Application.java:1539) [09:29:36.171] at com.caucho.server.deploy.DeployController.startImpl(DeployController.java
[jira] Commented: (MYFACES-384) Allow Pre-compiling web application for Tomcat
[
http://issues.apache.org/jira/browse/MYFACES-384?page=comments#action_12320078
]
John Schneider commented on MYFACES-384:
I've finally had some time to work on this issue, and have come up with a
possible solution.
I have tested the patch below on Tomcat 5.5 in a very simple web app. You can
recreate the environment with the FacesFilter and web.xml above.
The only difference is in web.xml, change:
servlet-mapping
servlet-nameorg.apache.jsp.success_jsp/servlet-name
url-pattern/success.jsp/url-pattern
/servlet-mapping
(changed /success.jsf to success.jsp)
I would appreciate it if others could test this in other environments. It
would be nice to add support for precompilation for the next MyFaces release.
--- WebXml~.javaThu Aug 25 19:59:30 2005
+++ WebXml.java Thu Aug 25 21:16:00 2005
@@ -30,7 +30,7 @@
*/
public class WebXml
{
-private static final Log log = LogFactory.getLog(WebXmlParser.class);
+private static final Log log = LogFactory.getLog(WebXml.class);
private Map _servlets = new HashMap();
private Map _servletMappings = new HashMap();
@@ -84,7 +84,20 @@
continue;
}
Class servletClass =
ClassUtils.simpleClassForName((String)entry.getValue());
-if (FacesServlet.class.isAssignableFrom(servletClass))
+boolean tomcatPrecompiledFacesServlet;
+
+try
+{
+ servletClass.getDeclaredField(_jspx_tagPool_f_view);
+ tomcatPrecompiledFacesServlet = true;
+}
+catch (NoSuchFieldException e)
+{
+ tomcatPrecompiledFacesServlet = false;
+}
+
+
+if (FacesServlet.class.isAssignableFrom(servletClass) ||
tomcatPrecompiledFacesServlet)
{
List urlPatterns = (List)_servletMappings.get(servletName);
for (Iterator it2 = urlPatterns.iterator(); it2.hasNext(); )
Allow Pre-compiling web application for Tomcat
--
Key: MYFACES-384
URL: http://issues.apache.org/jira/browse/MYFACES-384
Project: MyFaces
Type: Improvement
Components: General
Versions: 1.0.9 beta
Environment: Tomcat -- Jasper2
Reporter: John Schneider
Assignee: Manfred Geiler
Priority: Minor
Pre-compiling web applications for Tomcat is not supported out of the box
as it should be. I have written a filter that performs essentially the same
function as FacesServlet, so that each individual JSP servlet can be defined
and mapped in web.xml. However, limitations in
myfaces.webapp.webxml.WebXml.getFacesServletMappings() prevents these mapped
servlets from rendering the view.
The code in question is: if
(FacesServlet.class.isAssignableFrom(servletClass)) {
This will prevent any pre-compiled page from being added as a faces servlet
mapping, as these servlets extend org.apache.jasper.runtime.HttpJspBase.
The applicable stack trace is as follows:
14:02:45,443 DEBUG LifecycleImpl:118 - entering restoreView in
org.apache.myfaces
.lifecycle.LifecycleImpl
14:02:45,637 DEBUG JspStateManagerImpl:196 - No serialized view found in
server s
ession!
14:02:45,779 DEBUG JspViewHandlerImpl:191 - Created view /success.jsp
14:02:45,914 DEBUG DebugUtils:158 - Newly created view
UIViewRoot id=NULL family=javax.faces.ViewRoot locale=en
renderKitId=HTML
_BASIC rendered=true rendererType=NULL rendersChildren=false
transient=fa
lse viewId=/success.jsp/
14:02:45,960 DEBUG LifecycleImpl:157 - exiting restoreView in
org.apache.myfaces.
lifecycle.LifecycleImpl (-- render response)
14:02:45,963 DEBUG LifecycleImpl:288 - entering renderResponse in
org.apache.myfa
ces.lifecycle.LifecycleImpl
14:02:45,981 DEBUG WebXmlParser:117 - ignoring servlet +
org.apache.jsp.success_j
sp class org.apache.jsp.success_jsp (no FacesServlet)
14:02:45,985 ERROR JspViewHandlerImpl:424 - no faces servlet mappings found
14:02:46,012 ERROR success_jsp]:253 - Servlet.service() for servlet
org.apache.js
p.success_jsp threw exception
java.lang.IllegalArgumentException: could not find pathMapping for
servletPath =
/success.jsf requestPathInfo = null
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.getServletMappin
g(JspViewHandlerImpl.java:425)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspVi
ewHandlerImpl.java:246)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:3
00)
at com.urban4life.web.util.FacesFilter.doFilter(FacesFilter.java:63)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
[jira] Created: (MYFACES-384) Allow Pre-compiling web application for Tomcat
Allow Pre-compiling web application for Tomcat
--
Key: MYFACES-384
URL: http://issues.apache.org/jira/browse/MYFACES-384
Project: MyFaces
Type: Improvement
Components: General
Versions: 1.0.9 beta
Environment: Tomcat -- Jasper2
Reporter: John Schneider
Priority: Minor
Pre-compiling web applications for Tomcat is not supported out of the box as
it should be. I have written a filter that performs essentially the same
function as FacesServlet, so that each individual JSP servlet can be defined
and mapped in web.xml. However, limitations in
myfaces.webapp.webxml.WebXml.getFacesServletMappings() prevents these mapped
servlets from rendering the view.
The code in question is: if (FacesServlet.class.isAssignableFrom(servletClass))
{
This will prevent any pre-compiled page from being added as a faces servlet
mapping, as these servlets extend org.apache.jasper.runtime.HttpJspBase.
The applicable stack trace is as follows:
14:02:45,443 DEBUG LifecycleImpl:118 - entering restoreView in
org.apache.myfaces
.lifecycle.LifecycleImpl
14:02:45,637 DEBUG JspStateManagerImpl:196 - No serialized view found in server
s
ession!
14:02:45,779 DEBUG JspViewHandlerImpl:191 - Created view /success.jsp
14:02:45,914 DEBUG DebugUtils:158 - Newly created view
UIViewRoot id=NULL family=javax.faces.ViewRoot locale=en
renderKitId=HTML
_BASIC rendered=true rendererType=NULL rendersChildren=false
transient=fa
lse viewId=/success.jsp/
14:02:45,960 DEBUG LifecycleImpl:157 - exiting restoreView in
org.apache.myfaces.
lifecycle.LifecycleImpl (-- render response)
14:02:45,963 DEBUG LifecycleImpl:288 - entering renderResponse in
org.apache.myfa
ces.lifecycle.LifecycleImpl
14:02:45,981 DEBUG WebXmlParser:117 - ignoring servlet +
org.apache.jsp.success_j
sp class org.apache.jsp.success_jsp (no FacesServlet)
14:02:45,985 ERROR JspViewHandlerImpl:424 - no faces servlet mappings found
14:02:46,012 ERROR success_jsp]:253 - Servlet.service() for servlet
org.apache.js
p.success_jsp threw exception
java.lang.IllegalArgumentException: could not find pathMapping for servletPath =
/success.jsf requestPathInfo = null
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.getServletMappin
g(JspViewHandlerImpl.java:425)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspVi
ewHandlerImpl.java:246)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:3
00)
at com.urban4life.web.util.FacesFilter.doFilter(FacesFilter.java:63)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
lve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
lve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
va:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
va:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
e.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proces
sConnection(Http11Protocol.java:744)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoi
nt.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFoll
owerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
ol.java:684)
at java.lang.Thread.run(Thread.java:595)
-
FacesFilter:
import java.io.IOException;
import javax.faces.FactoryFinder;
import javax.faces.context.FacesContext;
import javax.faces.context.FacesContextFactory;
import javax.faces.lifecycle.Lifecycle;
import javax.faces.lifecycle.LifecycleFactory;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* @author a href=mailto:[EMAIL PROTECTED]John Schneider/a
*/
public class FacesFilter implements Filter {
private Log logger = LogFactory.getLog(FacesFilter.class);
public static final String LIFECYCLE_ID_ATTR =
javax.faces.LIFECYCLE_ID;
private FilterConfig filterConfig;
private FacesContextFactory facesContextFactory;
private
RE: TCK for JavaServer Faces
I haven't heard anymore about the TCK. What is the current status? John Rohrlich BEA Systems -Original Message- From: Kevin Osborn [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 9:13 AM To: [EMAIL PROTECTED] Cc: MyFaces PMC; MyFaces Development Subject: Re: TCK for JavaServer Faces Sorry, we were closed down for the week. I'll look into it for you and get you an update this week. Martin Marinschek wrote: Follow up as I haven't heard back of you: would it be possible to just shortly tell me if things are moving or if there is no way of receiving the TCK right now? regards, Martin On 7/3/05, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Kevin, regarding the short discussion we had at the JavaOne: it would be great if you could make sure we get the TCK for JSF1.1... We have already been trying to get it 1 1/2 years ago, then tried it again via the Apache Board, but haven't had any luck so far. Thank you very much! regards, Martin
Re: Welcome James!
Congratulations, James. :-) On 7/19/05, Manfred Geiler [EMAIL PROTECTED] wrote: Ladies and Gentlemen, Please welcome our new MyFaces committer James Mitchell (jmitchell)! James, glad to have you on board and looking forward to working together. Kind regards, Manfred Geiler
Re: [suggestion] ajaxInputSuggest
On 7/14/05, Sean Schofield [EMAIL PROTECTED] wrote: Since we are going to have two components for the forseeable future (at least in the sandbox) can I *suggest* that we call the ajax one ajaxSuggest? IMO ajaxInputSuggest is a little too wordy and easy to confuse with inputSuggest. The lower case first letter makes this appear to be a suggestion for the tag name. The standard naming convention for tags with a behavioral superclass of UIInput is input*, and ajaxSuggest does not follow that convention. You should pick a tag name that begins with input, such as inputAjaxSuggest, to help users understand both the behavioral contract and the interactive presentation contract for this component. Kind Regards, John Fallows.
