Re: [VOTE] Release Tobago 1.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 Regards, Udo Am 27.02.12 06:25, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.5.4. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12319864 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-085/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPS0m+AAoJEAEbRra2zTKA/6EP/1Y8QpHtkuZGsB/Ol1gsn1T+ gh5zw5x2BmCx6ITqFhb0T5mlCHDbrHpWIoWkEsbx3QExGQPo9/80jNzZfVs03kvU Ijf5kOLP+VJVESJWYvKxo7T4twph+tl6Mq1TMY/11IjdGwjFQC9vYRXOO+Q7VHbx N7KBmOBaIzmyRMBLryiO/vOHmvx5TOVFlyoyCQZsd4o7IRo0wsiuvl7pAyWv+pnn Ksm/FyDTYOQ8Q1IcNP8Rq+ECTym4dFkDsIDXk38f5rZbkDW62u+blmLtsooAhqxt CwnvZ5v0imCG+L6+7h1tA0BjwZvJB7kYfHWdUBc9Yw9zSv8NiWq5Oa6QCVC2xahp wKltCCBzXGxBIwlNBWGFhxtPUoDhgfxkTS26KSbrZEqg14pZNQ5qYMHQ4qp56D1Y dGyCec+sohOQTl2TbCoCnkk33SFNKZLUQnjJcodwRU8s52uEuxJHQAfh54HvsrPc +PtMXNlwNymSKJaQ7uOLXSi6/dtXVyxQU4sJ+I8Jg8sqZH6r5/9Rg9KAz/I+BY9T a9xR5k2ztQGnJ6PGIA2YI0rnkS++U3RUdOkVhmjO7wgkjK5G+WLrjuwKSffAazz4 yNvFQWMGe6cC1gZEMFepgsgf3Jef1fT2nZuauasWNa7pYzachfS8cLLM0XHZQEBs TQOecjnK03o2i6lWnneR =PKl9 -END PGP SIGNATURE-
[jira] [Created] (MYFACES-3482) jsf.js: jsr-344 getWindowId preparations, minor code cleanup
jsf.js: jsr-344 getWindowId preparations, minor code cleanup Key: MYFACES-3482 URL: https://issues.apache.org/jira/browse/MYFACES-3482 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.1.6, 2.0.12 Reporter: Werner Punz Priority: Minor As preparation for jsf 2.2 we need a get windowid function in jsf.js. Since the windowid is developed under the apache myfaces umbrella we are going to do the initial commits here for this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3482) jsf.js: jsr-344 getWindowId preparations, minor code cleanup
[ https://issues.apache.org/jira/browse/MYFACES-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3482. -- Resolution: Fixed Fix Version/s: 2.1.7-SNAPSHOT 2.0.13-SNAPSHOT jsf.js: jsr-344 getWindowId preparations, minor code cleanup Key: MYFACES-3482 URL: https://issues.apache.org/jira/browse/MYFACES-3482 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.0.12, 2.1.6 Reporter: Werner Punz Priority: Minor Fix For: 2.0.13-SNAPSHOT, 2.1.7-SNAPSHOT As preparation for jsf 2.2 we need a get windowid function in jsf.js. Since the windowid is developed under the apache myfaces umbrella we are going to do the initial commits here for this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tobago 1.5.4
Hi, +1 Regards, Volker Am 27. Februar 2012 10:15 schrieb Udo Schnurpfeil u...@schnurpfeil.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 Regards, Udo Am 27.02.12 06:25, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.5.4. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12319864 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-085/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPS0m+AAoJEAEbRra2zTKA/6EP/1Y8QpHtkuZGsB/Ol1gsn1T+ gh5zw5x2BmCx6ITqFhb0T5mlCHDbrHpWIoWkEsbx3QExGQPo9/80jNzZfVs03kvU Ijf5kOLP+VJVESJWYvKxo7T4twph+tl6Mq1TMY/11IjdGwjFQC9vYRXOO+Q7VHbx N7KBmOBaIzmyRMBLryiO/vOHmvx5TOVFlyoyCQZsd4o7IRo0wsiuvl7pAyWv+pnn Ksm/FyDTYOQ8Q1IcNP8Rq+ECTym4dFkDsIDXk38f5rZbkDW62u+blmLtsooAhqxt CwnvZ5v0imCG+L6+7h1tA0BjwZvJB7kYfHWdUBc9Yw9zSv8NiWq5Oa6QCVC2xahp wKltCCBzXGxBIwlNBWGFhxtPUoDhgfxkTS26KSbrZEqg14pZNQ5qYMHQ4qp56D1Y dGyCec+sohOQTl2TbCoCnkk33SFNKZLUQnjJcodwRU8s52uEuxJHQAfh54HvsrPc +PtMXNlwNymSKJaQ7uOLXSi6/dtXVyxQU4sJ+I8Jg8sqZH6r5/9Rg9KAz/I+BY9T a9xR5k2ztQGnJ6PGIA2YI0rnkS++U3RUdOkVhmjO7wgkjK5G+WLrjuwKSffAazz4 yNvFQWMGe6cC1gZEMFepgsgf3Jef1fT2nZuauasWNa7pYzachfS8cLLM0XHZQEBs TQOecjnK03o2i6lWnneR =PKl9 -END PGP SIGNATURE- -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
Re: [jira] [Updated] (TRINIDAD-2226) Provide mechanism to reload skin definitions from trinidad-skins.xml
Can one of the developers please commit my patches on the two branches if found
okay ?.
Thanks,
Prakash
On 2/26/2012 12:21 AM, Prakash Udupa (Updated) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prakash Udupa updated TRINIDAD-2226:
Status: Patch Available (was: Open)
Provide mechanism to reload skin definitions from trinidad-skins.xml
Key: TRINIDAD-2226
URL: https://issues.apache.org/jira/browse/TRINIDAD-2226
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
Attachments: JIRA_2226_Patch_over_1_2_12_6_2_branch.patch,
JIRA_2226_Patch_over_trunk.patch
Original Estimate: 48h
Remaining Estimate: 48h
Currently there is no way to be able to update the skins to an app at runtime
without needing to restart the app. Request here is to provide it in Trinidad's
skinning framework.
Requirement: Provide an API that complies to the following:
-
1. Reads (or marks it dirty so that it is read in next request)
trinidad-skins.xml and update the new skin definitions as per its contents
2. Subsequent requests on the webapp should reflect the skin definitions from
trinidad-skins.xml that was re-read
3. Should be statically called (because the clients of such API are usually
deployment tools that work outside of JSF lifecycle)
4. Cannot depend on any context object other than ServletContext (because that
is what a non-JSF entry point to this API can provide)
Proposed API:
-
1. New public non-static method in
'org.apache.myfaces.trinidad.skin.SkinFactory'
/**
* Reloads the skins that was registered with this factory.
* Subclassers are expected to provide the implementation.
*/
public void reload()
- We implement this in
'org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl'. In this
implementation we will preserve the order in which we register skins, which is
the following:
a) Register the base skins in Trinidad
b) Give chance to all registered Configurator services to attach their
skins to the SkinFactory programatically.
c) Read trinidad-skins.xml from META-INF and WEB-INF, and for the skin
definitions in there, create Skins and register with the SkinFactory
- Clients will call 'SkinFactory.getFactory().reload();' after updating the
trinidad-skins.xml to be able to reload the skins in the next request to the
app (browser cache clearance / Ctrl+F5 is of course needed).
2. New public method in 'org.apache.myfaces.trinidad.config.Configurator'
/**
* The skinning framework calls this method to notify Configurators that the
specified SkinFactory has been reloaded.
* The Configurator implementations may choose to reload skins here.
* @param externalContext the external context
* @param factory the SkinFactory instance to which the skins can be reloaded
*/
public void reloadSkins(ExternalContext externalContext, SkinFactory
factory){}
- This method will be no-op in the Configurator class, and can optionally be
implemented by any registered configurator services.
- The reload() method noted in #1 above will call this method on all registered
configurator services before attempting to register the skins from
trinidad-skins.xml that it will re-read now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Trinidad 2.0.1 (try 2)
+1 On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan blake.sulli...@oracle.comwrote: +1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: +1. Thanks for putting this together Scott. Andy On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase **IS** available by building the source manually. The last vote was vetoed because some files were missing licenses and there were some references to external repositories. The new staging repositories contain fixes for all of these issues including an enhancement to the base POM file which will automatically run the rat verifications at build to prevent the licensing issues in the future. At this time, I would like to ask for a vote, once again, on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ https://repository.apache.org/content/repositories/orgapachemyfaces-067 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/
Re: [VOTE] Trinidad 2.0.1 (try 2)
+1 On Mon, Feb 27, 2012 at 8:18 AM, Matt Cooper mcoo...@apache.org wrote: +1 On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan blake.sulli...@oracle.com wrote: +1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: +1. Thanks for putting this together Scott. Andy On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase **IS** available by building the source manually. The last vote was vetoed because some files were missing licenses and there were some references to external repositories. The new staging repositories contain fixes for all of these issues including an enhancement to the base POM file which will automatically run the rat verifications at build to prevent the licensing issues in the future. At this time, I would like to ask for a vote, once again, on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ https://repository.apache.org/content/repositories/orgapachemyfaces-067 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Results (was: [VOTE] Trinidad 2.0.1 (try 2))
Thank you all for voting and helping to get out this release. results: 5 binding +1 votes (pmc): - Scott O'Bryan - Mark Struberg - Werner Punz - Matt Cooper - Grant Smith 2 non-binding +1 votes (community): - Andy Schwartz - Blake Sullivan Regards, Scott O'Bryan On 02/27/2012 09:22 AM, Grant Smith wrote: +1 On Mon, Feb 27, 2012 at 8:18 AM, Matt Cooper mcoo...@apache.org mailto:mcoo...@apache.org wrote: +1 On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan blake.sulli...@oracle.com mailto:blake.sulli...@oracle.com wrote: +1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: +1. Thanks for putting this together Scott. Andy On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com mailto:darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase **IS** available by building the source manually. The last vote was vetoed because some files were missing licenses and there were some references to external repositories. The new staging repositories contain fixes for all of these issues including an enhancement to the base POM file which will automatically run the rat verifications at build to prevent the licensing issues in the future. At this time, I would like to ask for a vote, once again, on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-067 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Created] (TRINIDAD-2227) Faces keep showing WARN unhandled FacesMessage, besides tr:messages already rendered them.
Faces keep showing WARN unhandled FacesMessage, besides tr:messages already
rendered them.
--
Key: TRINIDAD-2227
URL: https://issues.apache.org/jira/browse/TRINIDAD-2227
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components, Facelets
Affects Versions: 2.0.0-core
Environment: Linux Fedora 15, MySQL 5.x, Apache Geronimo 3.0-Beta-1,
MyFaces 2.0.9, Trinidad 2.0.0, Using Facelets
Reporter: Eduardo Garcia
Every time the ManagedBean perform an action such as save, update, delete a row
in database, a message is created by using a method inside a static class:
public class FacesUtil {
//...some more stuff here
public static void setMessage(String clientid, String message){
FacesContext context = FacesContext.getCurrentInstance();
FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_INFO,
Info., message);
context.addMessage(clientid, msg);
context.renderResponse();
}
}
And the message is created on ManagedBean this way:
public void doDelete(ActionEvent event) {
String message = ;
//some method relevants actions here
message = Record has been deleted;
FacesUtil.setMessage(null,message);
}
The message is rendered as expected, but MyFaces for some reason, doesn't
notice that, and throws a warning message to console:
2012-02-27 11:02:14,398 WARN [RenderResponseExecutor] There are some unhandled
FacesMessages, this means not every FacesMessage had a chance to be rendered.
These unhandled FacesMessages are:
- Record has been deleted successfully
Thanks in advance,
Eduardo
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Trinidad 2.0.1
+1 On Fri, Feb 24, 2012 at 8:17 AM, Mark Struberg strub...@yahoo.de wrote: Hi Scott! While checking the release I also scanned the other stuff and the rest looks good. sorry for the inconvenience... LieGrue, strub - Original Message - From: Scott O'Bryan darkar...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Friday, February 24, 2012 3:49 PM Subject: Re: [VOTE] Release of Trinidad 2.0.1 I stand corrected, it IS in there. :D We've had those repos in there forever. Anyway, thanks Mark. So I've checked in the changes you requested to the latest tag and set up the rat audit tool to run as part of the standard build so we don't hit this issue again. Can you do me a favor and check the tag to make sure it looks good and then I'll promote it to the repository and start over the vote. Thanks, Scott On Fri 24 Feb 2012 06:56:50 AM MST, Scott O'Bryan wrote: I'm not sure I agree with this. In the case of java.net, removing the invalid repo is a fair assessment, but I'm unaware of any rules in maven-central that says build artifacts cannot be pulled in from other repositories. Am I missing something here? That said, I didn't have time yesterday to investigate the problem. It might just be a simple Geronimo dep issue. I have a few mins to look at this. Hopefully it's not a difficult problem. Sent from my iPhone On Feb 24, 2012, at 6:33 AM, Mark Strubergstrub...@yahoo.de wrote: Hi Scott! As for the repositories, I removed them and now seem to be getting an error during testing. Well, doesn't that mean that the source repository doesn't properly build? Also, such artifacts should not get propagated to maven.central as per it's policies. If you need help with the repo stuff then please ping me on IRC and I'll help. LieGrue, strub - Original Message - From: Scott O'Bryandarkar...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org Cc: Sent: Friday, February 24, 2012 2:07 PM Subject: Re: [VOTE] Release of Trinidad 2.0.1 Okay Marc, I fixed rat and the few license headers we have. It will now also run automagically as part of the Trinidad build so we can catch these sooner. As for the repositories, I removed them and now seem to be getting an error during testing. I guess my question is this, since we don't distribute any jboss code with the product, is the repository issue still a blocker or can it be handled as a bug next release? Scott Sent from my iPhone On Feb 23, 2012, at 7:07 AM, Mark Strubergstrub...@yahoo.de wrote: Hi! I'm really sorry, but I fear I have to cast a -1 :( A few smallish but imo important things which I found during the review: 1.) repositories !-- needed for Bean Validation API -- repository idjboss/id namejboss nexus/name urlhttp://repository.jboss.org/nexus/content/groups/public-jboss//url /repository !-- Needed for Mojarra -- repository idmaven2-repository.dev.java.net/id nameJava.net Repository for Maven/name urlhttp://download.java.net/maven/2//url /repository /repositories is this really needed? please the geronimo-spec jar for JSR-303 and Apache BVal instead. the java.net repo is btw dead already... All mojarra artifacts are available on maven.central Artifacts with a dead repo in it should definitely not get propagated to maven.central! 2.) please run mvn apache-rat:check The following files misses an ALv2 header: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/Global.xml trinidad-api/src/main/conf/META-INF/myfaces-core-2_0-metadata.xml trinidad-impl/src/test/resources/org/apache/myfaces/trinidadinternal/renderkit/testScripts/ contains a lot of stuff, but this should get excluded as they are only test resources. Please add the apache-rat plugin to the build and fix the missing headers or tweak the excludes until the build runs fine. LieGrue, strub - Original Message - From: Andy Schwartzandy.g.schwa...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org Cc: Sent: Thursday, February 23, 2012 1:31 PM Subject: Re: [VOTE] Release of Trinidad 2.0.1 +1 Andy On Feb 22, 2012, at 12:18 AM, Scott O'Bryan darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example
Re: [VOTE] Trinidad 2.0.1 (try 2)
+1 On Mon, Feb 27, 2012 at 9:22 AM, Grant Smith work.gr...@gmail.com wrote: +1 On Mon, Feb 27, 2012 at 8:18 AM, Matt Cooper mcoo...@apache.org wrote: +1 On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan blake.sulli...@oracle.com wrote: +1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: +1. Thanks for putting this together Scott. Andy On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase *IS* available by building the source manually. The last vote was vetoed because some files were missing licenses and there were some references to external repositories. The new staging repositories contain fixes for all of these issues including an enhancement to the base POM file which will automatically run the rat verifications at build to prevent the licensing issues in the future. At this time, I would like to ask for a vote, once again, on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-067 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[ANNOUNCE] Release of Apache MyFaces Trinidad 2.0.1
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Trinidad 2.0.1. This is a very important release with a lot of bug fixes and improvements and we invite you to try it out. Apache MyFaces Trinidad is available in both binary and source distributions and there are examples available as well: http://myfaces.apache.org/trinidad/download.html Apache MyFaces Trinidad is available in the central Maven repository under Group ID org.apache.myfaces.trinidad ReleaseNotes: http://s.apache.org/6Am Enjoy! Scott O'Bryan
[jira] [Commented] (MYFACES-3481) [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time
[ https://issues.apache.org/jira/browse/MYFACES-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217487#comment-13217487 ] Martin Kočí commented on MYFACES-3481: -- I see same results as reported with current trunk. The change in javax.faces.view.facelets.ValidatorHandler.getTagHandlerDelegate() is deployed and return the cached instance. Reproducible with: f:validateBean h:outputLabelmyfaces/h:outputLabel /f:validateBean FactoryFinder._getFactory(String) line: 267 FactoryFinder.getFactory(String) line: 206 HtmlComponentHandler(DelegatingMetaTagHandler).init(TagConfig) line: 42 HtmlComponentHandler(ComponentHandler).init(ComponentConfig) line: 37 HtmlComponentHandler.init(ComponentConfig) line: 37 GeneratedConstructorAccessor18.newInstance(Object[]) line: not available DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserComponentHandlerFactory.createHandler(TagConfig) line: 519 HtmlLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 TagUnit.getNextHandler() line: 61 AbstractTagLibrary$ValidatorConfigWrapper.getNextHandler() line: 317 ValidatorTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 152 ValidatorHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time - Key: MYFACES-3481 URL: https://issues.apache.org/jira/browse/MYFACES-3481 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 myfaces in Production stage: f:validateBean h:outputLabelmyfaces/h:outputLabel /f:validateBean (or book.xhtml in myfaces-jpa test app) In every request/response, this invocation appears: MetaRulesetImpl.init(Tag, Class?) line: 118 ComponentTagHandlerDelegate.createMetaRuleset(Class) line: 459 HtmlComponentHandler(DelegatingMetaTagHandler).createMetaRuleset(Class) line: 102 HtmlComponentHandler.createMetaRuleset(Class) line: 42 HtmlComponentHandler(MetaTagHandler).setAttributes(FaceletContext, Object) line: 63 HtmlComponentHandler(DelegatingMetaTagHandler).setAttributes(FaceletContext, Object) line: 93 ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 235 HtmlComponentHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 ValidatorTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 152 ValidatorHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 this applies for all children of f:validateBean Without f:validateBean Metatag rules are created only once in production stage during initial request to facelet. (Not sure if it is a bug - maybe something special needs to be done for f:beanValidator ) It also leads to stack bellow - but _getFactory method is synchronized and slow down response times to the same facelet: FactoryFinder._getFactory(String) line: 259 FactoryFinder.getFactory(String) line: 206 ConvertNumberHandler(DelegatingMetaTagHandler).init(TagConfig) line: 42 ConvertNumberHandler(FaceletsAttachedObjectHandler).init(TagConfig) line: 42 ConvertNumberHandler(ConverterHandler).init(ConverterConfig) line: 44 ConvertNumberHandler.init(ConverterConfig) line: 57 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserConverterHandlerFactory.createHandler(TagConfig) line: 593 CoreLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 TagUnit.getNextHandler() line: 61 AbstractTagLibrary$ComponentConfigWrapper.getNextHandler() line: 431 HtmlComponentHandler(TagHandler).init(TagConfig) line: 39
[jira] [Commented] (MYFACES-3481) [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time
[ https://issues.apache.org/jira/browse/MYFACES-3481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217564#comment-13217564 ] Leonardo Uribe commented on MYFACES-3481: - I see. This is different to the previous one fixed, and is caused by this call. _delegate.getValidatorConfig().getNextHandler().apply(ctx, parent); Tracking down this problem, it came from MYFACES-2512. In that time, we tried to implement the disabled logic into ValidatorTagHandlerDelegate, but after some tests cycles, we found that the right thing to do is move that logic into ComponentTagHandlerDelegate. Later, to solve validationGroups problem, another strategy was implemented, so we commented the old code, but this line was let without change. The solution is just use: _delegate.applyNextHandler(ctx, parent); Instead. The problem described on MYFACES-2512 will not happen, because all that code was changed in MYFACES-3259 with a better alternative. [perf] f:validateBean re-creates facelets handlers (MetaRulesetImpl,DelegatingMetaTagHandler ...) for children every time - Key: MYFACES-3481 URL: https://issues.apache.org/jira/browse/MYFACES-3481 Project: MyFaces Core Issue Type: Improvement Reporter: Martin Kočí Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 myfaces in Production stage: f:validateBean h:outputLabelmyfaces/h:outputLabel /f:validateBean (or book.xhtml in myfaces-jpa test app) In every request/response, this invocation appears: MetaRulesetImpl.init(Tag, Class?) line: 118 ComponentTagHandlerDelegate.createMetaRuleset(Class) line: 459 HtmlComponentHandler(DelegatingMetaTagHandler).createMetaRuleset(Class) line: 102 HtmlComponentHandler.createMetaRuleset(Class) line: 42 HtmlComponentHandler(MetaTagHandler).setAttributes(FaceletContext, Object) line: 63 HtmlComponentHandler(DelegatingMetaTagHandler).setAttributes(FaceletContext, Object) line: 93 ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 235 HtmlComponentHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 ValidatorTagHandlerDelegate.apply(FaceletContext, UIComponent) line: 152 ValidatorHandler(DelegatingMetaTagHandler).apply(FaceletContext, UIComponent) line: 53 this applies for all children of f:validateBean Without f:validateBean Metatag rules are created only once in production stage during initial request to facelet. (Not sure if it is a bug - maybe something special needs to be done for f:beanValidator ) It also leads to stack bellow - but _getFactory method is synchronized and slow down response times to the same facelet: FactoryFinder._getFactory(String) line: 259 FactoryFinder.getFactory(String) line: 206 ConvertNumberHandler(DelegatingMetaTagHandler).init(TagConfig) line: 42 ConvertNumberHandler(FaceletsAttachedObjectHandler).init(TagConfig) line: 42 ConvertNumberHandler(ConverterHandler).init(ConverterConfig) line: 44 ConvertNumberHandler.init(ConverterConfig) line: 57 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserConverterHandlerFactory.createHandler(TagConfig) line: 593 CoreLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String, String, TagConfig) line: 93 TagUnit.createFaceletHandler() line: 56 TextUnit.createFaceletHandler() line: 104 TagUnit(CompilationUnit).getNextFaceletHandler() line: 82 TagUnit.getNextHandler() line: 61 AbstractTagLibrary$ComponentConfigWrapper.getNextHandler() line: 431 HtmlComponentHandler(TagHandler).init(TagConfig) line: 39 HtmlComponentHandler(MetaTagHandler).init(TagConfig) line: 35 HtmlComponentHandler(DelegatingMetaTagHandler).init(TagConfig) line: 40 HtmlComponentHandler(ComponentHandler).init(ComponentConfig) line: 37 HtmlComponentHandler.init(ComponentConfig) line: 37 GeneratedConstructorAccessor17.newInstance(Object[]) line: not available DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 ConstructorT.newInstance(Object...) line: 513 AbstractTagLibrary$UserComponentHandlerFactory.createHandler(TagConfig) line: 519 HtmlLibrary(AbstractTagLibrary).createTagHandler(String, String, TagConfig) line: 98 CompositeTagLibrary.createTagHandler(String,
[jira] [Commented] (MYFACES-3459) RegexValidator does not provide label and pattern for first usage of RegexValidator.NOT_MATCHED
[
https://issues.apache.org/jira/browse/MYFACES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217568#comment-13217568
]
Leonardo Uribe commented on MYFACES-3459:
-
Of course, I have already committed it. Thanks for your help and for remind me
that.
RegexValidator does not provide label and pattern for first usage of
RegexValidator.NOT_MATCHED
---
Key: MYFACES-3459
URL: https://issues.apache.org/jira/browse/MYFACES-3459
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.5
Environment: myfaces trunk
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Trivial
Attachments: MYFACES-3459.patch, myfaces-1244836.patch
RegexValidator uses javax.faces.validator.RegexValidator.NOT_MATCHED 2x:
javax.faces.validator.RegexValidator.NOT_MATCHED= the passed value is not a
String, or when the pattern does not match the passed value.
the first usage for if (value instanceof String) check does not provide
args for {0} {1} in message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3483) @PostConstruct not called when annotated on
@PostConstruct not called when annotated on Key: MYFACES-3483 URL: https://issues.apache.org/jira/browse/MYFACES-3483 Project: MyFaces Core Issue Type: Bug Reporter: Andrzej Hołyst -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
