Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)
+1 I have had similar situations and people definitely need a fix this has higher priority than having no new config params. Werner Am 27.11.12 16:56, schrieb Leonardo Uribe: +1, if there are people with interest to get a problem solved, it's worth a shot to hear what people says and get it done. 2012/11/27 Leonardo Uribe lu4...@gmail.com: Hi Some time ago, it was mentioned the controversy behind a fix for MYFACES-3586 http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results Maybe we should reconsider the previous position about this one and try to fix it, even if that means to include additional web config params, even if exists better solutions for this one or even if suppose more work to do. The reason why we should change our position is users start to fall on the same hole over and over again. Given the interest on the problem, it starts to sound better to provide an alternate fix bundled in myfaces core instead say to the people ... setup a load balancer in front of your server and cache the resources there to fix your problem Things become a ridiculousness, when you find a similar problem: https://issues.apache.org/jira/browse/MYFACES-3656 ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true Both problems are similar because: 1. Both problems has a known solution. 2. The solution is not perfect / cannot be enabled by default / there are better alternatives 3. The typical answer is say ... woops ... try this alternative strategy and try to live with the problem ... Given the latest feedback about MYFACES-3586 and MYFACES-3656, I think it is desirable to take a look and revote a solution to this problem again. Please vote: +1 if you consider we need to fix this one once for all. +0 if you don't care about -1 if you consider do nothing is better and why Note we need minimum 3 +1 votes to support this initiative and override the previous decision of the community. regards, Leonardo Uribe
Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)
The only _real_ solution is to not use the JSF specced resource handling and
instead only use RESTful URLs.
Since JSF resources may contain EL expressions, they are _not_ cacheable. We
currently deliver them with a expiry of 14 days, but this is actually wrong!
The RI has the same bug, so it's at least broken in the same way ;)
To shed more light on the topic you should also quote the original thread about
Jakobs RelativeResourceHandler.
http://markmail.org/thread/glr356g45uta5yys
This contains all the really important discussions.
Jakob continued his project over at google code [1]
Fazit:
* We must NOT cache for JSF spec compliant resource handling because the EL
inside CSS, etc can change for _every_ request.
* If we like to have a fully cacheable solution, then we should finally go a
step back and again remove all the superfluous stuff added to
commons-resourcehandler and do it cleanly.
We might scan the resources for '#{' but that might become expensive as well.
There was some proposal for JSF-2.2, do you have an update what happened with
that?
LieGrue,
strub
[1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/
- Original Message -
From: Werner Punz werner.p...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Wednesday, November 28, 2012 9:39 AM
Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in
jar files served by ResourceHandlerImpl)
+1
I have had similar situations and people definitely need a fix this has
higher priority than having no new config params.
Werner
Am 27.11.12 16:56, schrieb Leonardo Uribe:
+1, if there are people with interest to get a problem solved,
it's worth a shot to hear what people says and get it done.
2012/11/27 Leonardo Uribe lu4...@gmail.com:
Hi
Some time ago, it was mentioned the controversy behind a fix
for MYFACES-3586
http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results
Maybe we should reconsider the previous position about this
one and try to fix it, even if that means to include additional web
config params, even if exists better solutions for this one or
even if suppose more work to do.
The reason why we should change our position is users start to
fall on the same hole over and over again. Given the interest on
the problem, it starts to sound better to provide an alternate fix
bundled in myfaces core instead say to the people ... setup a
load balancer in front of your server and cache the resources
there to fix your problem
Things become a ridiculousness, when you find a similar problem:
https://issues.apache.org/jira/browse/MYFACES-3656
ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
Both problems are similar because:
1. Both problems has a known solution.
2. The solution is not perfect / cannot be enabled by default / there
are
better alternatives
3. The typical answer is say ... woops ... try this alternative
strategy and
try to live with the problem ...
Given the latest feedback about MYFACES-3586 and MYFACES-3656,
I think it is desirable to take a look and revote a solution to this
problem
again.
Please vote:
+1 if you consider we need to fix this one once for all.
+0 if you don't care about
-1 if you consider do nothing is better and why
Note we need minimum 3 +1 votes to support this initiative and override
the previous decision of the community.
regards,
Leonardo Uribe
[jira] [Created] (MYFACES-3657) 2.2 branch: checkstyle violation prevents compile
Werner Punz created MYFACES-3657: Summary: 2.2 branch: checkstyle violation prevents compile Key: MYFACES-3657 URL: https://issues.apache.org/jira/browse/MYFACES-3657 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.0 Reporter: Werner Punz Priority: Minor We have a checkstyle violation in our 2.2 branch impl, this needs to be fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3657) 2.2 branch: checkstyle violation prevents compile
[ https://issues.apache.org/jira/browse/MYFACES-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3657. -- Resolution: Fixed Fix Version/s: 2.2.0 2.2 branch: checkstyle violation prevents compile - Key: MYFACES-3657 URL: https://issues.apache.org/jira/browse/MYFACES-3657 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.0 Reporter: Werner Punz Priority: Minor Fix For: 2.2.0 We have a checkstyle violation in our 2.2 branch impl, this needs to be fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)
Hi
This vote is only for fix the performance problem over the
default ResourceHandlerImpl bundled in MyFaces Core. The
idea is create a temporal folder and uncompress the resources
there. Also, adopt the idea of use a soft reference map to avoid
read the file, but that memory cache needs some rules.
In theory, nothing has happened in JSF 2.2, but Jakob, should
know that better than me (I don't see any changes on the spec
for this part).
I know there are more problems and tha a full solution for
ResourceHandler stuff is use only RESTful URLs, but that's for
another discussion. We need a proposal and check point by point
what to do, but that's for another discussion. If you want to start
the discussion, please do it but in another mail, because it is a
different topic.
EL expressions inside css files are considered application-scoped,
which means once evaluated they never change. It is not a problem
for the cache here. The solution proposed is feasible, but it cannot
be enabled by default.
Please vote +1, +0 or -1 over provide a fix for MYFACES-3586 inside
MyFaces Core.
regards,
Leonardo Uribe
2012/11/28 Mark Struberg strub...@yahoo.de:
The only _real_ solution is to not use the JSF specced resource handling and
instead only use RESTful URLs.
Since JSF resources may contain EL expressions, they are _not_ cacheable. We
currently deliver them with a expiry of 14 days, but this is actually wrong!
The RI has the same bug, so it's at least broken in the same way ;)
To shed more light on the topic you should also quote the original thread
about Jakobs RelativeResourceHandler.
http://markmail.org/thread/glr356g45uta5yys
This contains all the really important discussions.
Jakob continued his project over at google code [1]
Fazit:
* We must NOT cache for JSF spec compliant resource handling because the EL
inside CSS, etc can change for _every_ request.
* If we like to have a fully cacheable solution, then we should finally go a
step back and again remove all the superfluous stuff added to
commons-resourcehandler and do it cleanly.
We might scan the resources for '#{' but that might become expensive as well.
There was some proposal for JSF-2.2, do you have an update what happened with
that?
LieGrue,
strub
[1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/
- Original Message -
From: Werner Punz werner.p...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Wednesday, November 28, 2012 9:39 AM
Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in
jar files served by ResourceHandlerImpl)
+1
I have had similar situations and people definitely need a fix this has
higher priority than having no new config params.
Werner
Am 27.11.12 16:56, schrieb Leonardo Uribe:
+1, if there are people with interest to get a problem solved,
it's worth a shot to hear what people says and get it done.
2012/11/27 Leonardo Uribe lu4...@gmail.com:
Hi
Some time ago, it was mentioned the controversy behind a fix
for MYFACES-3586
http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results
Maybe we should reconsider the previous position about this
one and try to fix it, even if that means to include additional web
config params, even if exists better solutions for this one or
even if suppose more work to do.
The reason why we should change our position is users start to
fall on the same hole over and over again. Given the interest on
the problem, it starts to sound better to provide an alternate fix
bundled in myfaces core instead say to the people ... setup a
load balancer in front of your server and cache the resources
there to fix your problem
Things become a ridiculousness, when you find a similar problem:
https://issues.apache.org/jira/browse/MYFACES-3656
ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
Both problems are similar because:
1. Both problems has a known solution.
2. The solution is not perfect / cannot be enabled by default / there
are
better alternatives
3. The typical answer is say ... woops ... try this alternative
strategy and
try to live with the problem ...
Given the latest feedback about MYFACES-3586 and MYFACES-3656,
I think it is desirable to take a look and revote a solution to this
problem
again.
Please vote:
+1 if you consider we need to fix this one once for all.
+0 if you don't care about
-1 if you consider do nothing is better and why
Note we need minimum 3 +1 votes to support this initiative and override
the previous decision of the community.
regards,
Leonardo Uribe
[ANNOUNCE] Knee Deep in IT: Project Experiences with JSF 2.0, Javascript
Hello everyone, I'm pleased to announce a new article on JSFCentral.com about how a team at Sandia National Laboratories became highly productive using JSF to implement a complex UX design with minimal need for custom Javascript. This article walks through release cycles that transitioned a team to JSF from straight Javascript. Read the full article here: http://www.jsfcentral.com/articles/kneee_deep_in_it.html ___ Kito D. Mann | @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 | @jsfcentral +1 203-404-4848 x246 * Listen to the latest headlines in the JSF and Java EE newscast: * http://blogs.jsfcentral.com/JSFNewscast/* * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: Documentation
Hi
Yes, it is something like that, but it requires some extra details
1. Define a local server to do the site:stage-deploy using scp (note
the change in the pom.xml related to myfaces-local-staging)
server
idmyfaces-local-staging/id
usernamemylocaluser/username
passwordmylocalpwd/password
/server
2. The idea is use two folders (/myfaces-site/checkout and
/myfaces-site/site), and do a hard copy from site to checkout before
commit the content under checkout folder.
The idea is write a guide and do the necessary changes in all pom.xml files.
I have deployed the site for the release, but it seems something is
still not working well for svnpubsub, so I reopened the issue on
INFRA.
regards,
Leonardo Uribe
2012/11/27, Grant Smith grantsm...@apache.org:
Leo,
OK, I'll wait for you to finish the release process before I try to make
any documentation changes. If I understand you correctly, once you make the
above changes, all I need to do to build the docs and deploy them are:
1. mvn site:stage-deploy (in EACH of the modules)
2. svn commit
Is that correct ?
Thanks,
-Grant.
On Tue, Nov 27, 2012 at 7:18 AM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
This is the provisional changes done in site pom.xml to deploy the
site. I have locally two folders:
/home/lu4242/myfaces-site/checkout
/home/lu4242/myfaces-site/site
The idea is do the changes in myfaces-site/site and then do a manual
copy/commit for checkout.
regards,
Leonardo
Index: .
===
--- . (revision 1401760)
+++ . (working copy)
@@ -34,23 +34,54 @@
descriptionThis is the MyFaces Site/description
urlhttp://myfaces.apache.org/url
+ properties
+
site.mainDirectory${user.home}/myfaces-site/checkout/site.mainDirectory
+siteContent.path${user.home}/myfaces-site/site/siteContent.path
+!-- it's a default location for performance reason (not checkout
the content all the time)
+ you can override this value in your settings. --
+scmCheckout.path\${site.mainDirectory}/scmCheckout.path
+
siteDeploy.urlfile://${user.home}/myfaces-site/site/siteDeploy.url
+ /properties
+
build
defaultGoalsite/defaultGoal
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-ssh-external/artifactId
-version1.0-beta-7/version
+version2.2/version
/extension
/extensions
pluginManagement
plugins
plugin
artifactIdmaven-site-plugin/artifactId
-version3.0/version
+version3.1/version
/plugin
/plugins
/pluginManagement
+plugins
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-scm-publish-plugin/artifactId
+version1.0-beta-1/version
+configuration
+ pubScmUrlscm:svn:
https://svn.apache.org/repos/asf/myfaces/site/publish//pubScmUrl
+ tryUpdatetrue/tryUpdate
+ checkoutDirectory${scmCheckout.path}/checkoutDirectory
+ content\${siteContent.path}/content
+/configuration
+ /plugin
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-site-plugin/artifactId
+configuration
+
stagingRepositoryIdmyfaces-local-staging/stagingRepositoryId
+ stagingSiteURL${siteDeploy.url}/stagingSiteURL
+/configuration
+ /plugin
+/plugins
+
/build
reporting
plugins
@@ -65,7 +96,7 @@
developerConnectionscm:svn:
https://svn.apache.org/repos/asf/myfaces/site/trunk/developerConnection
urlhttp://svn.apache.org/viewcvs.cgi/myfaces/site/trunk/url
/scm
-
+!--
distributionManagement
site
idapache.website/id
@@ -73,6 +104,14 @@
urlscpexe://people.apache.org/www/myfaces.apache.org/url
/site
/distributionManagement
-
+--
+ distributionManagement
+site
+ idmyfaces-local-staging/id
+ nameApache Website/name
+ urlscp://localhost/home/lu4242/myfaces-site/url
+/site
+ /distributionManagement
+
/project
2012/11/27, Leonardo Uribe lu4...@gmail.com:
Hi
Since svnpubsub is working, do a site:deploy does not work. Instead,
you need to:
1. checkout locally
http://svn.apache.org/repos/asf/myfaces/site/publish/
WARNING: Our site is huge, that will take a lot of time
2. Use a local site:stage-deploy like is described here:
http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html
Remember all our projects are multi-module, so
maven-scm-publish-plugin does not help.
3. Manual commit
We need to update all myfaces projects to use this strategy, the idea
is do that with the current release process of myfaces core 2.1.10 /
2.0.16 . I'm still trying to find how to do the necessary changes in
our pom.xml
Re: Documentation
Hi
The server entry goes into .m2/settings.xml
regards,
Leonardo
2012/11/28, Leonardo Uribe lu4...@gmail.com:
Hi
Yes, it is something like that, but it requires some extra details
1. Define a local server to do the site:stage-deploy using scp (note
the change in the pom.xml related to myfaces-local-staging)
server
idmyfaces-local-staging/id
usernamemylocaluser/username
passwordmylocalpwd/password
/server
2. The idea is use two folders (/myfaces-site/checkout and
/myfaces-site/site), and do a hard copy from site to checkout before
commit the content under checkout folder.
The idea is write a guide and do the necessary changes in all pom.xml
files.
I have deployed the site for the release, but it seems something is
still not working well for svnpubsub, so I reopened the issue on
INFRA.
regards,
Leonardo Uribe
2012/11/27, Grant Smith grantsm...@apache.org:
Leo,
OK, I'll wait for you to finish the release process before I try to make
any documentation changes. If I understand you correctly, once you make
the
above changes, all I need to do to build the docs and deploy them are:
1. mvn site:stage-deploy (in EACH of the modules)
2. svn commit
Is that correct ?
Thanks,
-Grant.
On Tue, Nov 27, 2012 at 7:18 AM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
This is the provisional changes done in site pom.xml to deploy the
site. I have locally two folders:
/home/lu4242/myfaces-site/checkout
/home/lu4242/myfaces-site/site
The idea is do the changes in myfaces-site/site and then do a manual
copy/commit for checkout.
regards,
Leonardo
Index: .
===
--- . (revision 1401760)
+++ . (working copy)
@@ -34,23 +34,54 @@
descriptionThis is the MyFaces Site/description
urlhttp://myfaces.apache.org/url
+ properties
+
site.mainDirectory${user.home}/myfaces-site/checkout/site.mainDirectory
+siteContent.path${user.home}/myfaces-site/site/siteContent.path
+!-- it's a default location for performance reason (not checkout
the content all the time)
+ you can override this value in your settings. --
+scmCheckout.path\${site.mainDirectory}/scmCheckout.path
+
siteDeploy.urlfile://${user.home}/myfaces-site/site/siteDeploy.url
+ /properties
+
build
defaultGoalsite/defaultGoal
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-ssh-external/artifactId
-version1.0-beta-7/version
+version2.2/version
/extension
/extensions
pluginManagement
plugins
plugin
artifactIdmaven-site-plugin/artifactId
-version3.0/version
+version3.1/version
/plugin
/plugins
/pluginManagement
+plugins
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-scm-publish-plugin/artifactId
+version1.0-beta-1/version
+configuration
+ pubScmUrlscm:svn:
https://svn.apache.org/repos/asf/myfaces/site/publish//pubScmUrl
+ tryUpdatetrue/tryUpdate
+ checkoutDirectory${scmCheckout.path}/checkoutDirectory
+ content\${siteContent.path}/content
+/configuration
+ /plugin
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-site-plugin/artifactId
+configuration
+
stagingRepositoryIdmyfaces-local-staging/stagingRepositoryId
+ stagingSiteURL${siteDeploy.url}/stagingSiteURL
+/configuration
+ /plugin
+/plugins
+
/build
reporting
plugins
@@ -65,7 +96,7 @@
developerConnectionscm:svn:
https://svn.apache.org/repos/asf/myfaces/site/trunk/developerConnection
urlhttp://svn.apache.org/viewcvs.cgi/myfaces/site/trunk/url
/scm
-
+!--
distributionManagement
site
idapache.website/id
@@ -73,6 +104,14 @@
urlscpexe://people.apache.org/www/myfaces.apache.org/url
/site
/distributionManagement
-
+--
+ distributionManagement
+site
+ idmyfaces-local-staging/id
+ nameApache Website/name
+ urlscp://localhost/home/lu4242/myfaces-site/url
+/site
+ /distributionManagement
+
/project
2012/11/27, Leonardo Uribe lu4...@gmail.com:
Hi
Since svnpubsub is working, do a site:deploy does not work. Instead,
you need to:
1. checkout locally
http://svn.apache.org/repos/asf/myfaces/site/publish/
WARNING: Our site is huge, that will take a lot of time
2. Use a local site:stage-deploy like is described here:
http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html
Remember all our projects are multi-module, so
maven-scm-publish-plugin does not help.
3. Manual commit
We need to update all myfaces projects to use this strategy, the idea
is do that with the
Result (was: Re: [VOTE] Release of Extensions Validator 1.2.6 and 2.0.6)
thank you for voting! 3 binding +1 votes (pmc): - Grant Smith - Werner Punz - Gerhard Petracek 2 non-binding +1 votes: - Hazem Saleh - Thomas Andraschko no -1 votes regards, gerhard 2012/11/25 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions Validator out. The artifacts are deployed to Nexus [1]. These 2 releases contain the following modules for JSF 1.2, JSF 2.x: - ExtVal Core - ExtVal Property-Validation - ExtVal Bean-Validation (Integration + additional features for using JSR 303 with JSF 1.2 and 2.x) - Trinidad-Support-Module - Generic-Support-Module Please take a look at the 1.2.6 and 2.0.6 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-071/org/apache/myfaces/extensions/validator/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: Result (was: Re: [VOTE] Release of Extensions Validator 1.2.6 and 2.0.6)
count me in for another +1 ;) Sorry that I missed the eot, pretty busy around here... LieGrue, strub From: Gerhard Petracek gpetra...@apache.org To: dev@myfaces.apache.org Sent: Wednesday, November 28, 2012 7:49 PM Subject: Result (was: Re: [VOTE] Release of Extensions Validator 1.2.6 and 2.0.6) thank you for voting! 3 binding +1 votes (pmc): - Grant Smith - Werner Punz - Gerhard Petracek 2 non-binding +1 votes: - Hazem Saleh - Thomas Andraschko no -1 votes regards, gerhard 2012/11/25 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions Validator out. The artifacts are deployed to Nexus [1]. These 2 releases contain the following modules for JSF 1.2, JSF 2.x: - ExtVal Core - ExtVal Property-Validation - ExtVal Bean-Validation (Integration + additional features for using JSR 303 with JSF 1.2 and 2.x) - Trinidad-Support-Module - Generic-Support-Module Please take a look at the 1.2.6 and 2.0.6 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-071/org/apache/myfaces/extensions/validator/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[jira] [Reopened] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2259: --- Assignee: Max Starets Reopening this issue, since there are other problems with the dialog beyond the null source error in JSF Ajax implementation Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505969#comment-13505969 ] Max Starets commented on TRINIDAD-2259: --- The org.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX workaround would still apply though Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
