JSF 2.3
Hello, Any opinions on this https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra Basically it's regarding the common opinon that JavaEE should have a action based framework or support a action based style in JSF. cheers
Re: JSF 2.3
If they add support for such actions with @RequestMapping, then it should also be possible to declare request params as method params. e.g. @RequestMapping(...) public void doSomething(@RequestParameter(name=..) private String test) And of course conversion/validation of the request parameters. 2014/1/14 Karl Kildén karl.kil...@gmail.com Hello, Any opinions on this https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra Basically it's regarding the common opinon that JavaEE should have a action based framework or support a action based style in JSF. cheers
Re: JSF 2.3
Could you explain what the actual benefits of the action based programming style are? I am missing the purpose/use cases for the actual need of such a feature. Thanks in advance! Mit freundlichen Grüßen, *Christian Beikov* Am 14.01.2014 12:02, schrieb Thomas Andraschko: If they add support for such actions with @RequestMapping, then it should also be possible to declare request params as method params. e.g. @RequestMapping(...) public void doSomething(@RequestParameter(name=..) private String test) And of course conversion/validation of the request parameters. 2014/1/14 Karl Kildén karl.kil...@gmail.com Hello, Any opinions on this https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra Basically it's regarding the common opinon that JavaEE should have a action based framework or support a action based style in JSF. cheers
Re: JSF 2.3
Action based vs component based is a frequently discussed topic and you can probably find many resources arguing for one or the other. I really like JSF but I am still curious about stuff like this. For example if I want to use a third part javascript library for special corner cases it might be a good thing? I don't know but I'm very interested in others opinions. Thomas, useful for you? On 14 January 2014 12:24, Christian Beikov christian.bei...@gmail.comwrote: Could you explain what the actual benefits of the action based programming style are? I am missing the purpose/use cases for the actual need of such a feature. Thanks in advance! Mit freundlichen Grüßen, *Christian Beikov* Am 14.01.2014 12:02, schrieb Thomas Andraschko: If they add support for such actions with @RequestMapping, then it should also be possible to declare request params as method params. e.g. @RequestMapping(...) public void doSomething(@RequestParameter(name=..) private String test) And of course conversion/validation of the request parameters. 2014/1/14 Karl Kildén karl.kil...@gmail.com Hello, Any opinions on this https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf- tip-56-using-action-based-prototype-mojarra Basically it's regarding the common opinon that JavaEE should have a action based framework or support a action based style in JSF. cheers
Re: JSF 2.3
Not really but it's just matter of taste ;) 2014/1/14 Karl Kildén karl.kil...@gmail.com Action based vs component based is a frequently discussed topic and you can probably find many resources arguing for one or the other. I really like JSF but I am still curious about stuff like this. For example if I want to use a third part javascript library for special corner cases it might be a good thing? I don't know but I'm very interested in others opinions. Thomas, useful for you? On 14 January 2014 12:24, Christian Beikov christian.bei...@gmail.com wrote: Could you explain what the actual benefits of the action based programming style are? I am missing the purpose/use cases for the actual need of such a feature. Thanks in advance! Mit freundlichen Grüßen, *Christian Beikov* Am 14.01.2014 12:02, schrieb Thomas Andraschko: If they add support for such actions with @RequestMapping, then it should also be possible to declare request params as method params. e.g. @RequestMapping(...) public void doSomething(@RequestParameter(name=..) private String test) And of course conversion/validation of the request parameters. 2014/1/14 Karl Kildén karl.kil...@gmail.com Hello, Any opinions on this https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf- tip-56-using-action-based-prototype-mojarra Basically it's regarding the common opinon that JavaEE should have a action based framework or support a action based style in JSF. cheers
Re: [ANNOUNCE] MyFaces Core v2.2.0 Release
Hi Howard 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Leonardo, Some questions for you: 1. How has MyFaces 2.2 (beta) release been performing and/or accepted by MyFaces user community? We have received some good feedback that has helped a lot to get the new release. 2. Any big corporation/names start using MyFaces 2.2 (beta) release yet? If things goes like it was in 2.0, it still will take a couple of releases so more people start using fully the new artifacts, but since we are 2.2 I hope the adoption will be faster. 3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)? Yes, there are some improvements in session size / state management that will help. From speed perspective, with the same flags enabled both perform more or less the same. 4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2 performance against Mojarra, Wicket, and Spring...like you did for MyFaces 2.1.7? Probably, but more as an update to keep track what has happened. regards, Leonardo Uribe Thanks, Howard On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org wrote: The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.0.
Re: [core] What's new in MyFaces 2.2
Hi 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Wow, interesting that you sent this email as I was writing my email, asking a few questions bout MyFaces 2.2. Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me to think about MyFaces 2.2. I am considering migrating my app from MyFaces 2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and since the last time that I tested/used myFaces 2.2, I have no issues/defects to report. Just have not pushed MyFaces 2.2 to my production environment yet. The changes included in JSF 2.2 does not make any conflict with 2.0 / 2.1 code. The migration step from 2.1 to 2.2 is very simple, just replace the jars and that's it. There are some differences like for example the view scope beans are now stored in session and if CDI is enabled, view scope is managed by CDI. Additionally, there wasn't any change that affect the behavior significantly in JSF 2.2, so the code looks very stable. It were also included a lot of junit tests for the new features to ensure everything works as expected, which reduces in the long term the occurrence of bugs and provides a better code quality. I wanted to wait and hear a bit more from the community about it, but (LOL) that's the thing, there are not many questions at all on MyFaces user list. Evidently, it just works! :) On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org wrote: Hi For the people who want to know quickly what's new in MyFaces 2.2, I have written a summary of the new features here: http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html regards, Leonardo Uribe
Re: JSF 2.3
I am not an expert in action framework concepts, despite having used struts for several years :) but I have some practical experience with Struts, an action-based framework. So hopefully I can comment on the benefits of an action-based framework from the perspective a component-based mindset. I started writing web apps in a pure component-based web framework (WebObjects/Objective C) back in the 90s, and around the year 2000, give or take a couple years, wrote a major web application in WebObjects/Java, which I continue to maintain to this day. At some point, maybe around 2005 or 2006, a political decision was pushed down from above to switch the project to Struts, an action-based framework. Eventually, the project was converted over to struts (which took longer than developing the project in the first place, despite knowing exactly what it was supposed to do), and it continues to run in struts until this day. Now there is a strong recommendation that the project be switched over to JSF, which you might think that I, as a component-based development mindset person, would agree, especially since all of my other projects are in JSF these days. However, as I considered the conversiion, I realized that the action-based style provides some benefits for a public-facing needs-to-be-secure-and-error-free application. On a JSF page, anything that's a bean can have its methods called and its values set. There's no contract enforced between the view and controller layer, so the designer has to insure that view beans aren't providing non-view-bean access. There's also no correspondence between calling an action method and determining what field values (component value bindings) are related to that method. In Struts, you explicitly define which methods are actions (not every public String or public void is neccessarily supposed to be an action) and more importantly which fields (by defining the form) are tied to which actions. These value containers are completely isolated from the real values, like UIInput.getSubmittedValue(). All of this is enforced by the framework rather than designed-in by the developer.This adds a lot more work, but will eliminate certain classes of development errors due to the fact that you cannot break the contract. This is something that you probably could make happen in JSF right now with enough extra work. Action based framework action methods also operate on the idea of a pipeline. You don't call a single method, you call a chain of methods, each of which, like the unix shell do one small job, then forward to task on to the next thing. Not being an action-framework-mindset person, I probably don't fully take advantage of what this is supposed to allow you to do. it seems to me that it is rare that a web form action can be broken up into many sharable sequential input-output-based subtasks, other than processing a page submit, then initializing the next page. I used it a little bit to add page-based state management to my application (webobjects, like most component-based frameworks, was stateful, but struts was not stateful). I also cheated and used velocity as my view framework instead of JSPs (just like I cheated and used facelets as my view framework in JSF 1.1, which gave me a little bit more of a component-based presentation layer. (velocity macros). Explicitly initializing a page still seems good to me, even after 10 or 11 years of using JSF. Integration and unit testing for a struts project currently is far easier than testing a JSF project because of the explicit contract and statelessness. In an ideal world, I guess I'd like to upgrade this struts project so that I am using facelets as the view templating system (rather than velocity). I'd like the project to remain stateless (my page state system is more than adequate for the few things that need to retain state). I'd like to keep the explicit forced declaration of what form values belong to which actions, and how those values are validated for that action. I don't want to lose my ability to test, and maybe it is my own fault for not looking harder, but I haven't found a good way to test JSF pages after all this time. I'm not sure if I care about action chaining, but I like explicit page initialization. So I'm glad to see that action support is being considered for JSF 2.3. I think the explicit action/form declarations can be helpful. I'm glad that MyFaces is working on statelessness. At some point, it may indeed be practical to upgrade this project to JSF without losing all of the benefits that I now, years later, see that struts has provided. I definitely didn't see any benefits when I initially switched. Hope this helps. On Tue, Jan 14, 2014 at 6:24 AM, Christian Beikov christian.bei...@gmail.com wrote: Could you explain what the actual benefits of the action based programming style are? I am missing the purpose/use cases for the actual need of such a feature. Thanks
Re: JSF 2.3
See my answers inline. Am 14.01.2014 16:40, schrieb Mike Kienenberger: I am not an expert in action framework concepts, despite having used struts for several years :) but I have some practical experience with Struts, an action-based framework. So hopefully I can comment on the benefits of an action-based framework from the perspective a component-based mindset. I started writing web apps in a pure component-based web framework (WebObjects/Objective C) back in the 90s, and around the year 2000, give or take a couple years, wrote a major web application in WebObjects/Java, which I continue to maintain to this day. At some point, maybe around 2005 or 2006, a political decision was pushed down from above to switch the project to Struts, an action-based framework. Eventually, the project was converted over to struts (which took longer than developing the project in the first place, despite knowing exactly what it was supposed to do), and it continues to run in struts until this day. Now there is a strong recommendation that the project be switched over to JSF, which you might think that I, as a component-based development mindset person, would agree, especially since all of my other projects are in JSF these days. However, as I considered the conversiion, I realized that the action-based style provides some benefits for a public-facing needs-to-be-secure-and-error-free application. I am not quite sure about what you mean with that, please clarify. For me it sounds like you are refering to testability but please correct me if I am wrong. On a JSF page, anything that's a bean can have its methods called and its values set. There's no contract enforced between the view and controller layer, so the designer has to insure that view beans aren't providing non-view-bean access. There's also no correspondence between calling an action method and determining what field values (component value bindings) are related to that method. Basicly what you wrote is true, but still, IMO this is no argument pro action based style. You can design your action methods just like in an action based framework, but on a higher level of abstraction. EL allows you to use parameters, so if you really want to be explicit about that, you can still do it. In fact I think that this is a nice approach that I successfully used in some projects, but it comes with some problems. To wrap it up, you can be explicit about parameters and more or less design it to be stateless, but I guess most of the time this makes the whole thing more complicated. In Struts, you explicitly define which methods are actions (not every public String or public void is neccessarily supposed to be an action) and more importantly which fields (by defining the form) are tied to which actions. These value containers are completely isolated from the real values, like UIInput.getSubmittedValue(). All of this is enforced by the framework rather than designed-in by the developer.This adds a lot more work, but will eliminate certain classes of development errors due to the fact that you cannot break the contract. This is something that you probably could make happen in JSF right now with enough extra work. Could you elaborate what kind of errors you are refering to? Action based framework action methods also operate on the idea of a pipeline. You don't call a single method, you call a chain of methods, each of which, like the unix shell do one small job, then forward to task on to the next thing. Not being an action-framework-mindset person, I probably don't fully take advantage of what this is supposed to allow you to do. it seems to me that it is rare that a web form action can be broken up into many sharable sequential input-output-based subtasks, other than processing a page submit, then initializing the next page. I used it a little bit to add page-based state management to my application (webobjects, like most component-based frameworks, was stateful, but struts was not stateful). I also cheated and used velocity as my view framework instead of JSPs (just like I cheated and used facelets as my view framework in JSF 1.1, which gave me a little bit more of a component-based presentation layer. (velocity macros). Explicitly initializing a page still seems good to me, even after 10 or 11 years of using JSF. Agree and I guess therefore the viewActions have been introduced in JSF 2.2 Integration and unit testing for a struts project currently is far easier than testing a JSF project because of the explicit contract and statelessness. As written above, I guess if you design with testability in mind, you can also reach that with JSF. In an ideal world, I guess I'd like to upgrade this struts project so that I am using facelets as the view templating system (rather than velocity). I'd like the project to remain stateless (my page state system is more than adequate for the few things that need to retain state). I'd like to
Re: JSF 2.3
On Tue, Jan 14, 2014 at 10:40 AM, Mike Kienenberger mkien...@gmail.comwrote: Hope this helps. +1 Mike and thanks for sharing. it's good to hear/know this about struts. when i learned java ee 6 via java ee 6 tutorial, of course, JSF is mentioned there; i don't remember struts being mentioned there at all. so, my java web application development experience/world has been JSF, and that is where my preference is today, still.
Re: [core] What's new in MyFaces 2.2
Understood, thanks Leonardo. i am really going to have to make the step to migrate to JSF 2.2. hopefully will do it, ASAP. thanks again. On Tue, Jan 14, 2014 at 9:40 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Wow, interesting that you sent this email as I was writing my email, asking a few questions bout MyFaces 2.2. Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me to think about MyFaces 2.2. I am considering migrating my app from MyFaces 2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and since the last time that I tested/used myFaces 2.2, I have no issues/defects to report. Just have not pushed MyFaces 2.2 to my production environment yet. The changes included in JSF 2.2 does not make any conflict with 2.0 / 2.1 code. The migration step from 2.1 to 2.2 is very simple, just replace the jars and that's it. There are some differences like for example the view scope beans are now stored in session and if CDI is enabled, view scope is managed by CDI. Additionally, there wasn't any change that affect the behavior significantly in JSF 2.2, so the code looks very stable. It were also included a lot of junit tests for the new features to ensure everything works as expected, which reduces in the long term the occurrence of bugs and provides a better code quality. I wanted to wait and hear a bit more from the community about it, but (LOL) that's the thing, there are not many questions at all on MyFaces user list. Evidently, it just works! :) On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org wrote: Hi For the people who want to know quickly what's new in MyFaces 2.2, I have written a summary of the new features here: http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html regards, Leonardo Uribe
Re: [ANNOUNCE] MyFaces Core v2.2.0 Release
Understood. thanks again for the response, Leonardo. On Tue, Jan 14, 2014 at 9:30 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Howard 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Leonardo, Some questions for you: 1. How has MyFaces 2.2 (beta) release been performing and/or accepted by MyFaces user community? We have received some good feedback that has helped a lot to get the new release. 2. Any big corporation/names start using MyFaces 2.2 (beta) release yet? If things goes like it was in 2.0, it still will take a couple of releases so more people start using fully the new artifacts, but since we are 2.2 I hope the adoption will be faster. 3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)? Yes, there are some improvements in session size / state management that will help. From speed perspective, with the same flags enabled both perform more or less the same. 4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2 performance against Mojarra, Wicket, and Spring...like you did for MyFaces 2.1.7? Probably, but more as an update to keep track what has happened. regards, Leonardo Uribe Thanks, Howard On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org wrote: The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.0.
Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest
FOLLOWUP: org.apache.myfaces.application.ResourceHandlerImpl.level = OFF is working great, thanks again. On Tue, Jan 7, 2014 at 11:03 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Thanks Leonardo for the response. Per javadoc[1], OFF is available as you stated. I will give that a try. [1] http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#OFF On Tue, Jan 7, 2014 at 10:54 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Howard I think it should work with: org.apache.myfaces.application.ResourceHandlerImpl.level = OFF regards, Leonardo 2014/1/7 Howard W. Smith, Jr. smithh032...@gmail.com: Leonardo, On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com wrote: The exception was added in the log on: https://issues.apache.org/jira/browse/MYFACES-3736 I have checked it and there is no evidence of an error from MyFaces side. Maybe we can do something to hide the exception, printing it only if Level.FINE is set. In the meanwhile, what is the best way to prevent this exception from appearing in my (tomee+) log file? can i disable it via logging.properties via the following? org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING
MyFaces 2.2: another release, soon?
Will there be another release of MyFaces 2.2, since MyFaces Core 2.1.14 and 2.0.20 were released? I would assume that MyFaces 2.1.14 release fixes would be included in MyFaces 2.2, too. right?
Re: MyFaces 2.2: another release, soon?
2.0, 2.1, and 2.2 were all released at the same time. On Tue, Jan 14, 2014 at 5:17 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Will there be another release of MyFaces 2.2, since MyFaces Core 2.1.14 and 2.0.20 were released? I would assume that MyFaces 2.1.14 release fixes would be included in MyFaces 2.2, too. right?
Re: MyFaces 2.2: another release, soon?
wow, thanks Mike. (Late) last night, when I was replying to an ANNOUNCE MyFaces 2.2.0 email, I thought it was the 'beta release'. I just now recognized that I replied to the (latest) MyFaces 2.2.0 release. thanks! On Tue, Jan 14, 2014 at 5:20 PM, Mike Kienenberger mkien...@gmail.comwrote: 2.0, 2.1, and 2.2 were all released at the same time. On Tue, Jan 14, 2014 at 5:17 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Will there be another release of MyFaces 2.2, since MyFaces Core 2.1.14 and 2.0.20 were released? I would assume that MyFaces 2.1.14 release fixes would be included in MyFaces 2.2, too. right?
[Tobago] Tobago Version 1.0.* and Tomcat 7
Hello all, Could you please let me know whether Tobago 1.0.* is still supported in Tomcat 7 (or later versions)? Thanks a lot for your help and best wishes, Dom
MyFaces 2.2.0 (yesterday's release) CDI @ViewScoped @PreDestroy
Okay, I downloaded MyFaces 2.2.0 (yesterday's release), and added it to my TomEE 1.6.1 SNAPSHOT (downloaded 2 or 3 days ago), and I decided to test CDI @ViewScoped @PreDestroy. Below, you will see that I logged in, and opened a few pages that reference a few different instances of CDI @ViewScoped beans, @PreDestroy releaseResources() method was executed as i navigated to different views, but then here is the thing that concerns me, the @PreDestroy of pre-existing-and-thought-to-be-already-destroyed bean 'instances' were executed after logout, where logout = session.invalidate. See below, please. Is this behavior per the spec? Jan 15, 2014 2:16:45 AM pf.ApplicationScopeBean login INFO: sessionId = administrator5AD906CC2D25991567A047780BBBF561 Jan 15, 2014 2:16:45 AM jsf.users.pf_UsersController loginUser INFO: administrator logged in at 01/15/2014 02:16 AM Jan 15, 2014 2:17:01 AM jsf.orders.EditDriverVehicles init INFO: jsf.orders.EditDriverVehicles@5fe1cb9b Jan 15, 2014 2:17:03 AM jsf.orders.EditDriverVehicles releaseResources INFO: jsf.orders.EditDriverVehicles@5fe1cb9b Jan 15, 2014 2:17:06 AM jsf.orders.EditDriverVehicles init INFO: jsf.orders.EditDriverVehicles@7133db9 Jan 15, 2014 2:17:07 AM jsf.orders.EditDriverVehicles releaseResources INFO: jsf.orders.EditDriverVehicles@7133db9 Jan 15, 2014 2:17:10 AM jsf.orders.OrderDocumentBean init INFO: jsf.orders.OrderDocumentBean@41d7a36a Jan 15, 2014 2:17:12 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@41d7a36a Jan 15, 2014 2:17:14 AM jsf.orders.OrderDocumentBean init INFO: jsf.orders.OrderDocumentBean@486ae85a Jan 15, 2014 2:17:17 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@486ae85a Jan 15, 2014 2:17:21 AM jsf.orders.OrderDocumentBean init INFO: jsf.orders.OrderDocumentBean@6ff554c9 Jan 15, 2014 2:17:23 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@6ff554c9 Jan 15, 2014 2:17:29 AM jsf.users.pf_UsersController logout INFO: administrator logged out at 01/15/2014 02:17 AM Jan 15, 2014 2:17:29 AM jsf.orders.EditDriverVehicles releaseResources INFO: jsf.orders.EditDriverVehicles@7133db9 Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@486ae85a Jan 15, 2014 2:17:29 AM jsf.orders.EditDriverVehicles releaseResources INFO: jsf.orders.EditDriverVehicles@5fe1cb9b Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@6ff554c9 Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources INFO: jsf.orders.OrderDocumentBean@41d7a36a FYI, I 'want' to migrate to MyFaces 2.2.0 in production, and I think I will do it anyway, but please answer my question above about this behavior/implementation/test-results-of-mine. Thanks, Howard
Re: [core] What's new in MyFaces 2.2
Done (deployed MyFaces 2.2.0 with my app in production). On Tue, Jan 14, 2014 at 12:54 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: i am really going to have to make the step to migrate to JSF 2.2. hopefully will do it, ASAP. thanks again.
