Re: Apache CODI x JEE7 Glassfish4
what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Re: Apache CODI x JEE7 Glassfish4
yea, but that is minor tho what CODI can do. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:24 Subject: Re: Apache CODI x JEE7 Glassfish4 @mark: the parameter conversationPropagation was added in 1.1. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de Nope, we didn't touch @ConversationScoped a bit in CDI-1.1. The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. LieGrue, strub - Original Message - From: Kay Wrobel kay.wro...@gmx.net To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, 30 October 2013, 22:44 Subject: Re: Apache CODI x JEE7 Glassfish4 One could still investigate if @ConversatioScoped has improved in CDI 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the right person to discuss that annotation, but it's a thought. On 10/30/2013 04:33 PM, Gerhard Petracek wrote: hi edilmar, apache deltaspike is the official successor of codi/seam/... (including support for ee7+). some parts (including codi-conversations) are still on our list, however, you can try it with [1] (it's the same code - just different packages and based on deltaspike). @kay (and your comment about conversations): std. cdi conversations are available since cdi 1.0 and have many disadvantages compared to codi-conversations. that was the reason for introducing codi-conversations at all (see e.g. [2]) - they are still useful. regards, gerhard [1] http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/30 Edilmar Alves edili...@gmail.com I think CODI is a great replacement for my actual environment, the only problem is to deploy in GF4. 2013/10/30 Edilmar Alves edili...@gmail.com Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.html http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.html http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not simple to upgrade. 2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial server approved by the enterprise, I can't change for other server. Then, I test version 4 because there are some other functionalities I would like to use from JEE7 in my webapp, but with CODI it is not possible to deploy. 3) I didn't understand the suggestion to use Myfaces 2.2. Has it a replacement for the CODI ConversationScoped, for example? Because this scope is used in many pages of my webapp, the main resource from CODI that I use and need an alternative. I can't use Myfaces, for example, to change Richfaces. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last final
Re: Apache CODI x JEE7 Glassfish4
i haven't said something different. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de yea, but that is minor tho what CODI can do. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:24 Subject: Re: Apache CODI x JEE7 Glassfish4 @mark: the parameter conversationPropagation was added in 1.1. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de Nope, we didn't touch @ConversationScoped a bit in CDI-1.1. The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. LieGrue, strub - Original Message - From: Kay Wrobel kay.wro...@gmx.net To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, 30 October 2013, 22:44 Subject: Re: Apache CODI x JEE7 Glassfish4 One could still investigate if @ConversatioScoped has improved in CDI 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the right person to discuss that annotation, but it's a thought. On 10/30/2013 04:33 PM, Gerhard Petracek wrote: hi edilmar, apache deltaspike is the official successor of codi/seam/... (including support for ee7+). some parts (including codi-conversations) are still on our list, however, you can try it with [1] (it's the same code - just different packages and based on deltaspike). @kay (and your comment about conversations): std. cdi conversations are available since cdi 1.0 and have many disadvantages compared to codi-conversations. that was the reason for introducing codi-conversations at all (see e.g. [2]) - they are still useful. regards, gerhard [1] http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/30 Edilmar Alves edili...@gmail.com I think CODI is a great replacement for my actual environment, the only problem is to deploy in GF4. 2013/10/30 Edilmar Alves edili...@gmail.com Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.html http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.html http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not simple to upgrade. 2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial server approved by the enterprise, I can't change for other server. Then, I test version 4 because there are some other functionalities I would like to use from JEE7 in my webapp, but with CODI it is not possible to deploy. 3) I didn't
Re: Apache CODI x JEE7 Glassfish4
I'll try to substitute CODI to DeltaSpike using JEE7/GF4 for test... thanks... I'll return the result here... 2013/10/31 Gerhard Petracek gerhard.petra...@gmail.com i haven't said something different. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de yea, but that is minor tho what CODI can do. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:24 Subject: Re: Apache CODI x JEE7 Glassfish4 @mark: the parameter conversationPropagation was added in 1.1. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de Nope, we didn't touch @ConversationScoped a bit in CDI-1.1. The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. LieGrue, strub - Original Message - From: Kay Wrobel kay.wro...@gmx.net To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, 30 October 2013, 22:44 Subject: Re: Apache CODI x JEE7 Glassfish4 One could still investigate if @ConversatioScoped has improved in CDI 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the right person to discuss that annotation, but it's a thought. On 10/30/2013 04:33 PM, Gerhard Petracek wrote: hi edilmar, apache deltaspike is the official successor of codi/seam/... (including support for ee7+). some parts (including codi-conversations) are still on our list, however, you can try it with [1] (it's the same code - just different packages and based on deltaspike). @kay (and your comment about conversations): std. cdi conversations are available since cdi 1.0 and have many disadvantages compared to codi-conversations. that was the reason for introducing codi-conversations at all (see e.g. [2]) - they are still useful. regards, gerhard [1] http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/30 Edilmar Alves edili...@gmail.com I think CODI is a great replacement for my actual environment, the only problem is to deploy in GF4. 2013/10/30 Edilmar Alves edili...@gmail.com Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.html http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.html http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not
Re: Apache CODI x JEE7 Glassfish4
I think you called it 'circular injection'[1] and I've seen others call it circular reference, and for whatever reason, I was under the assumption that it was called cyclic reference (ever since i started using CDI). Circular Injection A-B-A [1] Page 26, http://people.apache.org/~struberg/inso2013/INSO_webdev-cdi-2013.pdf On Thu, Oct 31, 2013 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Re: Apache CODI x JEE7 Glassfish4
Circular Injection A-B-A is well supported and is one of the charms with proxies, right? I remember having that when using JSF beans though but it's not something I've seen in CDI cheers On 31 October 2013 14:53, Howard W. Smith, Jr. smithh032...@gmail.comwrote: I think you called it 'circular injection'[1] and I've seen others call it circular reference, and for whatever reason, I was under the assumption that it was called cyclic reference (ever since i started using CDI). Circular Injection A-B-A [1] Page 26, http://people.apache.org/~struberg/inso2013/INSO_webdev-cdi-2013.pdf On Thu, Oct 31, 2013 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Re: Apache CODI x JEE7 Glassfish4
which can result in inifinite loop and stackoverflow error. long time ago, i think I heard that CDI 1.1 would solve the stackoverflow error when developer does circular injection, incorrectly, or maybe I did not read something correctly, when i first started using CDI, and trying to avoid the stackoverflow error caused by circular reference. On Thu, Oct 31, 2013 at 9:53 AM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: I think you called it 'circular injection'[1] and I've seen others call it circular reference, and for whatever reason, I was under the assumption that it was called cyclic reference (ever since i started using CDI). Circular Injection A-B-A [1] Page 26, http://people.apache.org/~struberg/inso2013/INSO_webdev-cdi-2013.pdf On Thu, Oct 31, 2013 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Re: Apache CODI x JEE7 Glassfish4
In some clear cases it's not supported and this has not changed in CDI 1.1. However it's never been a limiting factor for me at least since i normally don't really use dependent beans or any other non normalscoped. From the CDI 1.1 spec: the container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in [normal_scope]. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope. On 31 October 2013 15:01, Howard W. Smith, Jr. smithh032...@gmail.comwrote: which can result in inifinite loop and stackoverflow error. long time ago, i think I heard that CDI 1.1 would solve the stackoverflow error when developer does circular injection, incorrectly, or maybe I did not read something correctly, when i first started using CDI, and trying to avoid the stackoverflow error caused by circular reference. On Thu, Oct 31, 2013 at 9:53 AM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: I think you called it 'circular injection'[1] and I've seen others call it circular reference, and for whatever reason, I was under the assumption that it was called cyclic reference (ever since i started using CDI). Circular Injection A-B-A [1] Page 26, http://people.apache.org/~struberg/inso2013/INSO_webdev-cdi-2013.pdf On Thu, Oct 31, 2013 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Re: Apache CODI x JEE7 Glassfish4
okay, understood, thanks Karl. i have learned how to avoid the stackoverflow error caused by circular injection, but just recently, I made a change in my software/project, and i experienced the stackoverflow error, and at first, i did not know what caused the exception, but then I ran a local test, and read the stacktrace...in netbeans error/output console...on my development server. the stacktrace (on the production server) was a bit too long for me to decipher; evidently, tomee/tomcat localhost log and/or stderr/catalina logs are easier to read in netbeans output/error console for tomee server. :) On Thu, Oct 31, 2013 at 10:31 AM, Karl Kildén karl.kil...@gmail.com wrote: In some clear cases it's not supported and this has not changed in CDI 1.1. However it's never been a limiting factor for me at least since i normally don't really use dependent beans or any other non normalscoped. From the CDI 1.1 spec: the container is required to support circularities in the bean dependency graph where at least one bean participating in every circular chain of dependencies has a normal scope, as defined in [normal_scope]. The container is not required to support circular chains of dependencies where every bean participating in the chain has a pseudo-scope. On 31 October 2013 15:01, Howard W. Smith, Jr. smithh032...@gmail.com wrote: which can result in inifinite loop and stackoverflow error. long time ago, i think I heard that CDI 1.1 would solve the stackoverflow error when developer does circular injection, incorrectly, or maybe I did not read something correctly, when i first started using CDI, and trying to avoid the stackoverflow error caused by circular reference. On Thu, Oct 31, 2013 at 9:53 AM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: I think you called it 'circular injection'[1] and I've seen others call it circular reference, and for whatever reason, I was under the assumption that it was called cyclic reference (ever since i started using CDI). Circular Injection A-B-A [1] Page 26, http://people.apache.org/~struberg/inso2013/INSO_webdev-cdi-2013.pdf On Thu, Oct 31, 2013 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: what do you mean with cyclic reference issue? there is no such thing for @NormalScoped beans, and for @Dependent it will never work. LieGrue, strub From: Howard W. Smith, Jr. smithh032...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:12 Subject: Re: Apache CODI x JEE7 Glassfish4 Mark, On Wed, Oct 30, 2013 at 7:05 PM, Mark Struberg strub...@yahoo.de wrote: The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. Hmmm, I thought I heard that CDI-1.1 would address the cyclic reference issue that occurs when using CDI. I have been using tomee/openwebbeans, and I made a change in my software/app that exposed that the cyclic reference issue still occurs. will OWB or CDI 1.1 (or future versions) address the cyclic reference issue, or is this up to the developer to ensure their software avoids the issue?
Performance params
Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: Performance params
Hi Kito 2013/10/31 Kito Mann kito.m...@virtua.com Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? This param avoids execute JSF 1.0 EL code, and disable jsp vdl, so EL expressions runs faster. The effect in performance is small but noticeable. · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? This flag enables ids storage at facelet handler level. The effect is it increase the size of the compiled facelet in memory (because all generated ids for the compiled facelet are stored in that level) but it gives a significant performance improvement in both memory and speed. In 2.1.x/2.0.x it is disabled by default, but in 2.2.x the idea is enable it by default, because there are no side effects, and the current code has been well tested. regards, Leonardo Uribe ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: Performance params
Kito, Since Leonardo answered your question, and since subject/title = performance params, I will go ahead and pass on performance params that are in my web.xml. See comments, and the URLs provided below as well. One of the outstanding Apache/PrimeFaces committers wrote the blog, and I am always happy to share and/or pass along. Hope it helps. When you read the context params below, you will see that I'm using high performance JUEL, OpenWebBeans, and MyFaces...of course. :) context-param param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name param-valuede.odysseus.el.ExpressionFactoryImpl/param-value /context-param context-param param-nameorg.apache.myfaces.EL_RESOLVER_COMPARATOR/param-name param-valueorg.apache.myfaces.el.unified.OpenWebBeansELResolverComparator/param-value /context-param context-param param-nameorg.apache.myfaces.COMPRESS_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value10/param-value /context-param context-param param-nameorg.apache.myfaces.SERIALIZE_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.SUPPORT_JSP_AND_FACES_EL/param-name param-valuefalse/param-value /context-param !-- Increase your JSF application performance (Part 1 - Environment Configuration) http://tandraschko.blogspot.de/2012/08/increase-your-jsf-application.html -- context-param param-namejavax.faces.FACELETS_REFRESH_PERIOD/param-name param-value-1/param-value /context-param context-param param-nameorg.apache.myfaces.CHECK_ID_PRODUCTION_MODE/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.SAVE_STATE_WITH_VISIT_TREE_ON_PSS/param-name param-valuefalse/param-value /context-param !-- https://cwiki.apache.org/MYFACES/cache-el-expressions.html -- context-param param-nameorg.apache.myfaces.CACHE_EL_EXPRESSIONS/param-name param-valuealways/param-value /context-param On Thu, Oct 31, 2013 at 6:25 PM, Kito Mann kito.m...@virtua.com wrote: Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: Performance params
Thanks for the clarification, Leonardo. ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Oct 31, 2013 at 7:24 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Kito 2013/10/31 Kito Mann kito.m...@virtua.com Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? This param avoids execute JSF 1.0 EL code, and disable jsp vdl, so EL expressions runs faster. The effect in performance is small but noticeable. · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? This flag enables ids storage at facelet handler level. The effect is it increase the size of the compiled facelet in memory (because all generated ids for the compiled facelet are stored in that level) but it gives a significant performance improvement in both memory and speed. In 2.1.x/2.0.x it is disabled by default, but in 2.2.x the idea is enable it by default, because there are no side effects, and the current code has been well tested. regards, Leonardo Uribe ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: Performance params
Thanks for the info, Howard. I'm pretty familiar with everything there, with the exception of JUEL. That might make a big difference for one of my clients, and it looks like we can get it running in WebSphere... ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Oct 31, 2013 at 7:46 PM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Kito, Since Leonardo answered your question, and since subject/title = performance params, I will go ahead and pass on performance params that are in my web.xml. See comments, and the URLs provided below as well. One of the outstanding Apache/PrimeFaces committers wrote the blog, and I am always happy to share and/or pass along. Hope it helps. When you read the context params below, you will see that I'm using high performance JUEL, OpenWebBeans, and MyFaces...of course. :) context-param param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name param-valuede.odysseus.el.ExpressionFactoryImpl/param-value /context-param context-param param-nameorg.apache.myfaces.EL_RESOLVER_COMPARATOR/param-name param-valueorg.apache.myfaces.el.unified.OpenWebBeansELResolverComparator/param-value /context-param context-param param-nameorg.apache.myfaces.COMPRESS_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value10/param-value /context-param context-param param-nameorg.apache.myfaces.SERIALIZE_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.SUPPORT_JSP_AND_FACES_EL/param-name param-valuefalse/param-value /context-param !-- Increase your JSF application performance (Part 1 - Environment Configuration) http://tandraschko.blogspot.de/2012/08/increase-your-jsf-application.html -- context-param param-namejavax.faces.FACELETS_REFRESH_PERIOD/param-name param-value-1/param-value /context-param context-param param-nameorg.apache.myfaces.CHECK_ID_PRODUCTION_MODE/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.SAVE_STATE_WITH_VISIT_TREE_ON_PSS/param-name param-valuefalse/param-value /context-param !-- https://cwiki.apache.org/MYFACES/cache-el-expressions.html -- context-param param-nameorg.apache.myfaces.CACHE_EL_EXPRESSIONS/param-name param-valuealways/param-value /context-param On Thu, Oct 31, 2013 at 6:25 PM, Kito Mann kito.m...@virtua.com wrote: Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
