Re: [VOTE] release of myfaces core 1.1.6
+0 (unfortunately stuck in my day job - no time for testing - but appreciating the new release) Thanks Leonardo! --Manfred On Tue, Aug 12, 2008 at 11:11 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.1.6 release of Apache MyFaces core out. The artifacts passed all TCK test. It also passes maven clirr test (mvn clirr:check -DcomparsionVersion=1.1.5). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v2.0.8 [1] 2. Maven artifact group org.apache.myfaces.core v1.1.6 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.1.6 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces116 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces116binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312312styleName=HtmlprojectId=10600 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [myfaces core] Is there any task left for release myfaces core 1.2.4?
Leonardo Uribe schrieb: Hi As planned to release tomahawk, It could be good (optional) to release myfaces core 1.2.4 Is there any task left to do this? If no I'll start the release procedure. Sounds good to me. There is always more to do, but I don't know of anything critical. So +1
[jira] Updated: (TRINIDAD-1156) update tagdoc for RowDisclosure
[ https://issues.apache.org/jira/browse/TRINIDAD-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1156: - Resolution: Fixed Fix Version/s: 1.0.10-core 1.2.10-core Status: Resolved (was: Patch Available) update tagdoc for RowDisclosure --- Key: TRINIDAD-1156 URL: https://issues.apache.org/jira/browse/TRINIDAD-1156 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.8-core, 1.0.9-core, 1.2.9-core Reporter: Venkata Guddanti Assignee: Matthias Weßendorf Priority: Minor Fix For: 1.2.10-core, 1.0.10-core Attachments: trunk.patch In the Events section, for org.apache.myfaces.trinidad.event.RowDisclosureEvent the text The Expansion event is generated when tree nodes are expanded or collapsed. was changed to: The Expansion event is generated when detail facet for the rows are expanded or collapsed. However this event is shared by the table, treeTable and tree component. The text should read: The expansion event is generated for a table when the detail facet of a row is expanded or collapsed. For tree or a treeTable, the expansion event is generated when tree nodes are expanded or collapsed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[tomahawk] extensionsfilter refactoring
Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. Regards, Simon
Re: [tomahawk] extensionsfilter refactoring
Simon, On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. was there a jira issue for it ? or can you point me to the svn rev? -M Regards, Simon -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [tomahawk] extensionsfilter refactoring
Matthias Wessendorf schrieb: Simon, On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. was there a jira issue for it ? or can you point me to the svn rev? The best thing to do is to look at these classes: org.apache.myfaces.webapp.filter.ExtensionsFilter org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory org.apache.myfaces.webapp.filter.TomahawkFacesContextWrapper org.apache.myfaces.webapp.filter.ExtensionsFilterConfig [1] The svn history of these files references MYFACES-434. There is no specific jira issue about my concerns; it is really an architecture/design disagreement rather than a specific bug. [1] ExtensionsFilterConfig.getExtensionsFilterConfig is invoked from TomahawkFacesContextWrapper. Regards, Simon
[jira] Created: (TOMAHAWK-1314) Escape attribute in radio and checkbox not working
Escape attribute in radio and checkbox not working -- Key: TOMAHAWK-1314 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1314 Project: MyFaces Tomahawk Issue Type: Bug Components: selectOneRadio / radio Affects Versions: 1.1.7-SNAPSHOT Environment: Tomcat 6.0.16 Tomahawk12-1.1.7-SNAPSHOT myfaces-api-1.2.4-SNAPSHOT myfaces-impl-1.2.4-SNAPSHOT Reporter: Paul Rivera Escape attribute is not working properly in radio and checkbox tags. I've attached a jsp file that shows this test case. If you run the sample, all of them are escaped even if you set escape to false. This problem is related to MYFACES-1897. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1897) escape value of a selectItem is never evaluated
[
https://issues.apache.org/jira/browse/MYFACES-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12622155#action_12622155
]
Paul Rivera commented on MYFACES-1897:
--
I've created TOMAHAWK-1314 for the tomahawk patch.
escape value of a selectItem is never evaluated
---
Key: MYFACES-1897
URL: https://issues.apache.org/jira/browse/MYFACES-1897
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.3
Reporter: Jörg Rothbarth
Assignee: Leonardo Uribe
Fix For: 1.2.4-SNAPSHOT
Attachments: myfaces-1897-part1.patch, myfaces-1897-part2.patch,
SelectItemEscapeBean.java, selectOneManyEscape-simple.jsp,
selectOneManyEscape.jsp, tomahawk12-HtmlCheckboxRenderer.patch,
tomahawk12-HtmlRadioRenderer.patch
The escape Attribute of a selectItem Component is not evaluated inside a
selectOneRadio component.
The selectItem Component has a escape member, but the member is never used.
To fix the problem i've done this:
HtmlRadioRendererBase.renderGroupOrItemRadio() Line ~199 :
// label element after the input
boolean componentDisabled = isDisabled(facesContext, selectOne);
boolean disabled = (componentDisabled || itemDisabled);
boolean escape = selectItem.isEscape();
HtmlRendererUtils.renderLabel(writer, selectOne, itemId,
selectItem.getLabel(), disabled,escape);
HtmlRendererUtils.renderLabel() Line ~1352:
public static void renderLabel(ResponseWriter writer, UIComponent
component, String forClientId,String labelValue, boolean
disabled) throws IOException {
renderLabel(writer, component, forClientId, labelValue, disabled, true);
}
/**
* Renders a label HTML element
*/
public static void renderLabel(ResponseWriter writer, UIComponent
component, String forClientId,String labelValue, boolean
disabled, boolean escape) throws IOException {
...
if ((labelValue != null) (labelValue.length() 0)) {
writer.write(HTML.NBSP_ENTITY);
if (escape) {
writer.writeText(labelValue, null);
} else {
writer.write(labelValue);
}
}
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [myfaces core] Is there any task left for release myfaces core 1.2.4?
[EMAIL PROTECTED] schrieb: Leonardo Uribe schrieb: Hi As planned to release tomahawk, It could be good (optional) to release myfaces core 1.2.4 Is there any task left to do this? If no I'll start the release procedure. Sounds good to me. There is always more to do, but I don't know of anything critical. So +1 Oh yeah, there is one thing. I suggested updating the org.tomcat:catalina:6.0.10 dependency to org.tomcat:catalina:6.0.13, so we don't depend on the special maven2 repo at tomcat.apache.org (6.0.13 is in the normal maven repos). If there are no objections, I'll do this in a few hours.
Problem rendering selectOneMenu
||Hi,
Recently I came around a problem testing my app with geronimo 2.1.2
(myfaces 1.2.3).
The app is working well in jboss 4.2 (JSF RI 1.2_04), and I'm trying it
with geronimo 2.1.2 (myfaces 1.2.3).
I have a managed bean called treeManager, with a selectedNode
property that is null the first time.
I have three input components: 2 inputText, and a selectOneMenu, the JSP
code is this:
...
h:outputLabel for=nodeName value=Nom/
h:inputText id=nodeName value=#{treeManager.selectedNode.name} /
h:outputLabel for=nodeDescription value=Descripció/
h:inputText id=nodeDescription
value=#{treeManager.selectedNode.description} /
h:outputLabel for=ambitType value=Àmbit/
h:selectOneMenu id=ambitType value=#{treeManager.selectedNode.ambit}
f:selectItem itemLabel=Global itemValue=global/
f:selectItem itemLabel=Organisme itemValue=organisme/
f:selectItem itemLabel=Procediment itemValue=procediment/
/h:selectOneMenu
When I try the JSF I get this error.
|javax.faces.FacesException: Exception while calling encodeEnd on
component : {Component-Path : [Class:
org.ajax4jsf.component.AjaxViewRoot,ViewId:
/dissenyador/estructures.jsp][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id_jsp_305935947_1]}|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)|
Caused by: ...
|Caused by: org.apache.jasper.el.JspPropertyNotFoundException:
/dissenyador/estructures.jsp(60,8) '#{treeManager.selectedNode.ambit}'
Target Unreachable, 'selectedNode' returned null|
| at
org.apache.jasper.el.JspValueExpression.getType(JspValueExpression.java:61)|
| at
org.apache.myfaces.shared_impl.renderkit._SharedRendererUtils.findUIOutputConverter(_SharedRendererUtils.java:58)|
| at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.findUIOutputConverter(RendererUtils.java:391)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.findUIOutputConverterFailSafe(HtmlRendererUtils.java:393)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:316)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:288)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:57)|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:607)|
Don't know if this is correct, because its true that selectedNode
evaluates to null, but no exception is thrown when rendering the two
previus inputText that also reference selectedNode.
Is this correct? Should I file a bug report?
--
-
Antoni Reus Darder
GIT Consultors S.L.
c/ Francesc Rover 2-B
07003 Palma de Mallorca
Illes Balears
mail: [EMAIL PROTECTED]
Tel: + 34 971 49 83 10
Fax: + 34 971 49 61 89
Re: Problem rendering selectOneMenu
Antoni Reus schrieb:
||Hi,
Recently I came around a problem testing my app with geronimo 2.1.2
(myfaces 1.2.3).
The app is working well in jboss 4.2 (JSF RI 1.2_04), and I'm trying
it with geronimo 2.1.2 (myfaces 1.2.3).
I have a managed bean called treeManager, with a selectedNode
property that is null the first time.
I have three input components: 2 inputText, and a selectOneMenu, the
JSP code is this:
...
h:outputLabel for=nodeName value=Nom/
h:inputText id=nodeName value=#{treeManager.selectedNode.name} /
h:outputLabel for=nodeDescription value=Descripció/
h:inputText id=nodeDescription
value=#{treeManager.selectedNode.description} /
h:outputLabel for=ambitType value=Àmbit/
h:selectOneMenu id=ambitType
value=#{treeManager.selectedNode.ambit}
f:selectItem itemLabel=Global itemValue=global/
f:selectItem itemLabel=Organisme itemValue=organisme/
f:selectItem itemLabel=Procediment itemValue=procediment/
/h:selectOneMenu
When I try the JSF I get this error.
|javax.faces.FacesException: Exception while calling encodeEnd on
component : {Component-Path : [Class:
org.ajax4jsf.component.AjaxViewRoot,ViewId:
/dissenyador/estructures.jsp][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id_jsp_305935947_1]}|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)|
Caused by: ...
|Caused by: org.apache.jasper.el.JspPropertyNotFoundException:
/dissenyador/estructures.jsp(60,8) '#{treeManager.selectedNode.ambit}'
Target Unreachable, 'selectedNode' returned null|
| at
org.apache.jasper.el.JspValueExpression.getType(JspValueExpression.java:61)|
| at
org.apache.myfaces.shared_impl.renderkit._SharedRendererUtils.findUIOutputConverter(_SharedRendererUtils.java:58)|
| at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.findUIOutputConverter(RendererUtils.java:391)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.findUIOutputConverterFailSafe(HtmlRendererUtils.java:393)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:316)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:288)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:57)|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:607)|
Don't know if this is correct, because its true that selectedNode
evaluates to null, but no exception is thrown when rendering the two
previus inputText that also reference selectedNode.
Is this correct? Should I file a bug report?
Interesting. From the stacktrace it look like the problem is when trying
to determine the *type* that this expression returns.
When actually asking for the value, null is simply returned if the
intermediate object is not there.
But when asking what static type of object would be returned from the
bound property, of course there is a real problem if the intermediate
node is not there.
Here's the code from SharedRendererUtils.findUIOutputConverter; the
getType call is the problem:
Class valueType = vb.getType(facesContext); // boom when an
intermediate node in the EL is null
if (valueType == null) return null;
if (String.class.equals(valueType)) return null;//No
converter needed for String type
if (Object.class.equals(valueType)) return null;//There is
no converter for Object class
The HtmlRendererUtils.internalRenderSelect uses
converter = findUIOutputConverterFailSafe
-- which obviously is not quite so fail safe :-)
I'm not quite sure what the converter is being used for during rendering
of the select component, but I do know that the rules about converters
and select-components are quite complex. The HTML select component must
always render strings for its options, but JSF requires typed objects to
be passed between the select *component* and the backing beans. So
conversions are required to be invoked at various times.
I think a JIRA issues should definitely be filed for this. If a
converter is optional here, then the code should catch this exception
and not use a converter. Even if a converter is mandatory (ie an error
should be reported if the value-type cannot be determined) then at least
the error reporting needs to be improved. And it is definitely a myfaces
issue, not a Geronimo one.
Just as a side-note, please report issues like this to the user list in
future. The myfaces developers are also subscribed to that...
Regards, Simon
[jira] Created: (TRINIDAD-1178) add getContextName() to ExternalCtxUtil
add getContextName() to ExternalCtxUtil --- Key: TRINIDAD-1178 URL: https://issues.apache.org/jira/browse/TRINIDAD-1178 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.9-core, 1.0.9-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf add getContextName() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1178) add getContextName() to ExternalCtxUtil
[ https://issues.apache.org/jira/browse/TRINIDAD-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1178. -- Resolution: Fixed Fix Version/s: 1.0.10-core 1.2.10-core add getContextName() to ExternalCtxUtil --- Key: TRINIDAD-1178 URL: https://issues.apache.org/jira/browse/TRINIDAD-1178 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.0.9-core, 1.2.9-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core add getContextName() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [myfaces core] Is there any task left for release myfaces core 1.2.4?
On Wed, 2008-08-13 at 12:54 +0200, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: Leonardo Uribe schrieb: Hi As planned to release tomahawk, It could be good (optional) to release myfaces core 1.2.4 Is there any task left to do this? If no I'll start the release procedure. Sounds good to me. There is always more to do, but I don't know of anything critical. So +1 Oh yeah, there is one thing. I suggested updating the org.tomcat:catalina:6.0.10 dependency to org.tomcat:catalina:6.0.13, so we don't depend on the special maven2 repo at tomcat.apache.org (6.0.13 is in the normal maven repos). If there are no objections, I'll do this in a few hours. Done.
Re: [tomahawk] extensionsfilter refactoring
On Wed, Aug 13, 2008 at 4:12 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: Simon, On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. was there a jira issue for it ? or can you point me to the svn rev? The best thing to do is to look at these classes: org.apache.myfaces.webapp.filter.ExtensionsFilter org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory org.apache.myfaces.webapp.filter.TomahawkFacesContextWrapper org.apache.myfaces.webapp.filter.ExtensionsFilterConfig [1] The svn history of these files references MYFACES-434. There is no specific jira issue about my concerns; it is really an architecture/design disagreement rather than a specific bug. [1] ExtensionsFilterConfig.getExtensionsFilterConfig is invoked from TomahawkFacesContextWrapper. Regards, Simon Hi I'll do a simple review (just to make clear the discussion). ExtensionsFilter has the following responsibilities (all we know this but sometimes is not very clear): 1. Wrap a multipart request (used for t:inputFileUpload), so the request could be correctly decoded. 1.1 For do this, it receives some params from web.xml like this: filter filter-nameextensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value /init-param /filter 1.2 So, ExtensionsFilter must wrap the request that goes to faces pages using a filter-mapping like this: filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping 2. ExtensionsFilter must serve resources (javascript, css...) of some tomahawk components. 3. If a buffered instance of AddResource is configured, ExtensionsFilter must buffer and add the resource reference to the head of jsf pages (for example when it is used DefaultAddResource) The changes proposed on MYFACES-434 was the following: a. Use a TomahawkFacesContextWrapper to do tasks 1 and 3 of ExtensionsFilter. It must be read the config params to know how to wrap the request from web.xml, because this params are on the filter init-param part. b. Add a ServeResourcePhaseListener for do the task 2 of ExtensionsFilter (In portlets we could not be ExtensionsFilter working). c. Wrap the portlet request properly when it is multipart content, so t:inputFileUpload could work on portlets (to be done, Scott told me to wait some time). Actually, ExtensionsFilter only does task 2 (ServeResourcePhaseListener was added on faces-config.xml) and tasks 1 and 3 are done by TomahawkFacesContextWrapper. Now the problem. It could be some problems when you mix 1.1 libraries with 1.2 code that wraps FacesContext (I don't remember the myfaces issue, but the local example of this problem is when you mix orchestra(1.1) myfaces core(1.2) with tomahawk(1.1.7-SNAPSHOT)). In order to anticipate the events, It could be good to remain the old feature (if ExtensionsFilter is configured and is working, do not use
[Trinidad] GlobalConfiguratonImpl.beginRequest called once results in a fine log?
In 1.2.9.1, the GlobalConfiguratonImpl has the function:
public void beginRequest(final ExternalContext externalContext)
This checks to see if the this has already be called once
If it is called a second time the following code is executed:
else
{
_LOG.fine(BeginRequest called multiple times for this request);
}
This seems really lenient to me. I would think an exception should be
thrown. How come it is only a fine log? Is there an instance when this
is okay?
The reason I came across this, is that we had a user configure the
Trinidad filter incorrectly:
filter-mapping
filter-nametrinidad/filter-name
servlet-nameFaces Servlet/servlet-name
dispatcherFORWARD/dispatcher
dispatcherREQUEST/dispatcher
/filter-mapping
filter-mapping
filter-nametrinidad/filter-name
url-pattern*.jspx/url-pattern
dispatcherFORWARD/dispatcher
dispatcherREQUEST/dispatcher
/filter-mapping
Due to the double-registering of the filter, exceptions were being
thrown in our code. I would like to be able to throw an exception or
at least a log a fatal/severe message when this happens.
Any opinions on this?
Let me know if it is valid to call beginRequest more than once. Also,
if you have a better means to detect an invalid filter setup, feel
free to share.
-Andrew
[jira] Created: (TRINIDAD-1179) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not
Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not --- Key: TRINIDAD-1179 URL: https://issues.apache.org/jira/browse/TRINIDAD-1179 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: Microsoft Windows XP Reporter: Anita Anandan Priority: Minor Steps to reproduce: Create a length validator associated with an input text. Provide a minimum attribute but not the maximum. Provide a custom error message using the attribute messageDetailMinimum. Provide a incorrect value. The default error message is displayed. You would expect the custom message you provided to be displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1179) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not
[ https://issues.apache.org/jira/browse/TRINIDAD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Anandan updated TRINIDAD-1179: Status: Patch Available (was: Open) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not --- Key: TRINIDAD-1179 URL: https://issues.apache.org/jira/browse/TRINIDAD-1179 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: Microsoft Windows XP Reporter: Anita Anandan Priority: Minor Steps to reproduce: Create a length validator associated with an input text. Provide a minimum attribute but not the maximum. Provide a custom error message using the attribute messageDetailMinimum. Provide a incorrect value. The default error message is displayed. You would expect the custom message you provided to be displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1179) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not
[ https://issues.apache.org/jira/browse/TRINIDAD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Anandan updated TRINIDAD-1179: Status: Open (was: Patch Available) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not --- Key: TRINIDAD-1179 URL: https://issues.apache.org/jira/browse/TRINIDAD-1179 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: Microsoft Windows XP Reporter: Anita Anandan Priority: Minor Steps to reproduce: Create a length validator associated with an input text. Provide a minimum attribute but not the maximum. Provide a custom error message using the attribute messageDetailMinimum. Provide a incorrect value. The default error message is displayed. You would expect the custom message you provided to be displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1179) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not
[ https://issues.apache.org/jira/browse/TRINIDAD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Anandan updated TRINIDAD-1179: Status: Patch Available (was: Open) Custom message of the length validator not displayed when the minimum attribute is specified and the maximum is not --- Key: TRINIDAD-1179 URL: https://issues.apache.org/jira/browse/TRINIDAD-1179 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: Microsoft Windows XP Reporter: Anita Anandan Priority: Minor Steps to reproduce: Create a length validator associated with an input text. Provide a minimum attribute but not the maximum. Provide a custom error message using the attribute messageDetailMinimum. Provide a incorrect value. The default error message is displayed. You would expect the custom message you provided to be displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [tomahawk] extensionsfilter refactoring
On Wed, Aug 13, 2008 at 3:48 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 4:12 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: Simon, On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. was there a jira issue for it ? or can you point me to the svn rev? The best thing to do is to look at these classes: org.apache.myfaces.webapp.filter.ExtensionsFilter org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory org.apache.myfaces.webapp.filter.TomahawkFacesContextWrapper org.apache.myfaces.webapp.filter.ExtensionsFilterConfig [1] The svn history of these files references MYFACES-434. There is no specific jira issue about my concerns; it is really an architecture/design disagreement rather than a specific bug. [1] ExtensionsFilterConfig.getExtensionsFilterConfig is invoked from TomahawkFacesContextWrapper. Regards, Simon Hi I'll do a simple review (just to make clear the discussion). ExtensionsFilter has the following responsibilities (all we know this but sometimes is not very clear): 1. Wrap a multipart request (used for t:inputFileUpload), so the request could be correctly decoded. 1.1 For do this, it receives some params from web.xml like this: filter filter-nameextensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value /init-param /filter 1.2 So, ExtensionsFilter must wrap the request that goes to faces pages using a filter-mapping like this: filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping 2. ExtensionsFilter must serve resources (javascript, css...) of some tomahawk components. 3. If a buffered instance of AddResource is configured, ExtensionsFilter must buffer and add the resource reference to the head of jsf pages (for example when it is used DefaultAddResource) The changes proposed on MYFACES-434 was the following: a. Use a TomahawkFacesContextWrapper to do tasks 1 and 3 of ExtensionsFilter. It must be read the config params to know how to wrap the request from web.xml, because this params are on the filter init-param part. b. Add a ServeResourcePhaseListener for do the task 2 of ExtensionsFilter (In portlets we could not be ExtensionsFilter working). c. Wrap the portlet request properly when it is multipart content, so t:inputFileUpload could work on portlets (to be done, Scott told me to wait some time). Actually, ExtensionsFilter only does task 2 (ServeResourcePhaseListener was added on faces-config.xml) and tasks 1 and 3 are done by TomahawkFacesContextWrapper. Now the problem. It could be some problems when you mix 1.1 libraries with 1.2 code that wraps FacesContext (I don't remember the myfaces issue, but the local example of this problem is when you mix orchestra(1.1) myfaces core(1.2) with tomahawk(1.1.7-SNAPSHOT)). In order to anticipate
Re: [tomahawk] extensionsfilter refactoring
+1 for Leonardo solution. I really cannot find another way to accomplish this as well. On Thu, Aug 14, 2008 at 2:19 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 3:48 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 4:12 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: Simon, On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, Just a reminder of the email I posted a few weeks ago: I'm still very concerned about the recent ExtensionsFilter refactoring. The new code now parses the web.xml to extract some configuration information. This just feels wrong to me. The new code also is based around a custom FacesContext wrapper. I'm worried about possible interactions between this and other libraries that also wrap FacesContext. And I'm worried about the portability of this code to the upcoming JSF2.0. I know this stuff is needed to get tomahawk useable for portlets. But it's very important not to break existing users. What I would like to see is: * separate out the resource-serving stuff into a separate utilities module, that can be called from either a filter or a FacesContext. And call the common code from both ExtensionsFilter and TomahawkFacesContextWrapper. * have the TomahawkFacesContextFactory create a FacesContext wrapper only in the case where the filter is not configured, ie look in the request-scope for a flag placed there by the filter. That means there is no chance of breaking existing setups where the filter is defined explicitly. * ideally, also have some way of turning off the faces-context wrapping even when the filter is not present. * don't parse the web.xml at all. I know you said earlier that it is needed, but I just don't see why. In any case, I think we *must* find some other solution; the current approach is really hard to maintain. Until this is fixed, I would definitely vote -1 on any tomahawk release. It's a major issue. was there a jira issue for it ? or can you point me to the svn rev? The best thing to do is to look at these classes: org.apache.myfaces.webapp.filter.ExtensionsFilter org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory org.apache.myfaces.webapp.filter.TomahawkFacesContextWrapper org.apache.myfaces.webapp.filter.ExtensionsFilterConfig [1] The svn history of these files references MYFACES-434. There is no specific jira issue about my concerns; it is really an architecture/design disagreement rather than a specific bug. [1] ExtensionsFilterConfig.getExtensionsFilterConfig is invoked from TomahawkFacesContextWrapper. Regards, Simon Hi I'll do a simple review (just to make clear the discussion). ExtensionsFilter has the following responsibilities (all we know this but sometimes is not very clear): 1. Wrap a multipart request (used for t:inputFileUpload), so the request could be correctly decoded. 1.1 For do this, it receives some params from web.xml like this: filter filter-nameextensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value /init-param /filter 1.2 So, ExtensionsFilter must wrap the request that goes to faces pages using a filter-mapping like this: filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping 2. ExtensionsFilter must serve resources (javascript, css...) of some tomahawk components. 3. If a buffered instance of AddResource is configured, ExtensionsFilter must buffer and add the resource reference to the head of jsf pages (for example when it is used DefaultAddResource) The changes proposed on MYFACES-434 was the following: a. Use a TomahawkFacesContextWrapper to do tasks 1 and 3 of ExtensionsFilter. It must be read the config params to know how to wrap the request from web.xml, because this params are on the filter init-param part. b. Add a ServeResourcePhaseListener for do the task 2 of ExtensionsFilter (In portlets we could not be ExtensionsFilter working). c. Wrap the portlet request properly when it is multipart content, so t:inputFileUpload could work on portlets (to be done, Scott told me to wait some time). Actually, ExtensionsFilter only does task 2 (ServeResourcePhaseListener was added on faces-config.xml) and tasks 1 and 3 are done by TomahawkFacesContextWrapper. Now the problem. It could be some problems when you mix 1.1 libraries with 1.2 code that wraps FacesContext (I don't remember
