Re: Can start in debug, but not in release
On 20/11/2012 20:16, Gerhard Petracek wrote: hi ludovic, to get rid of ... no org.apache.myfaces.extensions.cdi.core.api.provider.BeanManagerProvider in place! ... you have to ensure that all config-files and owb jar-files you are using are packaged correctly. you can compare your war-file e.g. with a war-file of a generated demo generate it e.g. with #4 of: mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~gpetracek/myfaces/ regards, gerhard Dear Gerhard, thank you for this quick reply. I, in fact, copied my dependencies from a pom.xml generation using your artifact. So, they are pretty much the same, excepted on the following point. I define MyFaces/OWB/PrimeFaces/other-JSF-related-stuff in a helper package, which I add as a dependency to my project. So, in the mvn dependency:tree of my project, [INFO] +- org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2:provided [INFO] +- org.apache.geronimo.specs:geronimo-el_1.0_spec:jar:1.0.2:provided is not listed. But, as far as I understand, it should not be a problem. And it does not seem to be, as adding them in my top level pom.xml does not help. Thanks again, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Gerhard, Interesting. - MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI - EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302 is a new issue that you just created and resolved per this email I just sent? :) Thanks, Howard On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: please have a look at [1] and [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/20 Mark Struberg strub...@yahoo.de CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: was thinking to http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html getAttributes() method (depend a bit on your real need) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github:
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
hi howard, yes - i've fixed EXTCDI-302 already - if you like, you can test it with the current snapshot (just ensure that you have the latest snapshot). if you have an apache-jira account, i'll update the ticket so that you are listed as the reporter of it. regards, gerhard 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 Gerhard, Interesting. - MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI - EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302 is a new issue that you just created and resolved per this email I just sent? :) Thanks, Howard On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: please have a look at [1] and [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/20 Mark Struberg strub...@yahoo.de CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i'm still not clear about your goal and where you need injection maybe share a (runnable) sample to show us what you are talking about side note: myfaces list can help you a lot about it too *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com Interesting, that will allow you to get instance of beans, if already instantiated, and that could have helped in converter, only if beans already injected earlier? On Nov 20, 2012 7:11 AM, Romain Manni-Bucau rmannibu...@gmail.com
Re: Can start in debug, but not in release
hi ludovic, then we would need a link to a package example which illustrates the issue. regards, gerhard 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 l.pe...@senat.fr l.pe...@senat.fr On 20/11/2012 20:16, Gerhard Petracek wrote: hi ludovic, to get rid of ... no org.apache.myfaces.extensions.**cdi.core.api.provider.**BeanManagerProvider in place! ... you have to ensure that all config-files and owb jar-files you are using are packaged correctly. you can compare your war-file e.g. with a war-file of a generated demo generate it e.g. with #4 of: mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~**gpetracek/myfaces/http://people.apache.org/~gpetracek/myfaces/ regards, gerhard Dear Gerhard, thank you for this quick reply. I, in fact, copied my dependencies from a pom.xml generation using your artifact. So, they are pretty much the same, excepted on the following point. I define MyFaces/OWB/PrimeFaces/other-**JSF-related-stuff in a helper package, which I add as a dependency to my project. So, in the mvn dependency:tree of my project, [INFO] +- org.apache.geronimo.specs:**geronimo-servlet_2.5_spec:jar:** 1.2:provided [INFO] +- org.apache.geronimo.specs:**geronimo-el_1.0_spec:jar:1.0.** 2:provided is not listed. But, as far as I understand, it should not be a problem. And it does not seem to be, as adding them in my top level pom.xml does not help. Thanks again, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
hi howard, #1: i've updated the ticket - thx! #2: via maven (to update a local snapshot build your application with the maven-parameter -U) or download it from [1] or checkout codi and build it locally (see the description in the wiki) regards, gerhard [1] https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/extensions/cdi/ 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 Gerhard, I just registered with username that matches username of my email address (above). Hmmm, now I need to find out how I can get the latest snapshot. Can I locate on Maven Central repository? Thanks, Howard On Wed, Nov 21, 2012 at 4:13 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi howard, yes - i've fixed EXTCDI-302 already - if you like, you can test it with the current snapshot (just ensure that you have the latest snapshot). if you have an apache-jira account, i'll update the ticket so that you are listed as the reporter of it. regards, gerhard 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 Gerhard, Interesting. - MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI - EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302 is a new issue that you just created and resolved per this email I just sent? :) Thanks, Howard On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: please have a look at [1] and [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/20 Mark Struberg strub...@yahoo.de CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org Cc: Sent: Tuesday, November 20, 2012 1:56 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext T he goal was to inject bean in facesconverter via CDI, but I don't have this need anymore, since faces converter is not an eligible injection point, so I opted to use request scoped JSF managed beans that have facesconverter defined within the bean. That's working fine. Thanks. Okay, I can cc myfaces user group as well, going forward. :-) On Nov 20, 2012 7:37 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:
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: CODI BeanManagerProvider in @FacesConverter breaks PrimeFaces p:pickList p:ajax event=transfer
mail came through just fine 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 7:07 AM Subject: CODI BeanManagerProvider in @FacesConverter breaks PrimeFaces p:pickList p:ajax event=transfer *Resending* this, because I attempted to send this earlier and got an email response that said my email was undelivered to *burntmail.com*. Mark, Please read/see below. Per your recommendation in an earlier/separate thread, Please try *BeanManagerProvider.getInstance().getContextualReference(Yourclass.class); inside the converter if you need it. If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI scopes) then you only need to do this once as you only get a proxy anyway. LieGrue, strub* I tried this, and this breaks PrimeFaces p:pickList p:ajax event=transfer. See/click URL below for my numerous tests, test results, and conclusion. :) Issue 4908 http://code.google.com/p/primefaces/issues/detail?id=4908 in PrimeFaces Issue Tracker Is this considered as an Apache CODI defect/issue or a lesson learned? Please confirm. Thanks, Howard
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
the jsf2 module of codi is tested with jsf 2.0.x and 2.1.x regards, gerhard 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 Gerhard, I definitely prefer [1] (JAR download), thanks. Interesting...I must have been multitasking big time while migrating to TomEE/CDI, because I downloaded jsf1.2 1.0.5 version of CODI; that's the filename of the JAR I downloaded. This 1.0.6 SNAPSHOT that is now available, is this jsf1.2 or jsf2.0? I hope jsf2.0, since my app has been jsf2.1 ever since the start (a little over 1 year ago). Thanks, Howard On Wed, Nov 21, 2012 at 4:40 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi howard, #1: i've updated the ticket - thx! #2: via maven (to update a local snapshot build your application with the maven-parameter -U) or download it from [1] or checkout codi and build it locally (see the description in the wiki) regards, gerhard [1] https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/extensions/cdi/ 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 Gerhard, I just registered with username that matches username of my email address (above). Hmmm, now I need to find out how I can get the latest snapshot. Can I locate on Maven Central repository? Thanks, Howard On Wed, Nov 21, 2012 at 4:13 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi howard, yes - i've fixed EXTCDI-302 already - if you like, you can test it with the current snapshot (just ensure that you have the latest snapshot). if you have an apache-jira account, i'll update the ticket so that you are listed as the reporter of it. regards, gerhard 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 Gerhard, Interesting. - MyFaces CODI https://issues.apache.org/jira/browse/EXTCDI - EXTCDI-302 https://issues.apache.org/jira/browse/EXTCDI-302 is a new issue that you just created and resolved per this email I just sent? :) Thanks, Howard On Wed, Nov 21, 2012 at 2:55 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: please have a look at [1] and [2]. regards, gerhard [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/11/20 Mark Struberg strub...@yahoo.de CDI injection using @Advanced should work perfectly fine. We tested this excessively and use it on several containers in production. I'm curious why it doesn't work for you. LieGrue, strub - Original Message - From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano rmpest...@yahoo.com.br Cc: Sent: Tuesday, November 20, 2012 3:13 PM Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Rafael, I saw that page about CODI @Advanced. :) I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject, and then I tried to inject Stateless EJB via @Inject, and that stateless EJB was not injected either. Thanks, Howard On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano rmpest...@yahoo.com.brwrote: you can also use CODI @Advanced and then inject anything in the converter, see [1]. i hope it helps. [1]: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://conventionsframework.org http://rpestano.wordpress.com/ @realpestano De: Howard W. Smith, Jr. smithh032...@gmail.com Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion users@myfaces.apache.org Cc: us...@openejb.apache.org us...@openejb.apache.org Enviadas: Terça-feira, 20 de Novembro de 2012 11:37 Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in facesconverter. Thanks. On Nov 20, 2012 8:34 AM, Mark Struberg strub...@yahoo.de wrote: you could also have used CODI BeanManagerProvider#getReference to get access to the bean. The support you need out of the box will come in JSF-2.2.
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: Can start in debug, but not in release
On 21/11/2012 10:24, Gerhard Petracek wrote: hi ludovic, then we would need a link to a package example which illustrates the issue. Dear Gerhard, while preparing this package, I constated that Mark was right and that the problem was a combination of an hibernate init failure combined with a deficient logging configuration. So, everthing works fine and the bug was not OWB/MyFaces/CODI related. Thank you again to both of you. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Gerhard/Mark, I just tested 1.0.6 SNAPSHOT of MyFaces CODI and injected bean in @FacesConverter via CODI @Advanced and @Inject as demonstrated in [2] below. It is evident that CODI @Advanced and @Inject is successfully injecting bean in the @FacesConverter, but this breaks PrimeFaces p:pickList p:ajax event=transfer as I noted earlier, Issue 4908http://code.google.com/p/primefaces/issues/detail?id=4908in PrimeFaces Issue Tracker. Next, I will attempt to test the fix for [1] EXTCDI-302 and use Mark's earlier suggestion, CODI BeanManagerProvider.getInstance(). getContextualReference(YourClass.class). Next reply will contain test results. [1] https://issues.apache.org/jira/browse/EXTCDI-302 [2] http://people.apache.org/~gpetracek/myfaces/codi/demos/ Below is stacktrace from the CODI @Advanced test that I mentioned above. This is related to PrimeFaces Issue 4908 above. java.lang.NullPointerException at jsf.role.pf_RoleController.access$000(pf_RoleController.java:45) at jsf.role.pf_RoleController$RoleControllerConverter.getAsObject(pf_RoleController.java:678) at org.primefaces.component.picklist.PickList.populateModel(PickList.java:425) at org.primefaces.component.picklist.PickList.queueEvent(PickList.java:401) at org.primefaces.component.behavior.ajax.AjaxBehaviorRenderer.decode(AjaxBehaviorRenderer.java:42) at javax.faces.component.behavior.ClientBehaviorBase.decode(ClientBehaviorBase.java:64) at org.primefaces.renderkit.CoreRenderer.decodeBehaviors(CoreRenderer.java:377) at org.primefaces.component.picklist.PickListRenderer.decode(PickListRenderer.java:50) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:467) at javax.faces.component.UIInput.decode(UIInput.java:352) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1377) at javax.faces.component.UIInput.processDecodes(UIInput.java:188) at org.apache.myfaces.context.servlet.PartialViewContextImpl$PhaseAwareVisitCallback.visit(PartialViewContextImpl.java:731) at org.apache.myfaces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:214) at javax.faces.component.UIComponent.visitTree(UIComponent.java:932) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at org.primefaces.component.tabview.TabView.visitTree(TabView.java:409) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIForm.visitTree(UIForm.java:354) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialExecute(PartialViewContextImpl.java:420) at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartial(PartialViewContextImpl.java:401) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:88) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:88) at javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcessor.process(UIViewRoot.java:1488) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1372) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:759) at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:38) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) at
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: Migrating to CDI: @Asynchronous
In my webapp i have the same issue. I need the beans.xml file in both folders too. Im using netbeans too. El nov 20, 2012 1:52 PM, Howard W. Smith, Jr. smithh032...@gmail.com escribió: Doh, NetBeans is probably not following the specification, because NetBeans has squiggly line under the bean class name, and has the following as a tip: CDI artifact is found but there is no beans.xml file. So, to avoid this, I need to have beans.xml in WEB-INF instead of META-INF. Per what I read in Java EE 6 tutorial (CDI) and other articles online, it seems as though beans.xml is supposed to be placed in META-INF, if you have JARs that you've developed that is referenced by the app. I could be saying this incorrectly. :) On Tue, Nov 20, 2012 at 1:57 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Mark, I confirmed and 'opted' to do the same as what you mentioned below, and web app is working fine. I 'moved' beans.xml from WEB-INF to META-INF, and app is running well, and running same as when beans.xml was in WEB-INF. I'll keep beans.xml in META-INF as per your recommendation. *2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1].* Please note, (temporarily) commenting out @Asynchronous method calls in my app most likely resolved the issue in OP. Thanks, Howard On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and I already reported (in an earlier post) that that didn't allow my web app to start in TomEE (or Glassfish, if I was still using Glassfish when I reported that earlier...smile). In response to Eclipse...hopefully, no offense will be taken, i'm not a user of eclipse, I've been a user of NetBeans ever since I started developing JSF web application (since last summer, 2011), and I can be the loyal
Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext
Test: 1.0.6 SNAPSHOT, CODI @Advanced *and* BeanManagerProvider to inject bean in @FacesConverter Test result: 1. CDI bean is injected successfully in @FacesConverter, as expected, and converter provides data to JSF component on xhtml (same for previous test) 2. This breaks PrimeFaces p:pickList p:ajax event=transfer (PrimeFaces Issue 4908 http://code.google.com/p/primefaces/issues/detail?id=4908). Stacktrace below: java.lang.NullPointerException at jsf.role.pf_RoleController$RoleControllerConverter.getAsObject(pf_RoleController.java:678) at org.primefaces.component.picklist.PickList.populateModel(PickList.java:425) at org.primefaces.component.picklist.PickList.queueEvent(PickList.java:401) at org.primefaces.component.behavior.ajax.AjaxBehaviorRenderer.decode(AjaxBehaviorRenderer.java:42) at javax.faces.component.behavior.ClientBehaviorBase.decode(ClientBehaviorBase.java:64) at org.primefaces.renderkit.CoreRenderer.decodeBehaviors(CoreRenderer.java:377) at org.primefaces.component.picklist.PickListRenderer.decode(PickListRenderer.java:50) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:467) at javax.faces.component.UIInput.decode(UIInput.java:352) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1377) at javax.faces.component.UIInput.processDecodes(UIInput.java:188) at org.apache.myfaces.context.servlet.PartialViewContextImpl$PhaseAwareVisitCallback.visit(PartialViewContextImpl.java:731) at org.apache.myfaces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:214) at javax.faces.component.UIComponent.visitTree(UIComponent.java:932) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at org.primefaces.component.tabview.TabView.visitTree(TabView.java:409) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIForm.visitTree(UIForm.java:354) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at javax.faces.component.UIComponent.visitTree(UIComponent.java:960) at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1165) at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialExecute(PartialViewContextImpl.java:420) at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartial(PartialViewContextImpl.java:401) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:88) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:88) at javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcessor.process(UIViewRoot.java:1488) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1372) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:759) at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:38) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at
Re: Migrating to CDI: @Asynchronous
Jose, adding beans.xml to WEB-INF 'and' META-INF breaks my app; app won't even start in TomEE, but as noted earlier/below, app can start and runs well if beans.xml is in either folder. :) On Wed, Nov 21, 2012 at 6:02 AM, José Luis Cetina maxtorz...@gmail.comwrote: In my webapp i have the same issue. I need the beans.xml file in both folders too. Im using netbeans too. El nov 20, 2012 1:52 PM, Howard W. Smith, Jr. smithh032...@gmail.com escribió: Doh, NetBeans is probably not following the specification, because NetBeans has squiggly line under the bean class name, and has the following as a tip: CDI artifact is found but there is no beans.xml file. So, to avoid this, I need to have beans.xml in WEB-INF instead of META-INF. Per what I read in Java EE 6 tutorial (CDI) and other articles online, it seems as though beans.xml is supposed to be placed in META-INF, if you have JARs that you've developed that is referenced by the app. I could be saying this incorrectly. :) On Tue, Nov 20, 2012 at 1:57 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Mark, I confirmed and 'opted' to do the same as what you mentioned below, and web app is working fine. I 'moved' beans.xml from WEB-INF to META-INF, and app is running well, and running same as when beans.xml was in WEB-INF. I'll keep beans.xml in META-INF as per your recommendation. *2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1].* Please note, (temporarily) commenting out @Asynchronous method calls in my app most likely resolved the issue in OP. Thanks, Howard On Tue, Nov 20, 2012 at 10:18 AM, Mark Struberg strub...@yahoo.de wrote: Dropping OpenEJB as we are now back to core JSF and related. I don't want to spam them ;) 1.): each container has pros and cons. And each of them needs different workarounds in edge cases :) 2.) I'm not using NetBeans, but it's basically the same scenario. In my project I opted for only using META-INF/beans.xml and completely dropping WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1]. What is a good example or use case for using CDI events? Oh there are plenty! You just need to understand that CDI events != messages. CDI events are _always_ synchronous and only get delivered to beans in currently active contexts. E.g. if you fire a CDI event and have a public @SessionScoped class User then only the contextual instance 'User' from the current session will receive the event. You can think about CDI events as a method invocation where you do not know on which (and how many) instances you invoke it. A practical use case. In our application we have a big fat menu. The menu content is depending on the language of the user and his privileges. Since this can change on a language change or if the user logs in/out, etc most apps always re-calculate the whole MenuItem tree from the database. What we did in our application is the following: Menu is a @SessionScoped cdi bean and we do NOT re-calculate the items for every request. Instead we fire a UserSettingsChangedEvent on each language change and login/logout. In the Menu bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload the menu in that case. This performs vastly better and allows us to radically cache lots of things. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-218 From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: us...@openejb.apache.org us...@openejb.apache.org Sent: Tuesday, November 20, 2012 3:56 PM Subject: Re: Migrating to CDI: @Asynchronous Mark, Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I think I did read that 'asynchronous' (runnable, etc...) tasks are not all that good in web application. So, while you were writing your reply, I was already commenting out the call to the @Asynchronous method, and I reverted to the synchronous version of the method to update Google Calendar. After adding @Asynchronous, I added some logic that works better than @Asynchronous, it will not do a google calendar update on 'every' database update; I have some strategic processing in place that brought the # of google calendar requests down by hundreds and even thousands on a daily average. You know what? I attempted to add to META-INF as well as WEB-INF (some days ago), and
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
Re: Need help in trinidad tree component
Hi Scott,
I solved that problem. It was basically java Script problem that has been
solved. However two more requirements:
1) I have to expand the tree by clicking the nodes.
2) When the web application will be first loaded, then the tree will be
expanded with only first level. That means:
IfA
---B
-D
C
E
is a tree then my requirement is(When application is first loaded):
A
-B
--C
I'm sure it can be done. Can u help me with some direction and sample code?
Thanks
On Mon, Nov 19, 2012 at 12:50 PM, Scott O'Bryan darkar...@gmail.com wrote:
http://myfaces.apache.org/**trinidad/trinidad-api/apidocs/**
org/apache/myfaces/trinidad/**context/RequestContext.htmlhttp://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/context/RequestContext.html
Look up addPartialTarget.
To do it declaratively you need to look in the tag doc under
partialTriggers.
Hope that helps.
Scott
On Mon Nov 19 10:45:45 2012, Muhibbul Chowdhury wrote:
Hi,
Thanks. Can you please send a sample code how to add trinidad
component as a partial target?
On Mon, Nov 19, 2012 at 11:29 AM, Scott O'Bryan darkar...@gmail.com
mailto:darkar...@gmail.com wrote:
I don't have time to look through the entire thing, but I think if
you add your tree component as a partial target, it might give you
what you want. I believe your model is being updated properly but
I'm not sure the changes to the component are being sent. This is
just a quick suggestion based on the symptom.
On Thu Nov 15 15:03:20 2012, muhibd23 wrote:
Hello,
I am working on a web application. Everything is working fine.
I just need a
simple help. I have populated a tree using JSF/trinidad tree
component.
However, I want to expand the tree branches by clicking (+)
sign and
collapse the tree branches by clicking (-) sign. It's not
working properly.
What's happening is that, I have to click the (+) sign and
then click the
root node to expand the next branch. Similarly, While
collapsing, I have to
click the (-) sign and then click the child node to collapse
it, but I want
to expand/ collapse nodes by clicking (+) or (-) sign.
My jsp side code:
trh:cellFormat valign=top
tr:panelHeader
script type=text/javascript
src=CollapsibleLists.js/__**script
tr:tree var=node
value=#{fileTreeHandler.__**treeModel}
f:facet name=nodeStamp
tr:panelGroupLayout
tr:commandLink text =
#{node.description}
actionListener=#{__**fileTreeHandler.downloadFile}**__/
/tr:panelGroupLayout
/f:facet
/tr:tree
/tr:panelHeader
/trh:cellFormat
Here is the filetreehandler code:
import org.acegisecurity.__**Authentication;
import org.acegisecurity.context.__**SecurityContextHolder;
import org.apache.log4j.Logger;
import org.apache.myfaces.trinidad.__**
component.core.data.CoreTree;
import org.apache.myfaces.trinidad.__**event.FocusEvent;
import org.apache.myfaces.trinidad.__**
model.ChildPropertyTreeModel;
import org.apache.myfaces.trinidad.__**model.RowKeySet;
import org.apache.myfaces.trinidad.__**model.TreeModel;
import javax.faces.context.__**ExternalContext;
import javax.faces.context.__**FacesContext;
import javax.servlet.http.__**HttpServletResponse;
import java.io.*;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
/**
* A Simple tree model used to create a graphical tree
representation for a
* given directory.
*
* @author Ric Smith, Oracle Corp.
*/
@SessionScoped
public class FileTreeHandler implements Serializable {
/** Apache tree model. */
private TreeModel treeModel;
private static final long serialVersionUID = 1L;
/** Was a node found. */
private boolean foundDirectory = false;
//private RowKeySet disclosedEntries;
private CoreTree tree;
private Object clickedNodeRowKey;
/** Logging for the class. */
private Logger logger = Logger.getLogger(this.__**
getClass());
/**
* Constructor.
* Reads the given directory.
Migration to TomEE/CODI: very strange AJAX issue during regression testing
You all know by now that I recently migrated *FROM*: Glassfish 3.1.2.2, MyFaces 2.1.9, and JSF Managed beans *TO*: TomEE 1.5 SNAPSHOT, Apache MyFaces CDI Extensions 1.0.6 (CODI), and CDI managed beans So, I am regression testing, and I am experiencing a very very strange issue with *TomEE/CODI* (development/test environment) that I have never seen with *Glassfish 3.1.2.2 *and* MyFaces 2.1.9* (currently in production). Attached you will find screen captures: 1. Page that shows *FROM* and *TO* (PrimeFaces) p:calendar components (jQuery DatePicker) that has *button* beside the textInput 2. Page that shows FROM and TO p:calendar components *without the button*beside textInput; this is an issue and *not* working as designed; this happens *sporadically after AJAX update*on the page, after I click the p:calendar button to update the data on the page via AJAX Someone please open an issue for this, and let me know if this is a TomEE/OpenEJB issue *or* MyFaces Core 2.1.9 and CODI issue. This is the reason why I am sending this email to both user mail lists. Thanks, Howard
Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing
The following is the XHTML for the *FROM* and *TO* p:calendar components in
PrimeFaces p:dataTable component. Please note that the *mode=popup
showOn=button* is hardcoded in the xhtml below, and is not conditionally
dependent on EL.
As the screen captures will show, I am testing this via my test/development
server, so please do not think I'm testing from iPad (since there is EL for
iPad devices below).
This issue is not happening in the Production environment (Glassfish
3.1.2.2 and MyFaces Core 2.1.9).
p:calendar id=filterTripDateFrom
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
h:outputText value=To: /
p:calendar id=filterTripDateTo
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn pattern=MM/dd/
size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
On Wed, Nov 21, 2012 at 3:06 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
You all know by now that I recently migrated
*FROM*: Glassfish 3.1.2.2, MyFaces 2.1.9, and JSF Managed beans
*TO*: TomEE 1.5 SNAPSHOT, Apache MyFaces CDI Extensions 1.0.6 (CODI), and
CDI managed beans
So, I am regression testing, and I am experiencing a very very strange
issue with *TomEE/CODI* (development/test environment) that I have never
seen with *Glassfish 3.1.2.2 *and* MyFaces 2.1.9* (currently in
production).
Attached you will find screen captures:
1. Page that shows *FROM* and *TO* (PrimeFaces) p:calendar components
(jQuery DatePicker) that has *button* beside the textInput
2. Page that shows FROM and TO p:calendar components *without the
button* beside textInput; this is an issue and *not* working as
designed; this happens *sporadically after AJAX update* on the page,
after I click the p:calendar button to update the data on the page via AJAX
Someone please open an issue for this, and let me know if this is a
TomEE/OpenEJB issue *or* MyFaces Core 2.1.9 and CODI issue. This is the
reason why I am sending this email to both user mail lists.
Thanks,
Howard
Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing
I removed Apache CODI JARs from classpath and duplicated this issue, so
this may be a TomEE/OpenEJB (OpenWebBeans) issue.
Please confirm.
Thanks,
Howard
On Wed, Nov 21, 2012 at 3:19 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
The following is the XHTML for the *FROM* and *TO* p:calendar components
in PrimeFaces p:dataTable component. Please note that the *mode=popup
showOn=button* is hardcoded in the xhtml below, and is not
conditionally dependent on EL.
As the screen captures will show, I am testing this via my
test/development server, so please do not think I'm testing from iPad
(since there is EL for iPad devices below).
This issue is not happening in the Production environment (Glassfish
3.1.2.2 and MyFaces Core 2.1.9).
p:calendar id=filterTripDateFrom
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
h:outputText value=To: /
p:calendar id=filterTripDateTo
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn pattern=MM/dd/
size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
On Wed, Nov 21, 2012 at 3:06 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
You all know by now that I recently migrated
*FROM*: Glassfish 3.1.2.2, MyFaces 2.1.9, and JSF Managed beans
*TO*: TomEE 1.5 SNAPSHOT, Apache MyFaces CDI Extensions 1.0.6 (CODI),
and CDI managed beans
So, I am regression testing, and I am experiencing a very very strange
issue with *TomEE/CODI* (development/test environment) that I have never
seen with *Glassfish 3.1.2.2 *and* MyFaces 2.1.9* (currently in
production).
Attached you will find screen captures:
1. Page that shows *FROM* and *TO* (PrimeFaces) p:calendar components
(jQuery DatePicker) that has *button* beside the textInput
2. Page that shows FROM and TO p:calendar components *without the
button* beside textInput; this is an issue and *not* working as
designed; this happens *sporadically after AJAX update* on the page,
after I click the p:calendar button to update the data on the page via
AJAX
Someone please open an issue for this, and let me know if this is a
TomEE/OpenEJB issue *or* MyFaces Core 2.1.9 and CODI issue. This is the
reason why I am sending this email to both user mail lists.
Thanks,
Howard
TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI
Is it really necessary or encouraged to use Apache MyFaces CODI with TomEE 1.5 (SNAPSHOT)? Any pros/cons, advantages/disadvantages using them both together? TomEE bundles MyFaces Core 2.1.9 and OpenEJB, but Apache MyFaces CODI is 'not' bundled with TomEE, for some reason or another. I've seen blogs encourage JSF developers to 'at least' use latest MyFaces Core version and OpenWebBeans for performance reasons, but I don't think I saw encouragement to use Apache MyFaces CODI. Thanks, Howard
Re: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI
Maybe you should look at the CODi wiki and understand what CODI provides. If you don't like it, don't use it. This isn't a required lib. 2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com Is it really necessary or encouraged to use Apache MyFaces CODI with TomEE 1.5 (SNAPSHOT)? Any pros/cons, advantages/disadvantages using them both together? TomEE bundles MyFaces Core 2.1.9 and OpenEJB, but Apache MyFaces CODI is 'not' bundled with TomEE, for some reason or another. I've seen blogs encourage JSF developers to 'at least' use latest MyFaces Core version and OpenWebBeans for performance reasons, but I don't think I saw encouragement to use Apache MyFaces CODI. Thanks, Howard
Re: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI
Hi Howard! CODI is a portable CDI _Extension_ and not a CDI container! CODI runs on Weld, OpenWebBeans, resin, Glassfish, TomEE, JBossAS, etc 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 9:51 PM Subject: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI Is it really necessary or encouraged to use Apache MyFaces CODI with TomEE 1.5 (SNAPSHOT)? Any pros/cons, advantages/disadvantages using them both together? TomEE bundles MyFaces Core 2.1.9 and OpenEJB, but Apache MyFaces CODI is 'not' bundled with TomEE, for some reason or another. I've seen blogs encourage JSF developers to 'at least' use latest MyFaces Core version and OpenWebBeans for performance reasons, but I don't think I saw encouragement to use Apache MyFaces CODI. Thanks, Howard
Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing
I replaced PrimeFaces 3.5 SNAPSHOT with PrimeFaces 3.4.1 (stable version),
and I am still duplicating this issue in my web app. So, this is *not* a
PrimeFaces 3.4.1 issue.
On Wed, Nov 21, 2012 at 3:45 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
I removed Apache CODI JARs from classpath and duplicated this issue, so
this may be a TomEE/OpenEJB (OpenWebBeans) issue.
Please confirm.
Thanks,
Howard
On Wed, Nov 21, 2012 at 3:19 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
The following is the XHTML for the *FROM* and *TO* p:calendar components
in PrimeFaces p:dataTable component. Please note that the *mode=popup
showOn=button* is hardcoded in the xhtml below, and is not
conditionally dependent on EL.
As the screen captures will show, I am testing this via my
test/development server, so please do not think I'm testing from iPad
(since there is EL for iPad devices below).
This issue is not happening in the Production environment (Glassfish
3.1.2.2 and MyFaces Core 2.1.9).
p:calendar id=filterTripDateFrom
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
h:outputText value=To: /
p:calendar id=filterTripDateTo
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn pattern=MM/dd/
size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
On Wed, Nov 21, 2012 at 3:06 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
You all know by now that I recently migrated
*FROM*: Glassfish 3.1.2.2, MyFaces 2.1.9, and JSF Managed beans
*TO*: TomEE 1.5 SNAPSHOT, Apache MyFaces CDI Extensions 1.0.6 (CODI),
and CDI managed beans
So, I am regression testing, and I am experiencing a very very strange
issue with *TomEE/CODI* (development/test environment) that I have
never seen with *Glassfish 3.1.2.2 *and* MyFaces 2.1.9* (currently in
production).
Attached you will find screen captures:
1. Page that shows *FROM* and *TO* (PrimeFaces) p:calendar
components (jQuery DatePicker) that has *button* beside the textInput
2. Page that shows FROM and TO p:calendar components *without the
button* beside textInput; this is an issue and *not* working as
designed; this happens *sporadically after AJAX update* on the page,
after I click the p:calendar button to update the data on the page via
AJAX
Someone please open an issue for this, and let me know if this is a
TomEE/OpenEJB issue *or* MyFaces Core 2.1.9 and CODI issue. This is the
reason why I am sending this email to both user mail lists.
Thanks,
Howard
Re: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI
Thanks Thomas and Mark. Right now, I have no CODI dependencies, so I'll remove from my app/project, for now. On Wed, Nov 21, 2012 at 3:51 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Is it really necessary or encouraged to use Apache MyFaces CODI with TomEE 1.5 (SNAPSHOT)? Any pros/cons, advantages/disadvantages using them both together? TomEE bundles MyFaces Core 2.1.9 and OpenEJB, but Apache MyFaces CODI is 'not' bundled with TomEE, for some reason or another. I've seen blogs encourage JSF developers to 'at least' use latest MyFaces Core version and OpenWebBeans for performance reasons, but I don't think I saw encouragement to use Apache MyFaces CODI. Thanks, Howard
Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing
I think I just solved this issue as follows:
*CAUSED BY:* p:calendar *readonlyInput=#{pf_usersController.loggedInViaIpad
== 'Y' ? 'true' : 'false'}*
1. Glassfish 3.1.2.2 and MyFaces Core 2.1.9 handles that perfectly
2. OpenWebBeans and MyFaces Core 2.1.9 seem to struggle with that EL for
whatever reason
3. So, I made it easy on OpenWebBeans and moved that EL to
rendered=..., and conditionally render separate components with a
readonlyInput=true only for iPad device/endusers
*CODE CHANGES* below:
h:outputText value=From: /
p:calendar id=filterTripDateFrom
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
rendered=#{pf_usersController.loggedInViaIpad == 'N'}
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
p:calendar id=filterTripDateFromOnIpad
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button readonlyInput=true
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
rendered=#{pf_usersController.loggedInViaIpad == 'Y'}
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
h:outputText value=To: /
p:calendar id=filterTripDateTo
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button
navigator=true effect=fadeIn pattern=MM/dd/ size=10
rendered=#{pf_usersController.loggedInViaIpad == 'N'}
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
p:calendar id=filterTripDateToOnIpad
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button readonlyInput=true
navigator=true effect=fadeIn pattern=MM/dd/ size=10
rendered=#{pf_usersController.loggedInViaIpad == 'Y'}
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
On Wed, Nov 21, 2012 at 3:19 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
The following is the XHTML for the *FROM* and *TO* p:calendar components
in PrimeFaces p:dataTable component. Please note that the *mode=popup
showOn=button* is hardcoded in the xhtml below, and is not
conditionally dependent on EL.
As the screen captures will show, I am testing this via my
test/development server, so please do not think I'm testing from iPad
(since there is EL for iPad devices below).
This issue is not happening in the Production environment (Glassfish
3.1.2.2 and MyFaces Core 2.1.9).
p:calendar id=filterTripDateFrom
value=#{pf_ordersController.filterTripDateFrom}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn
pattern=MM/dd/ size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateFromSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
h:outputText value=To: /
p:calendar id=filterTripDateTo
value=#{pf_ordersController.filterTripDateTo}
mode=popup showOn=button
readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' ? 'true' :
'false'}
navigator=true effect=fadeIn pattern=MM/dd/
size=10
p:ajax partialSubmit=false
event=dateSelect
listener=#{pf_ordersController.filterTripDateToSelected}
update=:ordersBrowseForm:ordersDataTable
:ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
/p:calendar
On Wed, Nov 21, 2012 at 3:06 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:
You all know by now that I recently migrated
*FROM*: Glassfish 3.1.2.2, MyFaces 2.1.9, and JSF Managed beans
*TO*: TomEE 1.5 SNAPSHOT, Apache MyFaces CDI Extensions 1.0.6 (CODI),
and CDI managed beans
So, I am regression testing, and I am experiencing a very very strange
issue with *TomEE/CODI* (development/test environment) that I have never
seen with *Glassfish 3.1.2.2 *and* MyFaces 2.1.9* (currently in
production).
Attached you will find screen captures:
1. Page that shows *FROM* and *TO* (PrimeFaces) p:calendar components
(jQuery DatePicker) that has *button* beside the textInput
2. Page that shows FROM and TO p:calendar
