Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Can i ask you how much users serves your app? Currently our app takes only 20mb session size with 200 (or 100, can't remember exactly) concurrent users and we don't use that much View(Access)Scoped beans. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
The most users that will be using the app concurrently is 4 to 5 users (my family), and there are times that they are doing some 'heavy lifting' (database retrievals/updates, as well as PDF files generated in memory and printed/viewed/emailed/faxed, and occasional data push to Google Calendar via Google Calendar API). Next, planning to automatically insert data into database from public website's form results. Hoping to expand the services of the 'app' to customers via the public website...one day. The (JSF/HTML5) web app is accessed in and out of the office on multiple platforms (laptops, iPad, multiple Android devices). On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can i ask you how much users serves your app? Currently our app takes only 20mb session size with 200 (or 100, can't remember exactly) concurrent users and we don't use that much View(Access)Scoped beans. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
hi howard, you can have a look at [1] (e.g. slide #9) the mentioned public application is using codi scopes like @ViewAccessScoped without any performance and/or memory issue. regards, gerhard [1] http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com The most users that will be using the app concurrently is 4 to 5 users (my family), and there are times that they are doing some 'heavy lifting' (database retrievals/updates, as well as PDF files generated in memory and printed/viewed/emailed/faxed, and occasional data push to Google Calendar via Google Calendar API). Next, planning to automatically insert data into database from public website's form results. Hoping to expand the services of the 'app' to customers via the public website...one day. The (JSF/HTML5) web app is accessed in and out of the office on multiple platforms (laptops, iPad, multiple Android devices). On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can i ask you how much users serves your app? Currently our app takes only 20mb session size with 200 (or 100, can't remember exactly) concurrent users and we don't use that much View(Access)Scoped beans. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Thanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best, only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but because of
this migration to TomEE/CDI, my focus has been there, and the server has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5 users
(my
family), and there are times that they are doing some 'heavy lifting'
(database retrievals/updates, as well as PDF files generated in memory
and
printed/viewed/emailed/faxed, and occasional data push to Google Calendar
via Google Calendar API). Next, planning to automatically insert data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100, can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and
JUEL
2.2.5. :)
Looking forward to the performance advantages/gains of OpenWebBeans.
:)
Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
and Google Calendar requests/updates are the only 2 bottlenecks in
the
app.
Thanks,
Howard
On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Howard, there is nothing against ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to high memory
usage,
so
it's better to use RequestScoped if possible.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
I'd like to take time to thank you all that helped me migrate
from
Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed
beans. I
think the migration is complete. I am in regression testing
phase/mode
now.
:)
Special shout out to Thomas Andraschko, as his inputs in
PrimeFaces
forums
and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to
MyFaces
Core
2.1.8 for fast (AJAX) rendering performance, and then he even
recommended
MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and
even
today, he encouraged me to consider Batoo JPA, and because of
that,
TomEE/OpenEJB and Batoo JPA are now discussing integration! :)
Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think
Thomas
and
some other expert users in PrimeFaces Core forum recommended
@RequestScoped
as much as possible throughout app, and recommended against JSF
@ViewScoped
as well as CODI @ViewAccessScoped (I hope I'm not misquoting
them...smile).
Honestly, I have no CDI @RequestScoped beans in my app; I need to
take
time
to move some of my code from CDI @SessionScoped to CDI
@RequestScoped.
Also, due to issues I experienced injecting EJBs inside of
@FacesConverter
(which were added to CDI @SessionScoped beans) caused me to move
all
my
@FacesConverter classes to JSF @RequestScoped beans; that seems
to
be
working great, but Mark and Gerhard has already recommended CODI
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
well, that should do :) We are serving up to 40.000 users with now 5GB RAM. But mostly due to lots of caches in our app. Oh and we have 16 webapps. Each user getting their own session in each webapp... So really nothing to worry about. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, November 21, 2012 11:29 AM Subject: Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped T he most users that will be using the app concurrently is 4 to 5 users (my family), and there are times that they are doing some 'heavy lifting' (database retrievals/updates, as well as PDF files generated in memory and printed/viewed/emailed/faxed, and occasional data push to Google Calendar via Google Calendar API). Next, planning to automatically insert data into database from public website's form results. Hoping to expand the services of the 'app' to customers via the public website...one day. The (JSF/HTML5) web app is accessed in and out of the office on multiple platforms (laptops, iPad, multiple Android devices). On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can i ask you how much users serves your app? Currently our app takes only 20mb session size with 200 (or 100, can't remember exactly) concurrent users and we don't use that much View(Access)Scoped beans. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP??? :) Oh, Romain informed me that tomee.xml JDBC resources automatically have pooling. I hope that is the case, because as soon as regression testing is complete, I would like to push the new CDI version of my JSF web app to production, and start using some of the other/neat features of CDI, like CDI events where possible. :) Thanks, Howard
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
@SessionScoped has the downside that you cannot open multiple browser tabs with
different data. Think about having a list of Cars and then opening 2 different
car-edit dialoges in new browser tabs. That would not work using @SessionScoped
and is the reason why we invented @WindowScoped and consorts.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Wednesday, November 21, 2012 11:55 AM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
T hanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best, only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml
which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in
production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but because of
this migration to TomEE/CDI, my focus has been there, and the server has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5 users
(my
family), and there are times that they are doing some 'heavy
lifting'
(database retrievals/updates, as well as PDF files generated in memory
and
printed/viewed/emailed/faxed, and occasional data push to Google
Calendar
via Google Calendar API). Next, planning to automatically insert data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on
multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100,
can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but
right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
2.1.9 and
JUEL
2.2.5. :)
Looking forward to the performance advantages/gains of
OpenWebBeans.
:)
Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
and Google Calendar requests/updates are the only 2
bottlenecks in
the
app.
Thanks,
Howard
On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Howard, there is nothing against
ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to
high memory
usage,
so
it's better to use RequestScoped if possible.
2012/11/21 Howard W. Smith, Jr.
smithh032...@gmail.com
I'd like to take time to thank you all that
helped me migrate
from
Glassfish 3.1.2.2 and JSF Managed beans to TomEE
and CDI managed
beans. I
think the migration is complete. I am in
regression testing
phase/mode
now.
:)
Special shout out to Thomas Andraschko, as his
inputs in
PrimeFaces
forums
and blogs, lead/motivated me to migrate from
Mojarra 2.1.7 to
MyFaces
Core
2.1.8 for fast (AJAX) rendering performance, and
then he even
recommended
MyFaces Core, OpenWebBeans, JUEL for huge
performance gains, and
even
today, he encouraged me to consider Batoo JPA, and
because of
that,
TomEE/OpenEJB and Batoo JPA are now discussing
integration! :)
Anyway, Jose, here, recommended CODI
@ViewAccessScoped. I think
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Great, thanks Mark, glad to hear that! Caches? Care to share a blog that 'you' possibly wrote on that, or anyone else? :) I did read about Second-Level caching in Java EE 6 tutorial, but was not a big priority when I reviewed that before I began developing JSF web app last year. :) On Wed, Nov 21, 2012 at 6:07 AM, Mark Struberg strub...@yahoo.de wrote: well, that should do :) We are serving up to 40.000 users with now 5GB RAM. But mostly due to lots of caches in our app. Oh and we have 16 webapps. Each user getting their own session in each webapp... So really nothing to worry about. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, November 21, 2012 11:29 AM Subject: Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped T he most users that will be using the app concurrently is 4 to 5 users (my family), and there are times that they are doing some 'heavy lifting' (database retrievals/updates, as well as PDF files generated in memory and printed/viewed/emailed/faxed, and occasional data push to Google Calendar via Google Calendar API). Next, planning to automatically insert data into database from public website's form results. Hoping to expand the services of the 'app' to customers via the public website...one day. The (JSF/HTML5) web app is accessed in and out of the office on multiple platforms (laptops, iPad, multiple Android devices). On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Can i ask you how much users serves your app? Currently our app takes only 20mb session size with 200 (or 100, can't remember exactly) concurrent users and we don't use that much View(Access)Scoped beans. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Thomas, Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since production box/server is running Windows 2003 Server, where 4GB RAM is max...shaking my head. I'm sure we will upgrade when necessary, but right now that app is lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and JUEL 2.2.5. :) Looking forward to the performance advantages/gains of OpenWebBeans. :) Also, this Batoo JPA that you mentioned earlier, because EclipseLink/Derby and Google Calendar requests/updates are the only 2 bottlenecks in the app. Thanks, Howard On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko andraschko.tho...@gmail.com wrote: Howard, there is nothing against ViewScoped/ViewAccessScoped. But many data in ViewScoped/ViewAccessScoped leads to high memory usage, so it's better to use RequestScoped if possible. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com I'd like to take time to thank you all that helped me migrate from Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI managed beans. I think the migration is complete. I am in regression testing phase/mode now. :) Special shout out to Thomas Andraschko, as his inputs in PrimeFaces forums and blogs, lead/motivated me to migrate from Mojarra 2.1.7 to MyFaces Core 2.1.8 for fast (AJAX) rendering performance, and then he even recommended MyFaces Core, OpenWebBeans, JUEL for huge performance gains, and even today, he encouraged me to consider Batoo JPA, and because of that, TomEE/OpenEJB and Batoo JPA are now discussing integration! :) Anyway, Jose, here, recommended CODI @ViewAccessScoped. I think Thomas and some other expert users in PrimeFaces Core forum recommended @RequestScoped as much as possible throughout app, and recommended against JSF @ViewScoped as well as CODI @ViewAccessScoped (I hope I'm not misquoting them...smile). Honestly, I have no CDI @RequestScoped beans in my app; I need to take time to move some of my code from CDI @SessionScoped to CDI @RequestScoped. Also, due to issues I experienced injecting EJBs inside of @FacesConverter (which were added to CDI @SessionScoped beans) caused me to move all my @FacesConverter classes to JSF @RequestScoped beans; that seems to be working great, but Mark and Gerhard has already recommended CODI @Advanced/etc... to inject beans in @FacesConverter classes. I need to give them a try even though I spent hours moving @FacesConverter classes from CDI beans to JSF Managed beans...during this migration to CDI. So, please advise on whether I should use @ViewAccessScoped; pros, cons, promote/hinder performance, etc... OR, should I move to CDI @RequestScoped, ASAP
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Interesting and thanks for letting me know. I thought I read somewhere that
CDI (or 'OpenWebBeans') has this ability that you're talking about, but
when I read about it earlier, i didn't see it referred as @WindowScoped.
Good to know, but the endusers have been trained to 'only' use Google
Chrome, and no need of opening multiple browser tabs/windows.
On Wed, Nov 21, 2012 at 6:12 AM, Mark Struberg strub...@yahoo.de wrote:
@SessionScoped has the downside that you cannot open multiple browser tabs
with different data. Think about having a list of Cars and then opening 2
different car-edit dialoges in new browser tabs. That would not work using
@SessionScoped and is the reason why we invented @WindowScoped and consorts.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Wednesday, November 21, 2012 11:55 AM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
T hanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best, only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml
which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in
production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but because
of
this migration to TomEE/CDI, my focus has been there, and the server has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5
users
(my
family), and there are times that they are doing some 'heavy
lifting'
(database retrievals/updates, as well as PDF files generated in
memory
and
printed/viewed/emailed/faxed, and occasional data push to Google
Calendar
via Google Calendar API). Next, planning to automatically insert data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on
multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100,
can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but
right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
2.1.9 and
JUEL
2.2.5. :)
Looking forward to the performance advantages/gains of
OpenWebBeans.
:)
Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
and Google Calendar requests/updates are the only 2
bottlenecks in
the
app.
Thanks,
Howard
On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Howard, there is nothing against
ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to
high memory
usage,
so
it's better to use RequestScoped if possible.
2012/11/21 Howard W. Smith, Jr.
smithh032...@gmail.com
I'd like to take time to thank you all that
helped me migrate
from
Glassfish 3.1.2.2 and JSF Managed beans to TomEE
and CDI managed
beans. I
think the migration is complete. I am in
regression testing
phase/mode
now.
:)
Special shout out to Thomas Andraschko, as his
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Can you all tell me why @PreDestroy method on CDI @ApplicationScoped is not
being invoked when app is undeployed? @PreDestroy on JSF @ApplicationScoped
Managed bean was invoked when app was undeployed (or app server was
shutdown).
On Wed, Nov 21, 2012 at 6:16 AM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
Interesting and thanks for letting me know. I thought I read somewhere
that CDI (or 'OpenWebBeans') has this ability that you're talking about,
but when I read about it earlier, i didn't see it referred as @WindowScoped.
Good to know, but the endusers have been trained to 'only' use Google
Chrome, and no need of opening multiple browser tabs/windows.
On Wed, Nov 21, 2012 at 6:12 AM, Mark Struberg strub...@yahoo.de wrote:
@SessionScoped has the downside that you cannot open multiple browser
tabs with different data. Think about having a list of Cars and then
opening 2 different car-edit dialoges in new browser tabs. That would not
work using @SessionScoped and is the reason why we invented @WindowScoped
and consorts.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Wednesday, November 21, 2012 11:55 AM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
T hanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best,
only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml
which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and
I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in
production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but because
of
this migration to TomEE/CDI, my focus has been there, and the server has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5
users
(my
family), and there are times that they are doing some 'heavy
lifting'
(database retrievals/updates, as well as PDF files generated in
memory
and
printed/viewed/emailed/faxed, and occasional data push to Google
Calendar
via Google Calendar API). Next, planning to automatically insert
data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on
multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100,
can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but
right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
2.1.9 and
JUEL
2.2.5. :)
Looking forward to the performance advantages/gains of
OpenWebBeans.
:)
Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
and Google Calendar requests/updates are the only 2
bottlenecks in
the
app.
Thanks,
Howard
On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Howard, there is nothing against
ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to
high memory
usage,
so
it's better to use RequestScoped if possible.
2012/11/21 Howard W. Smith, Jr.
smithh032...@gmail.com
I'd
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
please move this question to the openejb list as this might be a TomEE issue.
LieGrue,
strub
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg
strub...@yahoo.de
Sent: Wednesday, November 21, 2012 12:21 PM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
Can you all tell me why @PreDestroy method on CDI @ApplicationScoped is not
being invoked when app is undeployed? @PreDestroy on JSF @ApplicationScoped
Managed bean was invoked when app was undeployed (or app server was shutdown).
On Wed, Nov 21, 2012 at 6:16 AM, Howard W. Smith, Jr. smithh032...@gmail.com
wrote:
Interesting and thanks for letting me know. I thought I read somewhere that
CDI (or 'OpenWebBeans') has this ability that you're talking about, but when I
read about it earlier, i didn't see it referred as @WindowScoped.
Good to know, but the endusers have been trained to 'only' use Google Chrome,
and no need of opening multiple browser tabs/windows.
On Wed, Nov 21, 2012 at 6:12 AM, Mark Struberg strub...@yahoo.de wrote:
@SessionScoped has the downside that you cannot open multiple browser tabs
with different data. Think about having a list of Cars and then opening 2
different car-edit dialoges in new browser tabs. That would not work using
@SessionScoped and is the reason why we invented @WindowScoped and consorts.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Wednesday, November 21, 2012 11:55 AM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
T hanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best, only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml
which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in
production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but because of
this migration to TomEE/CDI, my focus has been there, and the server has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5 users
(my
family), and there are times that they are doing some 'heavy
lifting'
(database retrievals/updates, as well as PDF files generated in memory
and
printed/viewed/emailed/faxed, and occasional data push to Google
Calendar
via Google Calendar API). Next, planning to automatically insert data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on
multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100,
can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but
right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
2.1.9 and
JUEL
2.2.5. :)
Looking forward to the performance advantages/gains of
OpenWebBeans.
:)
Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
and Google Calendar requests/updates are the only 2
bottlenecks in
the
app.
Thanks,
Howard
On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Howard, there is nothing
Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped
Okay, already asked them, and they did tell me that this question should be
directed to them. I think Romain is looking into it. Thanks. :)
I think that's all the questions I have for now.
On Wed, Nov 21, 2012 at 6:23 AM, Mark Struberg strub...@yahoo.de wrote:
please move this question to the openejb list as this might be a TomEE
issue.
LieGrue,
strub
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg
strub...@yahoo.de
Sent: Wednesday, November 21, 2012 12:21 PM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
Can you all tell me why @PreDestroy method on CDI @ApplicationScoped is
not being invoked when app is undeployed? @PreDestroy on JSF
@ApplicationScoped Managed bean was invoked when app was undeployed (or app
server was shutdown).
On Wed, Nov 21, 2012 at 6:16 AM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
Interesting and thanks for letting me know. I thought I read somewhere
that CDI (or 'OpenWebBeans') has this ability that you're talking about,
but when I read about it earlier, i didn't see it referred as @WindowScoped.
Good to know, but the endusers have been trained to 'only' use Google
Chrome, and no need of opening multiple browser tabs/windows.
On Wed, Nov 21, 2012 at 6:12 AM, Mark Struberg strub...@yahoo.de
wrote:
@SessionScoped has the downside that you cannot open multiple browser
tabs with different data. Think about having a list of Cars and then
opening 2 different car-edit dialoges in new browser tabs. That would not
work using @SessionScoped and is the reason why we invented @WindowScoped
and consorts.
LieGrue,
strub
- Original Message -
From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Cc:
Sent: Wednesday, November 21, 2012 11:55 AM
Subject: Re: Migration to TomEE/CDI complete, regression testing,
ViewAccessScoped
T hanks Gerhard, will take a look.
Honestly, @SessionScoped fits the current design of my app the best,
only
because I'm always returning null or void from bean to JSF
commandButton/Link actionListener=..., and also, I have index.xhtml
which
is parent to all ui:include src=#{bean.page}.
Honestly, I have not seen any memory issues at all in production, and
I'm
monitoring server log on Production, looking for nullpointerexceptions
here/there, so I can resolve any/every 'exception' occuring in
production,
even if endusers don't see or 'report' the exception(s) to me. :)
Usually I'm updating the JSF web app software almost daily, but
because of
this migration to TomEE/CDI, my focus has been there, and the server
has
been running well without restart/etc...
On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi howard,
you can have a look at [1] (e.g. slide #9)
the mentioned public application is using codi scopes like
@ViewAccessScoped without any performance and/or memory issue.
regards,
gerhard
[1]
http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
The most users that will be using the app concurrently is 4 to 5
users
(my
family), and there are times that they are doing some 'heavy
lifting'
(database retrievals/updates, as well as PDF files generated in
memory
and
printed/viewed/emailed/faxed, and occasional data push to Google
Calendar
via Google Calendar API). Next, planning to automatically insert
data
into
database from public website's form results. Hoping to expand the
services
of the 'app' to customers via the public website...one day.
The (JSF/HTML5) web app is accessed in and out of the office on
multiple
platforms (laptops, iPad, multiple Android devices).
On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100,
can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
Thomas,
Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
since
production
box/server is running Windows 2003 Server, where 4GB RAM is
max...shaking
my head. I'm sure we will upgrade when necessary, but
right now that
app
is
lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
2.1.9 and
JUEL
2.2.5. :)
Looking
