Re: [VOTE] release for myfaces core 2.0.0-beta
+1 (nonbinding) It would really be appreciated if we could ship MyFaces-2.0.0-beta with the OpenWebBeans-M4 release we are planing to do this week ;) LieGrue, strub --- On Fri, 1/29/10, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: From: Jan-Kees van Andel jankeesvanan...@gmail.com Subject: Re: [VOTE] release for myfaces core 2.0.0-beta To: MyFaces Development dev@myfaces.apache.org Date: Friday, January 29, 2010, 9:17 PM +1 on the release. Also +1 on the three weekly release if Leonardo can handle the extra burden. :-) Regards, Jan-Kees 2010/1/29 Matthias Wessendorf mat...@apache.org: On Fri, Jan 29, 2010 at 5:29 PM, Leonardo Uribe lu4...@gmail.com wrote: 2010/1/29 Ganesh gan...@j4fry.org Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. I don't believe this is a myfaces problem. This error is usually found when jce.jar is not found on your classpath. I think we should release this as beta and later do another beta if required (in 2 or 3 weeks?). I'm not have any problem to do it. IMO that's fine... We should also have every three weeks a new beta ;-) -Matthias regards, Leonardo Uribe Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tomahawk on Google App Engine
Great :) I can deploy them on GAE after your work. Thanks, On Mon, Feb 1, 2010 at 12:24 AM, Ingo Hofmann ingo.hofmann.pri...@googlemail.com wrote: Hi Ali, On Friday I also started with converting the Tomahawk example JSPs to Facelets. So if you need all other examples as Facelets you can just wait for my work. I'm almost finished (I'm still fighting with some deployment issues, that's it). Best, Ingo 2010/1/31 Ali Ok al...@aliok.com.tr Hi, I deployed the Tomahawk-Exampleshttp://example.irian.at/myfacesexamples/home.jsf application on Google App Engine. Here is the link: http://tomahawk-01.latest.aliok-com-tr-test.appspot.com/ I followed the procedure described in - https://issues.apache.org/jira/browse/MYFACES-2504* : *2504-doc.diff - http://myfaces.apache.org/tomahawk/index.html Since JSP support is problematic and we should use Facelets as view renderer on Google App Engine, I needed to convert jsp pages to Facelets, which is annoying (I hate f:verbatim) . I converted only first 7 example on the index, and there is a problem with displayValueOnly attribute example. But you can think this application as a proof of concept. You can find the Eclipse project and the sources here: http://sites.google.com/a/aliok.com.tr/upload/uploads/Tomahawk--Examples-GAE.zip Please note that myfaces-api-1.2.8-AO.jar and myfaces-impl-1.2.8-AO.jar in the project are the jars that patch https://issues.apache.org/jira/browse/MYFACES-2504 : 2504-3.diff is applied. Regards, Ali
[jira] Created: (TOMAHAWK-1483) Build Failure on Maven 2.2.1
Build Failure on Maven 2.2.1
Key: TOMAHAWK-1483
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1483
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Build Process (Assembly)
Affects Versions: 1.1.10-SNAPSHOT
Environment: Windows 7, Maven 2.2.1
Reporter: Michael Kurz
Attachments: TOMAHAWK-1483.patch
We had some strange troubles over here building the Tomahawk trunk. The build
succeeded on one machine and failed on another. After some investigations we
found out that it is working with Maven 2.0.10 and not working with Maven 2.2.1
(generated source folders are not used in core12 and core20).
The problem seems to be, that the build-helper-maven-plugin is defined twice in
core12 and core20. The first time it adds the following directories in phase
generate-sources:
${project.build.directory}/shared_sources
${project.build.directory}/tomahawk12_sources
The second time it adds the following directories in phase process-sources:
${project.build.directory}/shared_sources
The funny thing is, with Maven 2.2.1 the first plugin execution in phase
generate-sources never seems to be called. When I remove the second one it
works as expected.
Anyway, do we need the second execution of the plugin in phase process-sources?
I don't see a reason.
Thanks to Ingo Hofmann for pointing me to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1483) Build Failure on Maven 2.2.1
[
https://issues.apache.org/jira/browse/TOMAHAWK-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kurz updated TOMAHAWK-1483:
---
Status: Patch Available (was: Open)
Build Failure on Maven 2.2.1
Key: TOMAHAWK-1483
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1483
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Build Process (Assembly)
Affects Versions: 1.1.10-SNAPSHOT
Environment: Windows 7, Maven 2.2.1
Reporter: Michael Kurz
Attachments: TOMAHAWK-1483.patch
We had some strange troubles over here building the Tomahawk trunk. The build
succeeded on one machine and failed on another. After some investigations we
found out that it is working with Maven 2.0.10 and not working with Maven
2.2.1 (generated source folders are not used in core12 and core20).
The problem seems to be, that the build-helper-maven-plugin is defined twice
in core12 and core20. The first time it adds the following directories in
phase generate-sources:
${project.build.directory}/shared_sources
${project.build.directory}/tomahawk12_sources
The second time it adds the following directories in phase process-sources:
${project.build.directory}/shared_sources
The funny thing is, with Maven 2.2.1 the first plugin execution in phase
generate-sources never seems to be called. When I remove the second one it
works as expected.
Anyway, do we need the second execution of the plugin in phase
process-sources? I don't see a reason.
Thanks to Ingo Hofmann for pointing me to this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (EXTVAL-82) Add the EmptyValueAwareValidationStrategy annotation to the Length and Pattern Annotations
[
https://issues.apache.org/jira/browse/EXTVAL-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806744#action_12806744
]
Rudy De Busscher edited comment on EXTVAL-82 at 2/1/10 2:01 PM:
The changed behaviour of @Length and @Pattern is indeed something that needs to
be documented. In the case a project upgrades to version x.x.3, the required
check they used to have implicitly, is gone.
The following is, I think, the easiest solution without major changes (no
additional constraint or custom validation strategy required) in the codebase
of the project that did an upgrade.
public class CompatiblePropertyValidationInterceptor extends
PropertyValidationInterceptor {
@Override
protected boolean isValidationStrategyCompatibleWithValue(
ValidationStrategy validationStrategy, Object value) {
if (validationStrategy instanceof LengthStrategy) {
return value != null;
}
if (validationStrategy instanceof PatternStrategy) {
return value != null;
}
return
super.isValidationStrategyCompatibleWithValue(validationStrategy, value);
}
}
and this class is registered in a custom startup listener as follows
ExtValContext.getContext().denyRendererInterceptor(PropertyValidationInterceptor.class);
ExtValContext.getContext().registerRendererInterceptor(new
CompatiblePropertyValidationInterceptor());
The functionality placed in the isValidationStrategyCompatibleWithValue method
is the same as putting an EmptyValueAwareValidationStrategy on the 2 strategies.
regards
Rudy
was (Author: rdebusscher):
The changed behaviour of @Length and @Pattern is indeed something that
needs to be documented. In the case a project upgrades to version x.x.3, the
required check they used to have implicitly, is gone.
The following is, I think, the easiest solution without major changes (no
additional constraint or custom validation strategy required) in the codebase
of the project that did an upgrade.
public class CompatiblePropertyValidationInterceptor extends
PropertyValidationInterceptor {
@Override
protected boolean isValidationStrategyCompatibleWithValue(
ValidationStrategy validationStrategy, Object value) {
if (validationStrategy instanceof LengthStrategy) {
return value != null;
}
if (validationStrategy instanceof PatternStrategy) {
return value != null;
}
return
super.isValidationStrategyCompatibleWithValue(validationStrategy, value);
}
}
and this class is registered in a custom startup listener as follows
ExtValContext.getContext().denyRendererInterceptor(ValidationInterceptor.class);
ExtValContext.getContext().registerRendererInterceptor(new
CompatiblePropertyValidationInterceptor());
The functionality placed in the isValidationStrategyCompatibleWithValue method
is the same as putting an EmptyValueAwareValidationStrategy on the 2 strategies.
regards
Rudy
Add the EmptyValueAwareValidationStrategy annotation to the Length and
Pattern Annotations
--
Key: EXTVAL-82
URL: https://issues.apache.org/jira/browse/EXTVAL-82
Project: MyFaces Extensions Validator
Issue Type: Improvement
Components: Property Validation
Affects Versions: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT
Reporter: Rudy De Busscher
Priority: Minor
Adding the EmptyValueAwareValidationStrategy allows in JSF 2.0 that Length
and Pattern validations are triggered (with the
javax.faces.VALIDATE_EMPTY_FIELDS parameter set).
They will cause a validation error with an empty string (Length annotation
with minimum set or Pattern) so the Required annotation is no longer needed.
Tested it out with ExtVal 2.0.3-SNAPSHOT and Myfaces 2.0.0-SNAPHOT (of 21/01)
and it works as expected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1484) t:inputCalendar as popup with forceId=false does not work
t:inputCalendar as popup with forceId=false does not work --- Key: TOMAHAWK-1484 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1484 Project: MyFaces Tomahawk Issue Type: Bug Components: Calendar Affects Versions: 1.1.10-SNAPSHOT Reporter: Ingo Hofmann A popup calender with forceId=true does not appear, but produces a JavaScript error when clicking on the button. The span element and JS code is rendered correctly, but the input element gets the wrong id (form ID missing). Simple Facelet page that reproduces this issue (first calender works fine, second doesn't): ?xml version=1.0 encoding=UTF-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:t=http://myfaces.apache.org/tomahawk; h:head meta HTTP-EQUIV=Content-Type CONTENT=text/html;charset=UTF-8 / titleCalender test/title /h:head h:body h:form id=calendarForm t:inputCalendar id=formWithForceIdTrue monthYearRowClass=yearMonthHeader weekRowClass=weekHeader popupButtonStyleClass=standard_bold currentDayCellClass=currentDayCell renderAsPopup=true popupDateFormat=MM/dd/ forceId=true/ t:inputCalendar id=formWithForceIdFalse monthYearRowClass=yearMonthHeader weekRowClass=weekHeader popupButtonStyleClass=standard_bold currentDayCellClass=currentDayCell renderAsPopup=true popupDateFormat=MM/dd/ forceId=false/ /h:form /h:body /html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-58) improve the update scanner
improve the update scanner -- Key: EXTSCRIPT-58 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-58 Project: MyFaces Extensions Scripting Issue Type: New Feature Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We probably not cover newly added files in our update scanner... investigate it and if not yet done add the functionality -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
t:dataList should not render li element when iterated element is not rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9, commons-el
1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging 1.1.1
Reporter: Bauke Scholtz
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-58) improve the update scanner
[ https://issues.apache.org/jira/browse/EXTSCRIPT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-58. -- Resolution: Fixed improve the update scanner -- Key: EXTSCRIPT-58 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-58 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We probably not cover newly added files in our update scanner... investigate it and if not yet done add the functionality -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-58) improve the update scanner
[ https://issues.apache.org/jira/browse/EXTSCRIPT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828237#action_12828237 ] Werner Punz commented on EXTSCRIPT-58: -- resolved, additional asynchronous scanning was introduced to check for added files in a performant manner improve the update scanner -- Key: EXTSCRIPT-58 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-58 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We probably not cover newly added files in our update scanner... investigate it and if not yet done add the functionality -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-60) overall code cleanup and unification
overall code cleanup and unification Key: EXTSCRIPT-60 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-60 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-59) overall code cleanup
overall code cleanup Key: EXTSCRIPT-59 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-59 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] MyFaces Core v2.0.0-beta Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.0-beta. MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core 2.0.0-beta is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.0.0-beta Bug * [MYFACES-2356] - HtmlRadioRendererBase calls converter method getAsString() not with the object, but with the string version when an validation error occured * [MYFACES-2396] - @PreDestroy method of Bean in CustomScope not invoked * [MYFACES-2410] - f:validateBean does not work as container for EditableValueHolders * [MYFACES-2429] - Missing localePrefix for resources is not ignored * [MYFACES-2430] - Button image url rendered wrong for resources * [MYFACES-2431] - NotSerializableException on state serialization * [MYFACES-2432] - InsertChildrenHandler.RelocateAllChildrenListener throws IndexOutOfBoundsException * [MYFACES-2434] - dummy request/response classes for system event listeners will break with Servlet 3.0 * [MYFACES-2436] - BeanValidator stops on null value (@NotNull not checked) * [MYFACES-2437] - columnClasses must not be rendered if colums columnClasses * [MYFACES-2445] - NPE on rendering outcome target links * [MYFACES-2447] - PhaseListeners not invoked correctly * [MYFACES-2450] - ViewHandler.deriveViewId must check is viewId really exists * [MYFACES-2453] - f:view is ignored by facelets * [MYFACES-2457] - f:selectItem escape property not bound in facelets * [MYFACES-2462] - ui:debug / is not working * [MYFACES-2468] - MyFaces needs to support adding a view-handler in faces-config.xml * [MYFACES-2469] - Invalid outcome gives NPE * [MYFACES-2472] - Missing return in UIComponent.EventListenerWrapper * [MYFACES-2474] - Fix navigation handler algorithm for redirects * [MYFACES-2475] - Visit facets in UIComponent.visitTree() * [MYFACES-2476] - @this in render not resolved on ajax request * [MYFACES-2477] - Ajax related fixes for command components * [MYFACES-2481] - Wrong property name in payload for ajax callback functions * [MYFACES-2482] - Use Error instead of Exception in Ajax Js Impl * [MYFACES-2484] - public final void pushComponentToEL(FacesContext context, UIComponent component) crashes if component is null * [MYFACES-2488] - PreRenderViewEvent-listeners could change UIViewRoot or set responseComplete * [MYFACES-2498] - Myfaces should be able to gracefully handle a runtime with the bean validation API on the classpath but no impl * [MYFACES-2499] - f:validateBean disabled=true not processed correctly * [MYFACES-2501] - f:validateBean should only use the validationGroups from the stack, if its validationGroups property is null or an empty string * [MYFACES-2506] - @ManagedBean doesn't work with missing scope annotation Improvement * [MYFACES-2435] - f:facet can have more than one child * [MYFACES-2444] - Implement new JSF 2 c:set features * [MYFACES-2464] - Find a way to do not use ELExpressions on jsf.js for getProjectStage Task * [MYFACES-2363] - ExceptionHandler implementation requires deal with ajax responses * [MYFACES-2368] - Update Render Response Phase to new spec * [MYFACES-2417] - h:commandButton and h:commandLink now can be rendered outside a form * [MYFACES-2418] - Implement h:selectManyXXX collectionType and hideNoSelectionOption * [MYFACES-2423] - h:dataTable renderer does not support colgroups facet * [MYFACES-2425] - JSTL Functions returns null instead * [MYFACES-2426] - UISelectItem itemEscaped should return true as default * [MYFACES-2427] - Composite Component not bound when calling ValueExpression from broadcast * [MYFACES-2428] - Id generation for facelets cause problems with htmlunit 2.4 or lower * [MYFACES-2438] - h:selectOneRadio can't render HTML.NBSP_ENTITY before start label text * [MYFACES-2446] - ExceptionHandlerImpl is not correct * [MYFACES-2448] - Wrappers created in 1.2 version should wrap new methods added in 2.0 * [MYFACES-2449] - ManagedBeanResolver and ScopedAttributeResolver could be called before UIViewRoot is available * [MYFACES-2451] - Add @JSFWebConfigParam annotation to new parameters in JSF 2.0 * [MYFACES-2454] - Adapt default error page generation to new spec * [MYFACES-2455] - ClientBehaviorHolder interface should be tracked by myfaces-builder-plugin metadata * [MYFACES-2456] - Interfaces should be tracked on myfaces builder plugin * [MYFACES-2459] - PreJsf2ExceptionHandlerImpl not correct * [MYFACES-2460] - Add Resource Headers and allow EL Expressions only on css files * [MYFACES-2465] - PreJsf2ExceptionHandlerFactory should create new instances of
Re: [vote] MyFaces Master pom v7
thanks for voting. We got fives votes, all +1 -Leonardo Uribe -Jakob Korherr -Bruno Aranda -Jan-Kees van Andel -Matthias Wessendorf I will publish the released master pom. -Matthias On Tue, Jan 26, 2010 at 9:52 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/1/26 Jakob Korherr jakob.korh...@gmail.com +1 Regards, Jakob 2010/1/26 Bruno Aranda brunoara...@gmail.com +1 2010/1/26 Matthias Wessendorf mat...@apache.org: we added a bunch of new committers; updated to Apache POM v7 -Matthias On Tue, Jan 26, 2010 at 5:38 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: No opinion on voting, I am just curious why the master is being released, what changed? -Andrew On Tue, Jan 26, 2010 at 7:10 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: +1 2010/1/26 Matthias Wessendorf mat...@apache.org: +1 On Tue, Jan 26, 2010 at 12:46 PM, Matthias Wessendorf mat...@apache.org wrote: This is the formal vote for the new myfaces master POM version 7. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom version 7 and think we can use it -1 if you found a flaw or potential problem with the new master pom Thanks, Matthias [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/7 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [vote] MyFaces Master pom v7
published the pom to: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/myfaces/myfaces/7/ -Matthias On Mon, Feb 1, 2010 at 9:43 PM, Matthias Wessendorf mat...@apache.org wrote: thanks for voting. We got fives votes, all +1 -Leonardo Uribe -Jakob Korherr -Bruno Aranda -Jan-Kees van Andel -Matthias Wessendorf I will publish the released master pom. -Matthias On Tue, Jan 26, 2010 at 9:52 PM, Leonardo Uribe lu4...@gmail.com wrote: +1 2010/1/26 Jakob Korherr jakob.korh...@gmail.com +1 Regards, Jakob 2010/1/26 Bruno Aranda brunoara...@gmail.com +1 2010/1/26 Matthias Wessendorf mat...@apache.org: we added a bunch of new committers; updated to Apache POM v7 -Matthias On Tue, Jan 26, 2010 at 5:38 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: No opinion on voting, I am just curious why the master is being released, what changed? -Andrew On Tue, Jan 26, 2010 at 7:10 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: +1 2010/1/26 Matthias Wessendorf mat...@apache.org: +1 On Tue, Jan 26, 2010 at 12:46 PM, Matthias Wessendorf mat...@apache.org wrote: This is the formal vote for the new myfaces master POM version 7. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom version 7 and think we can use it -1 if you found a flaw or potential problem with the new master pom Thanks, Matthias [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/7 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2504) Google App Engine Support
[ https://issues.apache.org/jira/browse/MYFACES-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828327#action_12828327 ] Leonardo Uribe commented on MYFACES-2504: - Checking the patch, I have seen a new init param to force myfaces to use jsp 2.0 initializer. My question is why don't create a param with other name that give a better idea about what the patch is doing (force jsp 2.0 initializer). In the patch there is nothing that is specific to Google App Engine, and it could be possible in the future getJspApplicationContext return a valid instance, so in terms of time the patch could be necessary only temporally. Google App Engine Support - Key: MYFACES-2504 URL: https://issues.apache.org/jira/browse/MYFACES-2504 Project: MyFaces Core Issue Type: Improvement Components: JSR-252, JSR-314 Affects Versions: 1.2.8, 2.0.0-alpha Environment: Google App Engine 1.3 Reporter: Ali Ok Priority: Minor Attachments: 2504-2.diff, 2504-3.diff, 2504-doc.diff, 2504.diff Support for Google App Engine for MyFaces 1.2 and 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ANNOUNCE: Introduction to Spring Faces Part 2
Hello, In this second article, Jeremy Grelle continues his exploration of Spring Faces with a sample application that demonstrates the Spring-centric integration approach. Here is an excerpt: The first article in this serieshttp://www.jsfcentral.com/articles/intro_spring_faces_1.htmlintroduced Spring Faces at a high, conceptual level. It examined how Spring Faces enables a Spring-centric approach to integration between JSF and Spring, allowing you to take advantage of the strengths of the JSF component model while retaining access to the full breadth of the de facto standard Spring programming model. It showed some of the advantages of assuming Spring Web Flow as the primary controller model for a JSF application, and began to examine the structure of the Spring Travel sample application that demonstrates the Spring-centric integration approach. In part 2, I'm going to pick up where we left off and dive into the code of the sample application to show how Spring Faces simplifies JSF development. Read the full article here: http://www.jsfcentral.com/articles/intro_spring_faces_2.html --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
ANNOUNCE: Daniel Hinojosa talks about Pitfalls and Testing with JBoss Seam
Hello, In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Daniel Hinojosa about testing JBoss Seam applications from the bottom up, and Seam pitfalls. This interview was recorded in September of 2008 at the JSF Summit, formerly called JSFOne, in Vienna, Virginia. Here is an excerpt: Kito: Okay. So I imagine there are probably at least two different approaches to using Seam-gen. One would be where you use Seam-gen once, create the scaffolding for the application, and then work normally off the top of it. Another option would be to use Seam-gen, then make some changes, regenerate, make some changes, regenerate, etc. Have you tried both methods before? Daniel: I have tried both and I ended up just – because it provides three basic folders for you: model, action, and test -- and I just use my id to create the classes out of there. Seam-gen offers your “create entity,” “create action,” and different kinds of things very much like Rails or Grails has. I have used those at first but then I ended up creating a new class, because from there I kind of know what I want. You can take different approaches with that. The value of that whole Seam-gen, I think, is in that whole build XML file. Read the full article here: http://www.jsfcentral.com/articles/hinojosa-01-10.html --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
[jira] Commented: (MYFACES-2489) Clean up the viewId calculation algorithm
[
https://issues.apache.org/jira/browse/MYFACES-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828388#action_12828388
]
Leonardo Uribe commented on MYFACES-2489:
-
This patch reveals different problems with the current implementation, and
apply it could lead to misunderstandings. Let's go by parts:
1. Change JspViewHandlerImpl is bad. Right now, myfaces has 3 ViewHandler
implementations:
org.apache.myfaces.application.jsp.JspViewHandlerImpl
org.apache.myfaces.view.facelets.FaceletViewHandler
org.apache.myfaces.application.ViewHandlerImpl
JspViewHandlerImpl and FaceletViewHandler are reference, and should not be
changed/removed if possible (in theory one user could use them). The one used
in jsf 2.0 is ViewHandlerImpl.
2. The spec section 7.6.2.1 ViewDeclarationLanguage.createView() says:
If no viewId could be identified, or the viewId is exactly equal to the
servlet mapping, send the response error
code SC_NOT_FOUND with a suitable message to the client
It seems there is something wrong here. ViewDeclarationLanguageBase calls
vdl.calculateViewId to check this condition, but looking in deep this is called
from ViewHandlerImpl.createView. Now look this code on
JspViewHandlerImpl.createView:
public UIViewRoot createView(FacesContext facesContext, String viewId)
{
String calculatedViewId = viewId;
try
{
calculatedViewId =
getViewHandlerSupport().calculateViewId(facesContext, viewId);
}
catch (InvalidViewIdException e)
{
sendSourceNotFound(facesContext, e.getMessage());
}
It seems an error on the spec. I think the intention is do this in
ViewHandlerImpl, because vdl.createView could be called from vdl.restoreView
and ViewHandlerImpl.restoreView converts it.
3. Just to keep in mind, DefaultRestoreViewSupport and
DefaultViewHandlerSupport are two complete different classes. Before refactor
them it is necessary to solve the previous point (maybe create another issue,
link it with this one, and solve that there). Do not remove
DefaultRestoreViewSupport or DefaultViewHandlerSupport, just mark them as
deprecated and add a note this class was replaced by.. One idea could be
add a new helper for RestoreViewExecutor and go back DefaultRestoreViewSupport
to jsf 1.2 form.
Clean up the viewId calculation algorithm
-
Key: MYFACES-2489
URL: https://issues.apache.org/jira/browse/MYFACES-2489
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-alpha-2
Reporter: Jakob Korherr
Attachments: MYFACES-2489-core.patch, MYFACES-2489-shared.patch,
myfaces-2489.patch
The whole viewId calculation process is a big mess. There is
DefaultRestoreViewSupport with calculateViewId and deriveViewId and there is
DefaultViewHandlerSupport with calculateViewId and calculateAndCheckViewId.
Furthermore each viewId gets calculated twice (e.g. first from test.jsf to
test.xhtml and then from test.xhtml to test.xhtml, which is not necessary).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1702) performance: decrease memory of FileSystemStyleCache by reusing CSSStyle objects.
performance: decrease memory of FileSystemStyleCache by reusing CSSStyle
objects.
-
Key: TRINIDAD-1702
URL: https://issues.apache.org/jira/browse/TRINIDAD-1702
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 1.2.13-core
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Attachments: CSSStyleKeyPatch12122.patch
Our performance team gave me the following statistics:
Objects:
Shallow HeapRetained
Heap
SkinStyleProvider13 723B
540M
FileSystemStyleCache$Entry 71 1704B536M
FileSystemStyleCache$StyleImpl 71 2272B533M
CSSStyle 315,431 7.5M
518M
The application they are testing has 13 skins, therefore there are 13
SkinStyleProvider objects.
Each css file has about 4500 selectors in this use case.
In FileSystemStyleCache's StyleImpl, we create a new CSSStyle object for every
selector, even though many of the selectors have the same css property
names/values. E.g., .af_inputText_xyz, .af_selectOneChoice_xyz,
.af_selectManyCheckbox_xyz {font-weight: bold; color: black}
To decrease the memory used, in StyleImpl we can reuse CSSStyle objects where
they have the same css property name and values. This small change saves 56% of
the memory used.
(Note: More memory should be saved in other ways, but this will be a different
JIRA issue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2483) Find a way to allow c:if work with partial state saving enabled
[ https://issues.apache.org/jira/browse/MYFACES-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-2483: - Just as a reference note, I moved and renamed the param org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS to MyfacesConfig class on shared. Playing a little with partial state saving algorithm, and re-reading the arguments about this problem, it was found that in most cases (c:if toogle) it is not necessary to restore the tree exactly like it was on the latest request, or in other words should remain stable between requests. The advantage is this is faster and state is smaller. Anyway, it is possible to find cases where the state should be preserved, so I'll introduce another param called org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE by default false. If this is set as true, parent components containing c:if, c:forEach, c:choose and ui:insert with src=ELExpression are marked to be restored fully. It is still pending how to prevent addition / removal of h:outputScript / h:outputStylesheet. Right now, on every request, duplicate instances of h:outputScript / h:outputStylesheet are silently removed by UIViewRoot.addComponentResource(FacesContext, UIComponent, String). Maybe we should try use an interface for tag handlers called RelocatableComponent and update ComponentTagHandlerDelegate to redirect ComponentSupport.findChildByTagId and try to found instances on UIViewRoot facets head and body, but resource instances are inmutable, in other words, there is no use case where a resource instance changes its inner state after added to the tree. Find a way to allow c:if work with partial state saving enabled --- Key: MYFACES-2483 URL: https://issues.apache.org/jira/browse/MYFACES-2483 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: fixPSSIf2009JAN-10.patch, fixPSSIf2009JAN-11.patch, fixPSSIf2009JAN-14.patch, fixPSSIf2009JAN-7.patch This one is difficult to solve but I still think it is possible. It was explored trying to solve MYFACES-2428, and it seems ri is trying to do something about it too on: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408 and https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313 One strategy to solve this one is this: 1. Mark the parent component containing c:if to not save it partially. 2. Do not execute c:if on postback and partial state saving enabled. In theory, the parent component should be restored fully from saved state. Note that things like: c:if pSome markup/p c:if is just invalid. It is expected that c:if only contains components with state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2483) Find a way to allow c:if work with partial state saving enabled
[ https://issues.apache.org/jira/browse/MYFACES-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2483. - Resolution: Fixed Find a way to allow c:if work with partial state saving enabled --- Key: MYFACES-2483 URL: https://issues.apache.org/jira/browse/MYFACES-2483 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: fixPSSIf2009JAN-10.patch, fixPSSIf2009JAN-11.patch, fixPSSIf2009JAN-14.patch, fixPSSIf2009JAN-7.patch This one is difficult to solve but I still think it is possible. It was explored trying to solve MYFACES-2428, and it seems ri is trying to do something about it too on: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408 and https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313 One strategy to solve this one is this: 1. Mark the parent component containing c:if to not save it partially. 2. Do not execute c:if on postback and partial state saving enabled. In theory, the parent component should be restored fully from saved state. Note that things like: c:if pSome markup/p c:if is just invalid. It is expected that c:if only contains components with state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
