from:"Howard W. Smith, Jr."

Karl, does this fix your issue and or meet your requirements? Looking
forward to your response. I'm sure others are, too. :-)

Can you refactor your code, so it is not dependent on c:forEach? Maybe
Leonardo can advise on that, too.
On Mar 9, 2014 9:24 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 @MYFACES-3865 It was fixed in 2.2.1, and the artifacts will be released
 in no time. The fix for c:forEach was really complex and painful, but it
 was finally done and the result is the best option we will have. Finally
 we have a proper solution that will work in complex cases and will
 allow all facelets dinamic tags to work well together.

 The hack done for:

 org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY

 Is meant for people that requires the old (and buggy) logic from facelets
 1.1.x, so it is expected to do not work in some cases.

 My personal perception is 2.2.1 will be very stable, it is obvious to have
 some small bugs, but in this release we created a lot of junit tests, so
 the probability of find bugs has become small. Anyway, we will be eager
 to check and fix all new issues as soon as possible.

 regards,

 Leonardo Uribe

 2014-03-09 18:26 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com:
  On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr wrote:
 
  I found 2.2 to be very stable, almost a drop in replacement for 2.1.
 
 
  +1
 
  I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and MyFaces
  2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied
  with myFaces 2.2.0, and i have had 'no' issues at all. :)

Re: 2.2 stability

response inline,

On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Hi Howard,

 If someone proposed a fix for me I must have missed it, so no my issues are
 still not resolved unfortunately. I don't think it's possible to write it
 in another fashion.


Leonardo's response, asking you to try MyFaces 2.2.1, which was released
within the last 12 to 24 hours. :)



 Problem #1: enctype=multipart/form-data not working. Not sure if anyone
 tried the demo app I linked in the jira but for now I can't investigate it
 any further on my own.


i don't think Leonardo's response was targeting this issue.
maybe/hopefully, Leonardo will respond at his earliest convenience.
earlier, did you say that this issue is resolved via Mojarra 2.2.x (and
some other container... glassfish, jboss, ...) ???



 Problem #2 I also have a problem with duplicated id's but it would take
 some time to reproduce it in a demo app so I'm hesitant to bring it up.
 Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some
 bindings :-)


did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is
fixed in your app/project?

is it best to assume that c:forEach is supposed to work with/via AJAX PPR?
just because Mojarra 'works', should we assume that Mojarra's
implementation is correct?

MyFaces and TomEE committers know that there MyFaces may be a bit more
'strict' than Mojarra (I can agree with that as well, as per my experience
when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces
(and TomEE) committers question the fact that Mojarra is really meeting
requirements of the spec, or there is a different set of TCKs that Mojarra
is running against. I hope 'they' will confirm, clarify, or correct what
I'm stating here. :)

Re: 2.2.0 and multipart

Leonardo Uribe, see below. I think this is the thread where Karl discussed
his fileUpload issue, and shared a test case (below), too.




On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Leonardo Uribe, Thanks for doing a test with this already.

 Everyone, this is how I reproduced it in a test project:


- Cloned Gerhards template
 project:https://github.com/os890/javaweb-cdi-ds-project-template
- Ran with mvn clean install jetty:run -
http://localhost:8080/javaweb-cdi-ds-project-template/helloWorld.xhtml-
 
 Wrote my name and pressed Press Me and it successfully navigated.
- Changed helloWorld.xhtml and added enctype=multipart/form-data to
the form.
- Ran project with mvn clean install jetty:run - it does not work
- Ran project with mvn clean install jetty:run -Pmojarra - works (Note
that mojarra profile is used)


 To conclude with a normal form Gerhards project template works just fine.
 It works fine with mojarra in either case. With Myfaces and
 enctype=multipart/form-data it does not work.

 I tried this several times with the same result.

 Deltaspike and Myfaces is what's in common with my normal stack. No
 Primefaces needed for reproduce

 cheers







 On 4 March 2014 14:58, Karl Kildén karl.kil...@gmail.com wrote:

  Well for me it breaks the form completely. Even if I have only a single
  component h:commandButton/ it's broke. Adding the primefaces parameter
  has no effect. I will try to put a test application together
 
 
  On 4 March 2014 14:17, Leonardo K. Shikida shik...@gmail.com wrote:
 
  Karl
 
  I haven't tested it, but Howard figured out that it may be a primefaces
  problem in their autodetection algorithm
 
  I haven't tested myself yet, but it seems it's just a matter of adding
  this
  parameter explicitly
 
  context-param
  param-nameprimefaces.UPLOADER/param-name
param-valuecommons/param-value
  /context-param
 
  best regards
 
  Leo
 
 
  []
 
  Leo
 
 
  On Tue, Mar 4, 2014 at 4:37 AM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   Leo,
  
   I have the same problem, What's your status?
  
   cheers
  
  
   On 22 February 2014 02:58, Leonardo K. Shikida shik...@gmail.com
  wrote:
  
Hi
   
Just noticed this thread about tomee, myfacs 2.2.0 and multipart
  request
   
   
   
  
 
 stackoverflow.com/questions/21948228/how-to-get-jsf-file-upload-to-work-on-tomee-1-6
   
does anyone know if between 2.1.13 and 2.2.0, multipart request has
  got
   any
new bug? could not find anything in JIRA
   
the guy who posted the stackoverflow question tested with
   
h:commandButton while I've reproduced the problem just switching
myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using
p:fileUpload
   
[]
   
Leo

Re: 2.2.0 and multipart

Karl, did you see the email below, and did you try that sample, and did
that work for you?



On Tue, Mar 4, 2014 at 10:30 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 wow, okay. :)

 Earlier, Leonardo Uribe mentioned the following:

 I can confirm a simple example using MyFaces 2.2.0 works. See:

 http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/

 Looking forward to hearing why your/Karl's test case does not work.



 On Tue, Mar 4, 2014 at 10:26 AM, Karl Kildén karl.kil...@gmail.comwrote:

 Removing deltaspike has no effect. / Karl


 On 4 March 2014 16:23, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  Have you reported this to Deltaspike? I wonder what happens when you
  'remove' delta spike from the equation/mix, and see if stuff/stack
 starts
  working. :)
 
 
 
  On Tue, Mar 4, 2014 at 9:55 AM, Karl Kildén karl.kil...@gmail.com
 wrote:
 
   It made no difference for me / Karl
  
  
   On 4 March 2014 15:52, Karl Kildén karl.kil...@gmail.com wrote:
  
Nice spot, In my production environment I changed it but I will test
  that
aspect in the template project
   
   
On 4 March 2014 15:50, Howard W. Smith, Jr. smithh032...@gmail.com
   wrote:
   
On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén karl.kil...@gmail.com
 
wrote:
   
 Everyone, this is how I reproduced it in a test project:


- Cloned Gerhards template
 project:https://github.com/os890/javaweb-cdi-ds-project-template

   
h,
   
examining the faces-config.xml, i see 2.0 specified instead of 2.1
 (or
2.2).
   
faces-config version=2.0
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xi=http://www.w3.org/2001/XInclude;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;
   
/faces-config
   
   
When MyFaces 2.2 was released, i don't think I saw any mention of a
'requirement' to update faces-config, accordingly, but it would be
  nice
   to
know if faces-config.xml has to be updated with '2.2' or 2.1.

Re: 2.2 stability

2014-03-09 Thread Howard W. Smith, Jr.

On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr wrote:

 I found 2.2 to be very stable, almost a drop in replacement for 2.1.


+1

I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and MyFaces
2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied
with myFaces 2.2.0, and i have had 'no' issues at all. :)

Re: 2.2.0 and multipart

On Tue, Mar 4, 2014 at 8:58 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Well for me it breaks the form completely.


interesting. please clarify this statement... breaks the form completely.


 Even if I have only a single component h:commandButton/ it's broke.


i'm definitely interested in seeing this h:form and h:commandbutton (and
p:fileUpload) xhtml syntax.


Adding the primefaces parameter has no effect. I will try to put a test
 application together


Karl,

Below is my xhtml, which is PrimeFaces 3.x FileUpload syntax. The following
code worked with PrimeFaces 3.x (and PrimeFaces 4.0.x and MyFaces 2.1.13),
but it stopped working when I added MyFaces 2.2 to my PrimeFaces 4.0.x
project/app.

h:form id=fileUploadForm enctype=multipart/form-data
p:panel header=Upload attachment
p:fileUpload value=#{orderDocumentBean.uploadedFile}
mode=simple /
p:commandLink value=Upload File ajax=false
onclick=displayLoadingImage(true)

 actionListener=#{orderDocumentBean.uploadAttachment()}/
/p:panel
/h:form

Once I specified 'commons' for PrimeFaces uploader context param in web.xml
(after upgrading to Apache commons fileupload 1.3 JAR), the xhtml 'above'
started working again.

Re: 2.2.0 and multipart

On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Everyone, this is how I reproduced it in a test project:


- Cloned Gerhards template
 project:https://github.com/os890/javaweb-cdi-ds-project-template


h,

examining the faces-config.xml, i see 2.0 specified instead of 2.1 (or 2.2).

faces-config version=2.0
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xi=http://www.w3.org/2001/XInclude;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;

/faces-config


When MyFaces 2.2 was released, i don't think I saw any mention of a
'requirement' to update faces-config, accordingly, but it would be nice to
know if faces-config.xml has to be updated with '2.2' or 2.1.

Re: 2.2.0 and multipart

Have you reported this to Deltaspike? I wonder what happens when you
'remove' delta spike from the equation/mix, and see if stuff/stack starts
working. :)



On Tue, Mar 4, 2014 at 9:55 AM, Karl Kildén karl.kil...@gmail.com wrote:

 It made no difference for me / Karl


 On 4 March 2014 15:52, Karl Kildén karl.kil...@gmail.com wrote:

  Nice spot, In my production environment I changed it but I will test that
  aspect in the template project
 
 
  On 4 March 2014 15:50, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:
 
  On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   Everyone, this is how I reproduced it in a test project:
  
  
  - Cloned Gerhards template
   project:https://github.com/os890/javaweb-cdi-ds-project-template
  
 
  h,
 
  examining the faces-config.xml, i see 2.0 specified instead of 2.1 (or
  2.2).
 
  faces-config version=2.0
  xmlns=http://java.sun.com/xml/ns/javaee;
  xmlns:xi=http://www.w3.org/2001/XInclude;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;
 
  /faces-config
 
 
  When MyFaces 2.2 was released, i don't think I saw any mention of a
  'requirement' to update faces-config, accordingly, but it would be nice
 to
  know if faces-config.xml has to be updated with '2.2' or 2.1.

Re: 2.2.0 and multipart

wow, okay. :)

Earlier, Leonardo Uribe mentioned the following:

I can confirm a simple example using MyFaces 2.2.0 works. See:

http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/

Looking forward to hearing why your/Karl's test case does not work.



On Tue, Mar 4, 2014 at 10:26 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Removing deltaspike has no effect. / Karl


 On 4 March 2014 16:23, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  Have you reported this to Deltaspike? I wonder what happens when you
  'remove' delta spike from the equation/mix, and see if stuff/stack starts
  working. :)
 
 
 
  On Tue, Mar 4, 2014 at 9:55 AM, Karl Kildén karl.kil...@gmail.com
 wrote:
 
   It made no difference for me / Karl
  
  
   On 4 March 2014 15:52, Karl Kildén karl.kil...@gmail.com wrote:
  
Nice spot, In my production environment I changed it but I will test
  that
aspect in the template project
   
   
On 4 March 2014 15:50, Howard W. Smith, Jr. smithh032...@gmail.com
   wrote:
   
On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén karl.kil...@gmail.com
wrote:
   
 Everyone, this is how I reproduced it in a test project:


- Cloned Gerhards template
 project:https://github.com/os890/javaweb-cdi-ds-project-template

   
h,
   
examining the faces-config.xml, i see 2.0 specified instead of 2.1
 (or
2.2).
   
faces-config version=2.0
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xi=http://www.w3.org/2001/XInclude;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;
   
/faces-config
   
   
When MyFaces 2.2 was released, i don't think I saw any mention of a
'requirement' to update faces-config, accordingly, but it would be
  nice
   to
know if faces-config.xml has to be updated with '2.2' or 2.1.

Re: 2.2.0 and multipart

2014-03-03 Thread Howard W. Smith, Jr.

On Mar 3, 2014 7:33 AM, Leonardo K. Shikida shik...@gmail.com wrote:

 Hi Howard

 thanks for the answer

You're welcome, Leonardo.


 except for the primefaces.UPLOADER thing, I was using FU 1.3 already and
 the primefaces file upload filter.

FileUpload 1.3, alone, did not solve the issue for me.


 the difference is that I use PF4 community

 I've also noticed from the manual that this parameter is optional (page
192)

 (...)
 FileUpload engine on the server side can either be servlet 3.0 or commons
 fileupload. PrimeFaces
 selects the most appropriate uploader engine by detection and it is
 possible to force one or the other
 usign an optional configuration param.
 context-param
 param-nameprimefaces.UPLOADER/param-name
 param-valueauto|native|commons/param-value
 /context-param
 (...)

 I'm gonna try setting the parameter explicitly, maybe it's a primefaces
 detection problem.

That's where I think the issue is. Auto detection is failing. That's why I
set to Commons, and then it started working.


 thanks!

 Leo


 []

 Leo


 On Sun, Mar 2, 2014 at 8:36 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com
  wrote:

  On Tue, Feb 25, 2014 at 10:20 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   +1 thanks Leonardo for informing the user list about this issue. I am
   using MyFaces 2.2 (and/via TomEE 1.6.1 snapshot) with my JSF web
   application, and I confirmed this bug/issue too in my app. PrimeFaces
4.x
   (simple) fileUpload is no longer working. :(
  
   maybe, it can/should be confirmed if MyFaces 2.2 (basic/simple)
  fileUpload
   works as designed/expected. i have not tested that though/yet.
  
 
  okay, this evening, I spent some time with this.
 
  1. I searched google for
 
  site:forum.primefaces.org fileupload 2.2
 
  2. found the following on PrimeFaces forum
 
  http://forum.primefaces.org/viewtopic.php?f=3t=31210
 
  3. which referenced the following (solution seemed to be too much)
 
 
 
http://stackoverflow.com/questions/17204355/glassfish-4-jsf-2-2-and-primefaces-fileuploadevent-not-working-together/17363970#17363970
 
  4. which referenced the following as a related link,
 
 
 
http://stackoverflow.com/questions/20316773/primefaces-4-0-fileupload-works-with-mojarra-2-2-but-not-myfaces-2-2?rq=1
 
  5. the answer below, motivated me to upgrade from apache commons
fileupload
  1.2.2 to 1.3
 
  http://stackoverflow.com/a/20347508/933054
 
  6. and then I looked at PrimeFaces 4.0 user guide, and recognized
something
  'new' that could be specified in web.xml. So, I added the following to
my
  web.xml,
 
  context-param
  param-nameprimefaces.UPLOADER/param-name
  param-valuecommons/param-value
  /context-param
 
  and finally, PrimeFaces (Elite) 4.0.x works with MyFaces 2.2.
 
  7. as per PrimeFaces 4.0 user guide, I already had the following (FYI,
  below is required if 'commons' fileupload is used)
 
  !-- PrimeFaces FileUpload Filter --
  filter
  filter-namePrimeFaces FileUpload Filter/filter-name
 
 
filter-classorg.primefaces.webapp.filter.FileUploadFilter/filter-class
  /filter
  filter-mapping
  filter-namePrimeFaces FileUpload Filter/filter-name
  servlet-nameFaces Servlet/servlet-name
  /filter-mapping

Re: 2.2.0 and multipart

2014-03-02 Thread Howard W. Smith, Jr.

On Tue, Feb 25, 2014 at 10:20 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 +1 thanks Leonardo for informing the user list about this issue. I am
 using MyFaces 2.2 (and/via TomEE 1.6.1 snapshot) with my JSF web
 application, and I confirmed this bug/issue too in my app. PrimeFaces 4.x
 (simple) fileUpload is no longer working. :(

 maybe, it can/should be confirmed if MyFaces 2.2 (basic/simple) fileUpload
 works as designed/expected. i have not tested that though/yet.


okay, this evening, I spent some time with this.

1. I searched google for

site:forum.primefaces.org fileupload 2.2

2. found the following on PrimeFaces forum

http://forum.primefaces.org/viewtopic.php?f=3t=31210

3. which referenced the following (solution seemed to be too much)

http://stackoverflow.com/questions/17204355/glassfish-4-jsf-2-2-and-primefaces-fileuploadevent-not-working-together/17363970#17363970

4. which referenced the following as a related link,

http://stackoverflow.com/questions/20316773/primefaces-4-0-fileupload-works-with-mojarra-2-2-but-not-myfaces-2-2?rq=1

5. the answer below, motivated me to upgrade from apache commons fileupload
1.2.2 to 1.3

http://stackoverflow.com/a/20347508/933054

6. and then I looked at PrimeFaces 4.0 user guide, and recognized something
'new' that could be specified in web.xml. So, I added the following to my
web.xml,

context-param
param-nameprimefaces.UPLOADER/param-name
param-valuecommons/param-value
/context-param

and finally, PrimeFaces (Elite) 4.0.x works with MyFaces 2.2.

7. as per PrimeFaces 4.0 user guide, I already had the following (FYI,
below is required if 'commons' fileupload is used)

!-- PrimeFaces FileUpload Filter --
filter
filter-namePrimeFaces FileUpload Filter/filter-name

filter-classorg.primefaces.webapp.filter.FileUploadFilter/filter-class
/filter
filter-mapping
filter-namePrimeFaces FileUpload Filter/filter-name
servlet-nameFaces Servlet/servlet-name
/filter-mapping

Re: 2.2.0 and multipart

2014-02-25 Thread Howard W. Smith, Jr.

On Tue, Feb 25, 2014 at 3:20 AM, Werner Punz werner.p...@gmail.com wrote:

 Am 22.02.14 02:58, schrieb Leonardo K. Shikida:

  Hi

 Just noticed this thread about tomee, myfacs 2.2.0 and multipart request

 stackoverflow.com/questions/21948228/how-to-get-jsf-file-
 upload-to-work-on-tomee-1-6

 does anyone know if between 2.1.13 and 2.2.0, multipart request has got
 any
 new bug? could not find anything in JIRA

 the guy who posted the stackoverflow question tested with

 h:commandButton while I've reproduced the problem just switching
 myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using
 p:fileUpload

 []

 Leo

  Hi this could be a new bug, we introduced a fileupload handling with JSF
 2.2 (the h:inputFile tag) maybe the normal multipart request handling was
 broken by the extensions done in this area the best bet is to file a
 bugreport in the myfaces bugtracker https://issues.apache.org/
 jira/browse/MYFACES

 Werner


 +1 thanks Leonardo for informing the user list about this issue. I am
using MyFaces 2.2 (and/via TomEE 1.6.1 snapshot) with my JSF web
application, and I confirmed this bug/issue too in my app. PrimeFaces 4.x
(simple) fileUpload is no longer working. :(

maybe, it can/should be confirmed if MyFaces 2.2 (basic/simple) fileUpload
works as designed/expected. i have not tested that though/yet.

Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?

Karl, p:poll introduces security concerns? Please elaborate/clarify.
Thanks.
On Feb 13, 2014 3:39 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Good suggestion Thomas,

 For myself I would need this:

  1 Hour: Keep session alive with p:poll
  1 Hour: Render p:idleMonitor instead and warn for activity and session
 destroy in x minutes.

 The switch to a idleMonitor would require that you  check the submitted
 request parameters and this way know if poll component triggered the
 request or the user.

 A plain p:poll is unacceptable for our system for security reasons.


 On 13 February 2014 09:26, Thomas Andraschko andraschko.tho...@gmail.com
 wrote:

   I dont know why  how this is so implemented but It is very normal
 that
  the
   user may be busy reading some section of website or be away for 20
  minutes,
as he comes back  interacts with opened pages, how would I make
 that
   work without the state ?
   I think this is a common requirement for any public websites.
 
  You could just add an ajax poll components and ping the server all 5
  minutes - so the session will only be destroyed if all tabs from your
  application are closed.

Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE

I think Leonardo, Gerhard, or one of the other committers may provide her
some good help, just to get another MyFaces user, especially when one is
migrating from Mojarra to MyFaces.

@Renee, +1 your goal/request.

I migrated from Mojarra to MyFaces, first, and then 2 months later, I
migrated from Glassfish to tomee (and JSF managed beans to CDI managed
beans at same time). Thomas, Romain, Mark Struberg, and others provided
great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
are definitely the place to be.

But I didn't have code dependent on the Mojarra library like you do. Still,
it took me about a week to migrate from Mojarra to MyFaces. Thomas and
Leonardo motivated me to start the migration after reading about the
performance comparison between Mojarra and MyFaces. Mark Struberg blog, why
is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)

I love high performance, that's why I opted to use MyFaces, tomee,
OpenWebBeans, and JUEL.

Wishing you much success.
On Feb 13, 2014 7:23 AM, Thomas Andraschko andraschko.tho...@gmail.com
wrote:

 I don't think that anyone will port your complete code and give you a
 complete solution ;)

 The biggest problem is AFAIR that the renderer implementations are not in
 the API packages. So you have to rebuild all this functionality without
 dependencies to the Impl.

 e.g.
 Attribute,AttributeManager - String[] with attribute namens
 Move all the utils functions to your own code (Util.componentIsDisabled,
 RenderKitUtils.getSelectItems. etc.)

 The most code doesn't really depent on the IMPL code.


 2014-02-13 12:44 GMT+01:00 Rene Perschon chummer_r...@gmx.net:

  Hi everyone!
 
  I'm currently migrating an application from Glassfish 3.1.1 to TomEE. Now
  the problem is that this application contains a custom component which
 was
  unfortunately coded with hard dependencies on com.sun.faces classes
 (maven
  dependency jsf-impl).
 
  Now my question is how can i port this component in such a way that it is
  independent from any concrete JSF implementation (or at least in such a
 way
  that it works with MyFaces).
 
  Here's the component:
 
  import java.io.IOException;
  import java.util.Iterator;
  import java.util.Map;
 
  import javax.faces.component.UIComponent;
  import javax.faces.component.UINamingContainer;
  import javax.faces.component.ValueHolder;
  import javax.faces.context.FacesContext;
  import javax.faces.context.ResponseWriter;
  import javax.faces.convert.Converter;
  import javax.faces.model.SelectItem;
  import javax.faces.model.SelectItemGroup;
 
  import com.sun.faces.renderkit.Attribute;
  import com.sun.faces.renderkit.AttributeManager;
  import com.sun.faces.renderkit.RenderKitUtils;
  import com.sun.faces.renderkit.html_basic.MenuRenderer;
  import com.sun.faces.util.RequestStateManager;
  import com.sun.faces.util.Util;
 
  /**
   * {@inheritDoc}.
   */
  public class CustomSelectManyCheckboxListRenderer extends MenuRenderer
  {
  /** {@inheritDoc}. */
  private static final Attribute[] ATTRIBUTES =
  AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
  /** Representing the border string. */
  private static final String BORDER = border;
  /** Representing the tr string. */
  private static final String TR = tr;
  /** Representing the td string. */
  private static final String TD = td;
  /** Representing the label string. */
  private static final String LABEL = label;
  /** Representing the newline string. */
  private static final String NEWLINE = \n;
  /** Representing the tab string. */
  private static final String TAB = \t;
  /** Representing the class string. */
  private static final String CLASS = class;
  /** Representing the style string. */
  private static final String STYLE = style;
  /** Representing the valign string. */
  private static final String VALIGN = valign;
 
 
  // -- Public
  Methods
 
 
  @Override
  public void encodeEnd(FacesContext context, UIComponent component)
  throws IOException
  {
 
  rendererParamsNotNull(context, component);
 
  if (!shouldEncode(component))
  {
  return;
  }
 
  ResponseWriter writer = context.getResponseWriter();
  assert (writer != null);
 
  String alignStr;
  Object borderObj;
  boolean alignVertical = false;
  int border = 0;
 
 
 
  if (null != component.getAttributes().get(layout))
  {
  alignStr = (String) component.getAttributes().get(layout);
  alignVertical = alignStr.equalsIgnoreCase(pageDirection);
  }
 
  if (null != component.getAttributes().get(BORDER))
  {
  borderObj = component.getAttributes().get(BORDER);
  border = (Integer) borderObj;
  }
 
  Converter

Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?

Very interesting, Karl, and thanks for the clarification!

+1 at the responses on this thread. They interested me, because for
security implementation in my app is

- 15 minutes session expiration (web.xml)
- meta refresh tag in head tag that redirects page to view expired 'page'
(got that concept/code from BalusC on stackoverflow.com)

but some months ago, an enduser requested a 'keep-alive session'
requirement on a page that will 'not' end his session while he using the
'payroll' page to do his work. He did not want to have to keep logging in,
and having to make filter selection via p:calendar begin/end dates of
payroll period, and then scroll down to job/employee that was last marked
as paid. So, i found some keep-alive-session code (by BalusC on
stackoverflow.com) and refactored app/page a bit to keep the session alive
until he logs out of the app or until he navigates to another page.

well, now that you all are talking about this, this reminds me of a recent
discussion on tomcat list about (re)designing webapp to allow enduser to
login and resume his work. I like that concept, and that might be the best
approach to address 'security concerns'. There would be no need to p:poll,
p:push, etc... just to keep the session alive or to push a message to
client to 'end' the session and logout user (sometime ago, i developed some
p:push + java bean code that did that, but not using that implementation in
the app).

polling to keep session alive seems to be the easiest way to 'satisfy' the
enduser, but definitely not the most-secure, as you said earlier. this
discussion may motivate me to refactor my app a bit, accordingly. thank you
all!



On Thu, Feb 13, 2014 at 7:07 AM, Karl Kildén karl.kil...@gmail.com wrote:

 It's just that if you just do p:poll every five minutes they are never
 logged out from activity. This has actually caused us to fail a security
 screening in the past.

 1. Users use security system before leaving office, forgets to logout and
 the PC does not lock from inactivity either
 2. In the middle of the night a burglar breaks in and has direct access to
 system because p:poll has kept stuff warm for him
 3. Lose Customer

 To clarify our users might just leave with computer logged on and system
 logged on so session timeout is essential. In general they actually want
 really short session timeouts but the tricky part is that for some pages
 they want 1H or similar. When they work on those pages they can't just lose
 the session so we warn them in advance. Might be enough to just use
 p:idleMonitor. Our solution is homemade because we don't have primefaces in
 that product so I was brainstorming when I mentioned it.

 For us it's DWR that keeps the session alive but in the future it will be
 p:push.

 TLDR:
 If you use p:poll don't forget that users may forget to logout and p:poll
 will disable session timeout.

 On 13 February 2014 12:52, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  Karl, p:poll introduces security concerns? Please elaborate/clarify.
  Thanks.
  On Feb 13, 2014 3:39 AM, Karl Kildén karl.kil...@gmail.com wrote:
 
   Good suggestion Thomas,
  
   For myself I would need this:
  
1 Hour: Keep session alive with p:poll
1 Hour: Render p:idleMonitor instead and warn for activity and
 session
   destroy in x minutes.
  
   The switch to a idleMonitor would require that you  check the submitted
   request parameters and this way know if poll component triggered the
   request or the user.
  
   A plain p:poll is unacceptable for our system for security reasons.
  
  
   On 13 February 2014 09:26, Thomas Andraschko 
  andraschko.tho...@gmail.com
   wrote:
  
 I dont know why  how this is so implemented but It is very normal
   that
the
 user may be busy reading some section of website or be away for 20
minutes,
  as he comes back  interacts with opened pages, how would I make
   that
 work without the state ?
 I think this is a common requirement for any public websites.
   
You could just add an ajax poll components and ping the server all 5
minutes - so the session will only be destroyed if all tabs from your
application are closed.

Re: Re: Problems with a custom component when migrating from Glassfish(mojarra) to TomEE

do you have a screen capture or some type of demo of the Select component?



On Thu, Feb 13, 2014 at 8:39 AM, Rene Perschon chummer_r...@gmx.net wrote:

 I don't think a TagHandler or a custom component can do what that code
 does. It's used to display a Select in a very specific way.



 Gesendet: Donnerstag, 13. Februar 2014 um 14:29 Uhr
 Von: Karl Kildén karl.kil...@gmail.com
 An: MyFaces Discussion users@myfaces.apache.org
 Betreff: Re: Problems with a custom component when migrating from
 Glassfish(mojarra) to TomEE
 Have you considered a custom tagHandler / composite component instead?

 I took a quick look but I don't recognize much sorry.


 On 13 February 2014 14:09, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  I think Leonardo, Gerhard, or one of the other committers may provide her
  some good help, just to get another MyFaces user, especially when one is
  migrating from Mojarra to MyFaces.
 
  @Renee, +1 your goal/request.
 
  I migrated from Mojarra to MyFaces, first, and then 2 months later, I
  migrated from Glassfish to tomee (and JSF managed beans to CDI managed
  beans at same time). Thomas, Romain, Mark Struberg, and others provided
  great help and motivation. Apache tomee, MyFaces, tomcat user mail lists
  are definitely the place to be.
 
  But I didn't have code dependent on the Mojarra library like you do.
 Still,
  it took me about a week to migrate from Mojarra to MyFaces. Thomas and
  Leonardo motivated me to start the migration after reading about the
  performance comparison between Mojarra and MyFaces. Mark Struberg blog,
 why
  is OpenWebBeans so fast, motivated me to migrate to CDI and tomee. :-)
 
  I love high performance, that's why I opted to use MyFaces, tomee,
  OpenWebBeans, and JUEL.
 
  Wishing you much success.
  On Feb 13, 2014 7:23 AM, Thomas Andraschko 
 andraschko.tho...@gmail.com
  wrote:
 
   I don't think that anyone will port your complete code and give you a
   complete solution ;)
  
   The biggest problem is AFAIR that the renderer implementations are not
 in
   the API packages. So you have to rebuild all this functionality without
   dependencies to the Impl.
  
   e.g.
   Attribute,AttributeManager - String[] with attribute namens
   Move all the utils functions to your own code
 (Util.componentIsDisabled,
   RenderKitUtils.getSelectItems. etc.)
  
   The most code doesn't really depent on the IMPL code.
  
  
   2014-02-13 12:44 GMT+01:00 Rene Perschon chummer_r...@gmx.net:
  
Hi everyone!
   
I'm currently migrating an application from Glassfish 3.1.1 to TomEE.
  Now
the problem is that this application contains a custom component
 which
   was
unfortunately coded with hard dependencies on com.sun.faces classes
   (maven
dependency jsf-impl).
   
Now my question is how can i port this component in such a way that
 it
  is
independent from any concrete JSF implementation (or at least in
 such a
   way
that it works with MyFaces).
   
Here's the component:
   
import java.io.IOException;
import java.util.Iterator;
import java.util.Map;
   
import javax.faces.component.UIComponent;
import javax.faces.component.UINamingContainer;
import javax.faces.component.ValueHolder;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.convert.Converter;
import javax.faces.model.SelectItem;
import javax.faces.model.SelectItemGroup;
   
import com.sun.faces.renderkit.Attribute;
import com.sun.faces.renderkit.AttributeManager;
import com.sun.faces.renderkit.RenderKitUtils;
import com.sun.faces.renderkit.html_basic.MenuRenderer;
import com.sun.faces.util.RequestStateManager;
import com.sun.faces.util.Util;
   
/**
* {@inheritDoc}.
*/
public class CustomSelectManyCheckboxListRenderer extends
 MenuRenderer
{
/** {@inheritDoc}. */
private static final Attribute[] ATTRIBUTES =
   
  AttributeManager.getAttributes(AttributeManager.Key.SELECTMANYCHECKBOX);
/** Representing the border string. */
private static final String BORDER = border;
/** Representing the tr string. */
private static final String TR = tr;
/** Representing the td string. */
private static final String TD = td;
/** Representing the label string. */
private static final String LABEL = label;
/** Representing the newline string. */
private static final String NEWLINE = \n;
/** Representing the tab string. */
private static final String TAB = \t;
/** Representing the class string. */
private static final String CLASS = class;
/** Representing the style string. */
private static final String STYLE = style;
/** Representing the valign string. */
private static final String VALIGN = valign;
   
   
// --
  Public
Methods
   
   
@Override
public void encodeEnd(FacesContext

Re: @FlowScoped, @Named and @ManagedBean

On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Deltaspike modules have consistently been usable off the shelf and would
be
 a far better solution then doing tricks to make CODI work.

+1


 However using JSF stuff would require you to use 0.6-SNAPSHOT. I would
 actually just use @SessionScoped, write a TODO and wait for 0.6 release if
 I could. Otherwise I would use SNAPSHOT since the JSF stuff is all fixed
 for 0.6 afaik.

When I experimented with CODI, I used 1.0.6 snapshot and had the same thing
in mind and then i heard that CODI was dead project, and most likely 1.0.6
would not be released. And I did hear and recognize that deltaspike is
recommended instead of CODI. Someone, please confirm.



 On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote:

  How mature is DeltaSpike? It's only at 0.05.

+1 good question.

 
  On Tuesday, February 11, 2014, Thomas Andraschko 
  andraschko.tho...@gmail.com wrote:
 
   Can't you just switch to DS?
  
  
   2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com
javascript:;
   :
  
Hi
   
CDI implementations does not require to provide anything to JSF in
order to make @FlowScoped to work. The code has been tested against
OWB and Weld and it works in both cases.
   
But the flow stuff relies on the new ClientWindow API, and that
could
cause a conflict with CODI, because CODI provides a solution for
this
part too. In fact, the solution introduced in the standard comes
from
CODI.
   
In your particular case, the best option is provide a custom
ClientWindowFactory / ClientWindow that implements
ClientWindow.getId() method and grab the value generated by CODI.
Theorically there is no need of the custom PhaseListener, because
the
attachWindow step is done in CODI. I haven't tried it but I
suppose
a custom ClientWindow will work.
   
regards,
   
Leonardo Uribe
   
2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 11/02/2014 14:51, l.pe...@senat.fr wrote:

 On 11/02/2014 10:28, l.pe...@senat.fr wrote:

 On 11/02/2014 03:30, Leonardo Uribe wrote:


 [...]

 @FlowScoped annotation is for CDI only, so it will not work for
  JSF
 managed beans. In your case, I believe the bean is instantiated
  but
   it
 is not stored in any context, so once is created is discarded,
   giving
 the impression that the bean is working but it is not.

 In MyFaces it is possible to create a custom flow scope
annotation
   for
 other containers that works just like @FlowScoped, implementing
 org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are
 already in CDI, so you don't need to bother about that.

 I have seen @Named annotation working with Spring, so it is not
 something specific for CDI, but @FlowScoped depends of CDI API.

 I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped
   annotation)
 with OpenWebBeans 1.2.1.

 So, I thought  was ok on the CDI side...

 ...but after reading your mail, it seems to me that this CDI
 implementation was provided before JSF 2.2 release, and so that
it
must not
 include proper @FacesFlow support.

 Should I switch to another implementation, like DeltaSpike ?

 I must have misunderstood your mail from Sep 26 2013 (

   
  
 
http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852.html
 ) inviting us to try Faces Flows in MyFaces 2.2.

 After some debugging, I found that :
 * beans are discovered and processed ok by
 org.apache.myfaces.flow.cdi.FlowScopeCDIExtension
 * -flow.xml is detected and processed with no errors ;
 * if I use an empty -flow.xml file, an exception is raised line
716
  of
 org.apache.myfaces.config.DefaultFacesConfigurationProvider (on
 facesConfig.getFacesFlowDefinitions().add(flow); )
 * if I add a breakpoint in
 org.apache.myfaces.flow.FlowHandlerImpl#clientWindowTransition, I
  can
see :
 ** my flow registered in _flowMapById (with flow1 key)
 ** my flow registered in _flowMapByDocumentId (with an empty key)
 ** that _facesFlowProvider is null


 ok, I think I got it. And, as I feared, it seems to be CODI
related.

 In JSF2.2, a call to

 //JSF 2.2: attach window
 _lifecy
 
 
 
  --
  ___
 
  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://w
  http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com
  http://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: @FlowScoped, @Named and @ManagedBean

On Wed, Feb 12, 2014 at 5:40 AM, Gerhard Petracek 
gerhard.petra...@gmail.com wrote:

 @howard:
 (as announced back then) codi is in maintenance-mode, because new features
 will be added to deltaspike.
 you might have seen the latest updates for using it with ee7.


+1 thanks Gerhard

Re: @FlowScoped, @Named and @ManagedBean

+1 thanks Karl. That is all good to know and good to hear from one of the
users. :)

And for the record, if Thomas recommends it, I know it's a good
recommendation.


On Wed, Feb 12, 2014 at 5:48 AM, Karl Kildén karl.kil...@gmail.com wrote:

 This question has been raised on the mailing list several times. The answer
 is always the same:
 Released functionality is mature and stable. 0.X indicates that the API
 might change but so far this has happened like 1-2 times I think and
 probably took 2 minutes to fix for depending projects. The actual impl is
 stable though.

 By following the discussion on the mailing list it's quite clear that they
 put effort into not only porting CODI but to enhance it as well. I have
 Deltaspike in production for many, many months with no issues (all though
 not 0.6-SNAPSHOT). And you can assume it's going to be more tested then
 code you include yourself to do something similar.

 The parts regarding JSF is stable for 0.6 so getting the support from a
 SNAPSHOT right now and replace with stable release later is not a very
 adventurous.

 These are the docs for getting started:
 http://deltaspike.apache.org/jsf.html

 cheers


 On 12 February 2014 11:33, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  On Feb 12, 2014 1:40 AM, Karl Kildén karl.kil...@gmail.com wrote:
  
   Deltaspike modules have consistently been usable off the shelf and
 would
  be
   a far better solution then doing tricks to make CODI work.
 
  +1
 
  
   However using JSF stuff would require you to use 0.6-SNAPSHOT. I would
   actually just use @SessionScoped, write a TODO and wait for 0.6 release
  if
   I could. Otherwise I would use SNAPSHOT since the JSF stuff is all
 fixed
   for 0.6 afaik.
 
  When I experimented with CODI, I used 1.0.6 snapshot and had the same
 thing
  in mind and then i heard that CODI was dead project, and most likely
 1.0.6
  would not be released. And I did hear and recognize that deltaspike is
  recommended instead of CODI. Someone, please confirm.
 
  
  
   On 12 February 2014 02:44, Kito Mann kito.m...@virtua.com wrote:
  
How mature is DeltaSpike? It's only at 0.05.
 
  +1 good question.
 
   
On Tuesday, February 11, 2014, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:
   
 Can't you just switch to DS?


 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com
  javascript:;
 :

  Hi
 
  CDI implementations does not require to provide anything to JSF
 in
  order to make @FlowScoped to work. The code has been tested
 against
  OWB and Weld and it works in both cases.
 
  But the flow stuff relies on the new ClientWindow API, and that
  could
  cause a conflict with CODI, because CODI provides a solution for
  this
  part too. In fact, the solution introduced in the standard comes
  from
  CODI.
 
  In your particular case, the best option is provide a custom
  ClientWindowFactory / ClientWindow that implements
  ClientWindow.getId() method and grab the value generated by CODI.
  Theorically there is no need of the custom PhaseListener, because
  the
  attachWindow step is done in CODI. I haven't tried it but I
  suppose
  a custom ClientWindow will work.
 
  regards,
 
  Leonardo Uribe
 
  2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
   On 11/02/2014 14:51, l.pe...@senat.fr wrote:
  
   On 11/02/2014 10:28, l.pe...@senat.fr wrote:
  
   On 11/02/2014 03:30, Leonardo Uribe wrote:
  
  
   [...]
  
   @FlowScoped annotation is for CDI only, so it will not work
  for
JSF
   managed beans. In your case, I believe the bean is
  instantiated
but
 it
   is not stored in any context, so once is created is
 discarded,
 giving
   the impression that the bean is working but it is not.
  
   In MyFaces it is possible to create a custom flow scope
  annotation
 for
   other containers that works just like @FlowScoped,
  implementing
   org.apache.myfaces.spi.FacesFlowProvider SPI interface. You
  are
   already in CDI, so you don't need to bother about that.
  
   I have seen @Named annotation working with Spring, so it is
  not
   something specific for CDI, but @FlowScoped depends of CDI
  API.
  
   I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped
 annotation)
   with OpenWebBeans 1.2.1.
  
   So, I thought  was ok on the CDI side...
  
   ...but after reading your mail, it seems to me that this CDI
   implementation was provided before JSF 2.2 release, and so
 that
  it
  must not
   include proper @FacesFlow support.
  
   Should I switch to another implementation, like DeltaSpike ?
  
   I must have misunderstood your mail from Sep 26 2013 (
  
 

   
 
 
 http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

On Wed, Feb 12, 2014 at 9:12 AM, Karl Kildén karl.kil...@gmail.com wrote:

 myfaces-impl
 myfaces-api

 Remove old jars in /lib and place replacements there


yep/agreed!

+1 glad to see you using tomee + myfaces 2.2

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

On Wed, Feb 12, 2014 at 11:21 AM, maurojava mauro2java2...@gmail.comwrote:

 hi . i have tried but not work!

 o have substitute the jars but when i deploy not start into tomee.

 It can possible because i have jse1.7 ?


 the source of project


list steps, more details like following

1. i have JDK 7.0.45 (or whatever version)
2. tomee 1.6.0
3. myfaces 2.2 api and impl JARS, copied to tomee/lib
4. removed myfaces 2.1 api and impl JARs from tomee/lib
5. NOT using CODI in WAR or tomee/lib

Re: StackOverflowError with MyFaces 2.2.0

2014-01-22 Thread Howard W. Smith, Jr.

On Wed, Jan 22, 2014 at 1:50 PM, Mike Calmus m...@calmus.org wrote:

 I tried updating an existing application to MyFaces 2.2.0 (from 2.1.11) by
 simply replacing the library.


Interesting. I'm sure that I could have migrated my app from MyFaces 2.1.11
to myFaces 2.2.0, but I'm using TomEE, which has a nice home for MyFaces
2.1.x (and MyFaces 2.2.x).

Library = api and impl JAR

or

library = bundle JAR ?



 When I try to deploy the app, I get a StackOverflowError (below).


Might be good for you to copy/paste your (entire) server log (on startup of
server/app) to pastebin website or provide that in your next reply.

Re: JSF / MyFaces 2.2

2014-01-19 Thread Howard W. Smith, Jr.

On Sat, Jan 18, 2014 at 3:14 AM, Michael Kurz michi.k...@gmx.at wrote:

 You can have a look at my blog http://jsflive.wordpress.com/. I wrote
 some articles about JSF 2.2 features.

 Regards
 Michael


+1 wow, Michael, so many blog posts related to JSF 2.2. Thanks!

While scrolling through the list of your blogs, JSF 2.2 view actions caught
my attention. :)

Re: JSF / MyFaces 2.2

2014-01-16 Thread Howard W. Smith, Jr.

On Thu, Jan 16, 2014 at 4:56 AM, l.pe...@senat.fr l.pe...@senat.fr wrote:


 what documents do you suggest to read to get an idea of what's new in JSF
 2.2


i just searched google.com for jsf 2.2 and below was first in 'my' (google)
search results (since I been there before)

http://jdevelopment.nl/jsf-22/

What's new in JSF 2.2? | J-Development
jdevelopment.nl/jsf-22/?

You've visited this page 5 times. Last visit: 10/22/13




 and in our favourite JSF implementation, MyFaces ?


Leonardo sent an email (a few days ago) about the following:

[core] What's new in MyFaces 2.2

where he referenced the following blog:

http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html

also, you can check release notes for MyFaces 2.2, and that should list
everything in MyFaces 2.2. I think the announcement emails sent to user
list, about MyFaces 2.2 (beta and final releases) also mentioned the
release notes.

Re: JSF / MyFaces 2.2

2014-01-16 Thread Howard W. Smith, Jr.

i would go with those 2 URLs that I provided, and just last night, while
reading Leonardo's blog about MyFaces 2.2 (what's new), he said that there
was a previous blog about view pooling, so i looked at his list of blogs on
the right hand side (the menu/navigator/tree), and found the following:

http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html

which is on my to-do list. i want to see if i can or have need to add that
to my app.




On Thu, Jan 16, 2014 at 1:07 PM, Ludovic Pénet l.pe...@senat.fr wrote:

 Well, you know what, I already googled (thanks) and read release notes
 (thanks again)...

 Best regards,



 Howard W. Smith, Jr. smithh032...@gmail.com a écrit :

 On Thu, Jan 16, 2014 at 4:56 AM, l.pe...@senat.fr l.pe...@senat.fr wrote:


 what documents do you suggest to read to get an idea of what's new in JSF
 2.2



 i just searched google.com for jsf 2.2 and below was first in 'my' (google)
 search results (since I been there before)

 http://jdevelopment.nl/jsf-22/

 What's new in JSF 2.2? | J-Development
 jdevelopment.nl/jsf-22/?

 You've visited this page 5 times. Last visit: 10/22/13




 and in our favourite JSF implementation, MyFaces ?



 Leonardo sent an email (a few days ago) about the following:

 [core] What's new in MyFaces 2.2

 where he referenced the following blog:

 http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html

 also, you can check release notes for MyFaces 2.2, and that should list
 everything in MyFaces 2.2. I think the announcement emails sent to user
 list, about MyFaces 2.2 (beta and final releases) also mentioned the
 release notes.


 --
 Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: JSF 2.2 Exit Flow

2014-01-16 Thread Howard W. Smith, Jr.

On Thu, Jan 16, 2014 at 8:10 PM, Geoffrey Longo gmlo...@live.com wrote:

 I have an application that consists of a dropdown menu bar with many menu
 items.  Each menu item will initiate a new faces flow.  This is working
 correctly, however, once I am inside a flow, I would like any click on a
 menu item to exit the current flow, and then start a new one.  There are
 dozens of menu items in the application, so I was wondering if there is any
 way to have the current flow automatically exit when a menu item is clicked
 without having to define a flow-return for each menu item?

 Thanks,
 Geoff


I was wondering how your code looked. Now I know via your post[1] in
PrimeFaces forum. :)

i'm not using Faces Flow yet, so I'm just listening/reading. :)


[1] http://forum.primefaces.org/viewtopic.php?f=3t=35881

Re: [core] What's new in MyFaces 2.2

MyFaces 2.2.0 is working just as good as MyFaces 2.1.13 (has been working
over the last few months).

So, i guess MyFaces 2.2.0 is here to stay in my app. Thank you!


On Wed, Jan 15, 2014 at 2:54 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Done (deployed MyFaces 2.2.0 with my app in production).

 On Tue, Jan 14, 2014 at 12:54 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 i am really going to have to make the step to migrate to JSF 2.2.
 hopefully will do it, ASAP. thanks again.

Re: MyFaces 2.2.0 (yesterday's release) CDI @ViewScoped @PreDestroy

On Wed, Jan 15, 2014 at 2:27 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 FYI, I 'want' to migrate to MyFaces 2.2.0 in production, and I think I
 will do it anyway, but please answer my question above about this
 behavior/implementation/test-results-of-mine.


well, I'm running MyFaces 2.2.0 in production now, and GC is the same as
when I was running MyFaces 2.1.3 (and when I was using OmniFaces CDI
@ViewScoped). this is my jvisualvm graph[1], today (this morning).

Still a satisfied/happy MyFaces user, and happy to be 'now' using MyFaces
2.2.0. Maybe I can ask TomEE users/committers to add MyFaces 2.2.0 to the
stack! :)

[1] http://postimg.org/image/u2y6j11tt/

Re: MyFaces 2.2.0 ViewScoped

Hey, Jose. you should have used NetBeans 'Fix imports' option after
removing Omnifaces package.

i think you are using NetBeans (but I might be wrong).

Fix imports would have gave you a dialog showing you the MyFaces 2.2
@ViewScoped package to import.



On Wed, Jan 15, 2014 at 3:34 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 Hi im currently using org.omnifaces.cdi.ViewScoped for my @Named beans, now
 with MyFaces 2.2.0 which package do i have to use for @ViewScoped and
 @Named for work togheter.

 Thanks

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

Leonardo,

Jose uses/deploys EARs. Maybe that is the issue. Has MyFaces 2.2
@ViewScoped been tested in an EAR.

Jose,

You need to provide more of your configuration and share that you usually
deploy your app via EAR(s). right?



On Wed, Jan 15, 2014 at 5:48 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 It looks like something not directly related to MyFaces, it is like if
 the classpath is scanned twice, or like the bean is subscribed twice.
 I suppose it is a bug in OWB or in TomEE. Maybe you should report it
 in:

 https://issues.apache.org/jira/browse/TOMEE

 regards,

 Leonardo Uribe

 2014/1/15 José Luis Cetina maxtorz...@gmail.com:
  Hi. I use TomEE 1.6.0 Final release with myfaces 2.1.13 and jdk 1.7 with
  this i was using the org.omnifaces.cdi.ViewScoped annotation with any
  problem, with the new release of myfaces 2.2.0 i decide to change from
  org.omnifaces.cdi.ViewScoped to javax.faces.view.ViewScoped then im
 gettin
  this AmbiguousResolutionException.
 
 
  This error only happend in Linux environment, if i run the same project
 in
  Windows this error never appears.
 
 
  I removed my faces 2.1.13 jars (api and imp) from tomee lib and add
 myfaces
  api and impl 2.2.0
 
 
  What could be wrong?
 
  Log:
 
  javax.enterprise.inject.AmbiguousResolutionException: Ambiguous
 resolution
  found beans:
  ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API
 
 Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder],
  Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
  from
 jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class
  ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API
 
 Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder],
  Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
  from
 jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionExceptionForBeans(InjectionExceptionUtil.java:104)
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:94)
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:71)
 
 org.apache.webbeans.container.InjectionResolver.resolve(InjectionResolver.java:699)
 
 org.apache.webbeans.container.BeanManagerImpl.resolve(BeanManagerImpl.java:925)
 
 org.apache.webbeans.container.InjectableBeanManager.resolve(InjectableBeanManager.java:201)
 
 org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:413)
 
 org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:144)
 
 org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.getViewScopeBeanHolder(CDIManagedBeanHandlerImpl.java:64)
 
 org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.generateViewScopeId(CDIManagedBeanHandlerImpl.java:92)
 
 org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76)
 
 org.apache.myfaces.view.ViewScopeProxyMap.size(ViewScopeProxyMap.java:89)
  javax.faces.component.UIViewRoot.saveState(UIViewRoot.java:1498)
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:846)
 
 org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:351)
 
 org.apache.myfaces.renderkit.ErrorPageWriter.handle(ErrorPageWriter.java:470)
 
 org.apache.myfaces.context.MyFacesExceptionHandlerWrapperImpl.handle(MyFacesExceptionHandlerWrapperImpl.java:301)
 
 javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:61)
 
 org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:162)
 
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:287)
  javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces
 api and impl 2.2.0


that's exactly what I did and I don't get the error.

Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too?

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

if you are not able to use MyFaces 2.2 @ViewScoped, you may need to keep
OmniFaces CDI @ViewScoped until someone helps you with your issue.

Some months ago, I tested MyFaces 2.2 with OmniFaces CDI @ViewScoped; all
of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I
experienced no issues. My app is not packaged as an EAR.

today, i am using MyFaces 2.2 @ViewScoped beans even though I still have
OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped).

For the first day, running MyFaces 2.2, I am quite pleased. No issues to
report, no exceptions in tomee/tomcat log files.



On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 I removed CODI and my app is package as ear. maybe i need to try tomee
 1.6.1-snapshot


 2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com

  On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina maxtorz...@gmail.com
  wrote:
 
   I removed my faces 2.1.13 jars (api and imp) from tomee lib and add
  myfaces
   api and impl 2.2.0
  
 
  that's exactly what I did and I don't get the error.
 
  Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too?
 



 --
 ---
 *SCJA. José Luis Cetina*
 ---

Re: JSF 2.3

On Tue, Jan 14, 2014 at 10:40 AM, Mike Kienenberger mkien...@gmail.comwrote:

 Hope this helps.


+1 Mike and thanks for sharing.

it's good to hear/know this about struts. when i learned java ee 6 via java
ee 6 tutorial, of course, JSF is mentioned there; i don't remember struts
being mentioned there at all. so, my java web application development
experience/world has been JSF, and that is where my preference is today,
still.

Re: [core] What's new in MyFaces 2.2

Understood, thanks Leonardo. i am really going to have to make the step to
migrate to JSF 2.2. hopefully will do it, ASAP. thanks again.



On Tue, Jan 14, 2014 at 9:40 AM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  Wow, interesting that you sent this email as I was writing my email,
 asking
  a few questions bout MyFaces 2.2.
 
  Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me
 to
  think about MyFaces 2.2. I am considering migrating my app from MyFaces
  2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and
  since the last time that I tested/used myFaces 2.2, I have no
  issues/defects to report. Just have not pushed MyFaces 2.2 to my
 production
  environment yet.
 

 The changes included in JSF 2.2 does not make any conflict with 2.0 / 2.1
 code.
 The migration step from 2.1 to 2.2 is very simple, just replace the
 jars and that's
 it. There are some differences like for example the view scope beans are
 now
 stored in session and if CDI is enabled, view scope is managed by CDI.

 Additionally, there wasn't any change that affect the behavior
 significantly in
 JSF 2.2, so the code looks very stable. It were also included a lot of
 junit tests
 for the new features to ensure everything works as expected, which reduces
 in the long term the occurrence of bugs and provides a better code quality.

  I wanted to wait and hear a bit more from the community about it, but
 (LOL)
  that's the thing, there are not many questions at all on MyFaces user
 list.
  Evidently, it just works! :)
 
 
 
  On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org
 wrote:
 
  Hi
 
  For the people who want to know quickly what's new in MyFaces 2.2, I
  have written a summary of the new features here:
 
  http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html
 
  regards,
 
  Leonardo Uribe

Re: [ANNOUNCE] MyFaces Core v2.2.0 Release

Understood. thanks again for the response, Leonardo.



On Tue, Jan 14, 2014 at 9:30 AM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi Howard

 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  Leonardo,
 
  Some questions for you:
 
  1. How has MyFaces 2.2 (beta) release been performing and/or accepted by
  MyFaces user community?
 

 We have received some good feedback that has helped a lot to get the new
 release.

  2. Any big corporation/names start using MyFaces 2.2 (beta) release yet?
 

 If things goes like it was in 2.0, it still will take a couple of
 releases so more
 people start using fully the new artifacts, but since we are 2.2 I hope the
 adoption will be faster.

  3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)?
 

 Yes, there are some improvements in session size / state management that
 will help. From speed perspective, with the same flags enabled both perform
 more or less the same.

  4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2
  performance against Mojarra, Wicket, and Spring...like you did for
 MyFaces
  2.1.7?
 

 Probably, but more as an update to keep track what has happened.

 regards,

 Leonardo Uribe

  Thanks,
  Howard
 
 
  On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org
 wrote:
 
  The Apache MyFaces team is pleased to announce the release of MyFaces
  Core 2.2.0.

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

FOLLOWUP:

org.apache.myfaces.application.ResourceHandlerImpl.level = OFF


is working great, thanks again.



On Tue, Jan 7, 2014 at 11:03 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Thanks Leonardo for the response. Per javadoc[1], OFF is available as you
 stated. I will give that a try.

 [1]
 http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#OFF



 On Tue, Jan 7, 2014 at 10:54 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi Howard

 I think it should work with:

 org.apache.myfaces.application.ResourceHandlerImpl.level = OFF

 regards,

 Leonardo

 2014/1/7 Howard W. Smith, Jr. smithh032...@gmail.com:
  Leonardo,
 
  On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com
 wrote:
 
  The exception
  was added in the log on:
 
  https://issues.apache.org/jira/browse/MYFACES-3736
 
  I have checked it and there is no evidence of an error from MyFaces
 side.
 
  Maybe we can do something to hide the exception, printing it only if
  Level.FINE is set.
 
 
  In the meanwhile, what is the best way to prevent this exception from
  appearing in my (tomee+) log file? can i disable it via
 logging.properties
  via the following?
 
  org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING

MyFaces 2.2: another release, soon?

Will there be another release of MyFaces 2.2, since MyFaces Core 2.1.14 and
2.0.20 were released?

I would assume that MyFaces 2.1.14 release fixes would be included in
MyFaces 2.2, too.

right?

Re: MyFaces 2.2: another release, soon?

wow, thanks Mike. (Late) last night, when I was replying to an ANNOUNCE
MyFaces 2.2.0 email, I thought it was the 'beta release'.

I just now recognized that I replied to the (latest) MyFaces 2.2.0 release.

thanks!



On Tue, Jan 14, 2014 at 5:20 PM, Mike Kienenberger mkien...@gmail.comwrote:

 2.0, 2.1, and 2.2 were all released at the same time.

 On Tue, Jan 14, 2014 at 5:17 PM, Howard W. Smith, Jr.
 smithh032...@gmail.com wrote:
  Will there be another release of MyFaces 2.2, since MyFaces Core 2.1.14
 and
  2.0.20 were released?
 
  I would assume that MyFaces 2.1.14 release fixes would be included in
  MyFaces 2.2, too.
 
  right?

MyFaces 2.2.0 (yesterday's release) CDI @ViewScoped @PreDestroy

Okay, I downloaded MyFaces 2.2.0 (yesterday's release), and added it to my
TomEE 1.6.1 SNAPSHOT (downloaded 2 or 3 days ago), and I decided to test
CDI @ViewScoped @PreDestroy.

Below, you will see that I logged in, and opened a few pages that reference
a few different instances of CDI @ViewScoped beans, @PreDestroy
releaseResources() method was executed as i navigated to different views,
but then here is the thing that concerns me, the @PreDestroy of
pre-existing-and-thought-to-be-already-destroyed bean 'instances' were
executed after logout, where logout = session.invalidate. See below, please.

Is this behavior per the spec?

Jan 15, 2014 2:16:45 AM pf.ApplicationScopeBean login
INFO: sessionId = administrator5AD906CC2D25991567A047780BBBF561
Jan 15, 2014 2:16:45 AM jsf.users.pf_UsersController loginUser
INFO: administrator logged in at 01/15/2014 02:16 AM

Jan 15, 2014 2:17:01 AM jsf.orders.EditDriverVehicles init
INFO: jsf.orders.EditDriverVehicles@5fe1cb9b
Jan 15, 2014 2:17:03 AM jsf.orders.EditDriverVehicles releaseResources
INFO: jsf.orders.EditDriverVehicles@5fe1cb9b
Jan 15, 2014 2:17:06 AM jsf.orders.EditDriverVehicles init
INFO: jsf.orders.EditDriverVehicles@7133db9
Jan 15, 2014 2:17:07 AM jsf.orders.EditDriverVehicles releaseResources
INFO: jsf.orders.EditDriverVehicles@7133db9
Jan 15, 2014 2:17:10 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@41d7a36a
Jan 15, 2014 2:17:12 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@41d7a36a
Jan 15, 2014 2:17:14 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@486ae85a
Jan 15, 2014 2:17:17 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@486ae85a
Jan 15, 2014 2:17:21 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@6ff554c9
Jan 15, 2014 2:17:23 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@6ff554c9

Jan 15, 2014 2:17:29 AM jsf.users.pf_UsersController logout
INFO: administrator logged out at 01/15/2014 02:17 AM

Jan 15, 2014 2:17:29 AM jsf.orders.EditDriverVehicles releaseResources
INFO: jsf.orders.EditDriverVehicles@7133db9
Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@486ae85a
Jan 15, 2014 2:17:29 AM jsf.orders.EditDriverVehicles releaseResources
INFO: jsf.orders.EditDriverVehicles@5fe1cb9b
Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@6ff554c9
Jan 15, 2014 2:17:29 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@41d7a36a


FYI, I 'want' to migrate to MyFaces 2.2.0 in production, and I think I will
do it anyway, but please answer my question above about this
behavior/implementation/test-results-of-mine.

Thanks,
Howard

Re: [core] What's new in MyFaces 2.2

Done (deployed MyFaces 2.2.0 with my app in production).

On Tue, Jan 14, 2014 at 12:54 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 i am really going to have to make the step to migrate to JSF 2.2.
 hopefully will do it, ASAP. thanks again.

Re: [ANNOUNCE] MyFaces Core v2.2.0 Release

2014-01-13 Thread Howard W. Smith, Jr.

Leonardo,

Some questions for you:

1. How has MyFaces 2.2 (beta) release been performing and/or accepted by
MyFaces user community?

2. Any big corporation/names start using MyFaces 2.2 (beta) release yet?

3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)?

4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2
performance against Mojarra, Wicket, and Spring...like you did for MyFaces
2.1.7?

Thanks,
Howard


On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org wrote:

 The Apache MyFaces team is pleased to announce the release of MyFaces
 Core 2.2.0.

Re: [core] What's new in MyFaces 2.2

2014-01-13 Thread Howard W. Smith, Jr.

Wow, interesting that you sent this email as I was writing my email, asking
a few questions bout MyFaces 2.2.

Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me to
think about MyFaces 2.2. I am considering migrating my app from MyFaces
2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and
since the last time that I tested/used myFaces 2.2, I have no
issues/defects to report. Just have not pushed MyFaces 2.2 to my production
environment yet.

I wanted to wait and hear a bit more from the community about it, but (LOL)
that's the thing, there are not many questions at all on MyFaces user list.
Evidently, it just works! :)



On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org wrote:

 Hi

 For the people who want to know quickly what's new in MyFaces 2.2, I
 have written a summary of the new features here:

 http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html

 regards,

 Leonardo Uribe

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2014-01-07 Thread Howard W. Smith, Jr.

Leonardo,

On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com wrote:

 The exception
 was added in the log on:

 https://issues.apache.org/jira/browse/MYFACES-3736

 I have checked it and there is no evidence of an error from MyFaces side.

 Maybe we can do something to hide the exception, printing it only if
 Level.FINE is set.


In the meanwhile, what is the best way to prevent this exception from
appearing in my (tomee+) log file? can i disable it via logging.properties
via the following?

org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2014-01-07 Thread Howard W. Smith, Jr.

Thanks Leonardo for the response. Per javadoc[1], OFF is available as you
stated. I will give that a try.

[1]
http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html#OFF



On Tue, Jan 7, 2014 at 10:54 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi Howard

 I think it should work with:

 org.apache.myfaces.application.ResourceHandlerImpl.level = OFF

 regards,

 Leonardo

 2014/1/7 Howard W. Smith, Jr. smithh032...@gmail.com:
  Leonardo,
 
  On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com
 wrote:
 
  The exception
  was added in the log on:
 
  https://issues.apache.org/jira/browse/MYFACES-3736
 
  I have checked it and there is no evidence of an error from MyFaces
 side.
 
  Maybe we can do something to hide the exception, printing it only if
  Level.FINE is set.
 
 
  In the meanwhile, what is the best way to prevent this exception from
  appearing in my (tomee+) log file? can i disable it via
 logging.properties
  via the following?
 
  org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2013-11-14 Thread Howard W. Smith, Jr.

Correct. Not a MyFaces or Tomcat/TomEE issue, but hiding the exception...
sounds good to me. :)



On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 Thanks to provide the link of the discussion in tomcat list. The exception
 was added in the log on:

 https://issues.apache.org/jira/browse/MYFACES-3736

 I have checked it and there is no evidence of an error from MyFaces side.

 Maybe we can do something to hide the exception, printing it only if
 Level.FINE is set.

 regards,

 Leonardo Uribe



 2013/11/11 Howard W. Smith, Jr. smithh032...@gmail.com

  FYI,
 
  On Sun, Nov 10, 2013 at 8:29 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   more on this topic...
 
 
  Discussed on the tomcat list:
 
  Avoiding/Handling SocketTimeoutException(s) when web application serving
  resources to mobile clients[1]
 
 
  [1]
 
 
 http://tomcat.10.x6.nabble.com/Avoiding-Handling-SocketTimeoutException-s-when-web-application-serving-resources-to-mobile-clients-td5007700.html

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2013-11-11 Thread Howard W. Smith, Jr.

FYI,

On Sun, Nov 10, 2013 at 8:29 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 more on this topic...


Discussed on the tomcat list:

Avoiding/Handling SocketTimeoutException(s) when web application serving
resources to mobile clients[1]


[1]
http://tomcat.10.x6.nabble.com/Avoiding-Handling-SocketTimeoutException-s-when-web-application-serving-resources-to-mobile-clients-td5007700.html

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2013-11-10 Thread Howard W. Smith, Jr.

more on this topic...

On Fri, Nov 8, 2013 at 9:28 PM, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

 Today (this evening), the exception below occurred twice for the same
 (mobile) enduser within 1 to 2 hours' time. In the past, while using
 previous releases of MyFaces 2.1.8+, I have seen the handleResourceRequest
 error, but the stacktrace was not in the log file.

 Can the stacktrace be eliminated as in previous versions of MyFaces? was
 this added, recently, to log the stracktrace of this exception or
 certain/selected exceptions? Or should I catch this exception in my Filter
 when chain.doFilter(req, res) is executed?


this morning, I recognized more occurrences of this exception in log files,
and it is still related to connection between server and 'mobile client'.
User was attempting to login from mobile iPad via an internal wireless
phone connection. please see all below and advise if MyFaces can do
anything about this, or if I should approach tomcat user list about socket
timeout exception(s), or the best way I should approach this type of
scenario-and-exception. I updated gist[1], too.


localhost_access_log shows the follow (please note the filenames and time
difference between the 1, 2, and 3rd lines below)

x.x.x.x - - [09/Nov/2013:13:08:25 -0500] GET
/webapp/javax.faces.resource/primefaces.css.jsf?ln=primefacesv=4.0.3
HTTP/1.1 200 10036

x.x.x.x - - [09/Nov/2013:13:09:00 -0500] GET
/webapp/javax.faces.resource/jquery/jquery.js.jsf?ln=primefacesv=4.0.3
HTTP/1.1 200 -

x.x.x.x - - [09/Nov/2013:13:09:00 -0500] GET
/webapp/javax.faces.resource/jquery/jquery-plugins.js.jsf?ln=primefacesv=4.0.3
HTTP/1.1 200 -



tomcat7-stderr

Nov 09, 2013 1:09:00 PM
org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery.js with library
primefaces :null
ClientAbortException:  java.net.SocketTimeoutException
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)

Caused by: java.net.SocketTimeoutException
at 
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
at 
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)

Nov 09, 2013 1:09:00 PM
org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery-plugins.js with
library primefaces :null
ClientAbortException:  java.net.SocketTimeoutException

Caused by: java.net.SocketTimeoutException
at 
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
at 
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)


[1] https://gist.github.com/smithh032772/7380812

[TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

2013-11-08 Thread Howard W. Smith, Jr.

Today (this evening), the exception below occurred twice for the same
(mobile) enduser within 1 to 2 hours' time. In the past, while using
previous releases of MyFaces 2.1.8+, I have seen the handleResourceRequest
error, but the stacktrace was not in the log file.

Can the stacktrace be eliminated as in previous versions of MyFaces? was
this added, recently, to log the stracktrace of this exception or
certain/selected exceptions? Or should I catch this exception in my Filter
when chain.doFilter(req, res) is executed?

gist[1] has the two occurrences of the stacktrace in the log file.


Nov 08, 2013 4:06:05 PM org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery-plugins.js with library
primefaces :null
ClientAbortException:  java.net.SocketTimeoutException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:359)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:309)
at
org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:108)
at java.util.zip.DeflaterOutputStream.close(Unknown Source)
at
org.omnifaces.servlet.GzipHttpServletResponse$GzipThresholdOutputStream.close(GzipHttpServletResponse.java:229)
at
org.omnifaces.io.ResettableBufferedOutputStream.close(ResettableBufferedOutputStream.java:101)
at
org.omnifaces.servlet.HttpServletResponseOutputWrapper$1.close(HttpServletResponseOutputWrapper.java:100)
at
org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:421)
at
javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:62)
at
org.primefaces.application.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:132)
at
javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:62)
at
org.primefaces.mobile.application.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:119)
at
javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:62)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
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:98)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:149)
at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

snip
at pf.LoginFilter.doFilter(LoginFilter.java:241)
/snip

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1721)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1679)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketTimeoutException
at

Re: Performance params

2013-11-01 Thread Howard W. Smith, Jr.

Kito,

On Thu, Oct 31, 2013 at 7:46 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 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.


Also, I couldn't help myself in saying this, another outstanding Apache
committer wrote this blog with the following question,

Why is OpenWebBeans so fast?[1]

I hope your client is willing to use OpenWebBeans + JUEL + MyFaces. that is
a happy stack which will make for happy campers/endusers/etc...


[1] http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/

Re: Performance params

2013-11-01 Thread Howard W. Smith, Jr.

and with that said, an answer[1] to a question on stackoverflow,

context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value/context-param
  context-param
param-namecom.sun.faces.expressionFactory/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
  /context-param



[1] http://stackoverflow.com/a/5538539/933054


On Fri, Nov 1, 2013 at 7:13 PM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:

 http://lmgtfy.com/?q=tomcat+ExpressionFactoryImpl


 2013/11/1 José Luis Cetina maxtorz...@gmail.com

  I use tomee with the default EL
 
 
  2013/11/1 Thomas Andraschko andraschko.tho...@gmail.com
 
   It depends on your AS or EL Implementation.
   If you use JUEL, its: de.odysseus.el.ExpressionFactoryImpl
  
  
   2013/11/1 José Luis Cetina maxtorz...@gmail.com
  
And what is the value of org.apache.myfaces.EXPRESSION_FACTORY ?
   
   
2013/11/1 Thomas Andraschko andraschko.tho...@gmail.com
   
 AFAIR you must set org.apache.myfaces.EXPRESSION_FACTORY because
  the
   EL
 Factory can't be extraced from JSP anymore.


 2013/11/1 José Luis Cetina maxtorz...@gmail.com

  I didnt have any of this performance parameters in my webapps,
 now
  im
  trying to use them (i have any other params), im trying one by
 one
   and
 when
  i set
 
  context-param
 
 
  param-nameorg.apache.myfaces.SUPPORT_JSP_AND_FACES_EL/param-name
  param-valuefalse/param-value
  /context-param
 
  and try to access to my app i get an
 
  SEVERE - StandardWrapper.Throwable
  java.lang.IllegalStateException: No Factories configured for this
  Application. This happens if the faces-initialization does not
 work
   at
 all
  - make sure that you properly include all configuration settings
 necessary
  for a basic faces application and that all the necessary libs are
 included.
  Also check the logging output of your web application and your
container
  for any exceptions!
  If you did that and find nothing, the mistake might be due to the
   fact
 that
  you use some special web-containers which do not support
  registering
  context-listeners via TLD files and a context listener is not
 setup
   in
 your
  web.xml.
  A typical config looks like this;
  listener
 
 
 

   
  
 
 listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
  /listener
 
  I dont have the
   org.apache.myfaces.webapp.StartupServletContextListener
  listener in my web.xml, im using an ear, what im doing wrong?
 
 
  2013/11/1 Kito Mann kito.m...@virtua.com
 
   Thanks for the link, Howard. Mark is definitely an outstanding
Apache
   Committer ;-).
  
   At any rate, this client isn't using CDI, so that isn't an
  option.
   I
  would
   definitely consider it for clients that are using CDI, though.
 I
always
   felt like OpenWebBeans was more stable than Weld.
  
   ___
  
   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 Fri, Nov 1, 2013 at 9:48 AM, Howard W. Smith, Jr. 
   smithh032...@gmail.com
wrote:
  
Kito,
   
On Thu, Oct 31, 2013 at 7:46 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   
 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.
   
   
Also, I couldn't help myself in saying this, another
  outstanding
 Apache
committer wrote this blog with the following question,
   
Why is OpenWebBeans so fast?[1]
   
I hope your client is willing to use OpenWebBeans + JUEL +
   MyFaces.
  that
   is
a happy stack which will make for happy
 campers/endusers/etc...
   
   
[1]
  
   
 http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/
   
  
 
 
 
  --
 
 ---
  *SCJA. José Luis Cetina

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

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?

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: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Howard W. Smith, Jr.

Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was
just/recently released (yesterday, I think). Feel free to give that a try.

TomEE and tomcat8 is and/or will be targeting JEE7.

is it a requirement to deploy to Glassfish 4, or you just want to deploy to
your local machine for testing purposes only?

if for testing purposes only, download latest tomee 1.6 snapshot and
Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib folder,
and give them a try. and if you have any tomee-related questions, please
subscribe to tomee user list and ask questions there. they are 'apache',
too, and just as helpful there, 'too'. :)



On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net wrote:

 Hi Edilmar.

 I had the same issues. There are incompatibilities apparently with JSF 2.2
 that ships with GlassFish 4. And JSF 2.2 has some much improved CDI
 features, such as proper @ViewScope.

 Kay


 On 10/30/2013 01:03 PM, Edilmar Alves wrote:

 Hi,

 I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 +
 Hibernate4.2.6 + JSF2 + RichFaces4.3.4.
 Then, when I try to deploy in GF4, server.log arises this error, and
 searching on Internet, some people said this is a
 problem with CODI, that is not compatible with JEE7 projects. Is this
 true?
 If it is not compatible, is there some alternative
 that makes the same as CODI ConversationScoped for example, that I use in
 many places in my webapp?

   [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE]
 [NCLS-CORE-00026]
 [javax.enterprise.system.core] [tid: _ThreadID=36
 _ThreadName=admin-listener(5)] [timeMillis: 1375109082206] [levelValue:
 1000] [[

Exception during lifecycle processing

 org.glassfish.deployment.**common.DeploymentException: CDI deployment
 failure:WELD-001408 Unsatisfied dependencies for type [Validator] with
 qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject
 private
 org.hibernate.validator.**internal.cdi.interceptor.**
 ValidationInterceptor.**validator]

  at org.glassfish.weld.**WeldDeployer.event(**WeldDeployer.java:225)

  at org.glassfish.kernel.event.**EventsImpl.send(EventsImpl.**
 java:131)

  at
 org.glassfish.internal.data.**ApplicationInfo.load(**
 ApplicationInfo.java:328)

  at
 com.sun.enterprise.v3.server.**ApplicationLifecycle.deploy(**
 ApplicationLifecycle.java:493)

  at
 com.sun.enterprise.v3.server.**ApplicationLifecycle.deploy(**
 ApplicationLifecycle.java:219)

  at
 org.glassfish.deployment.**admin.DeployCommand.execute(**
 DeployCommand.java:491)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl$2$1.run(**
 CommandRunnerImpl.java:527)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl$2$1.run(**
 CommandRunnerImpl.java:523)

  at java.security.**AccessController.doPrivileged(**Native Method)

  at javax.security.auth.Subject.**doAs(Subject.java:356)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl$2.execute(**
 CommandRunnerImpl.java:522)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl.doCommand(**
 CommandRunnerImpl.java:546)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl.doCommand(**
 CommandRunnerImpl.java:1423)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl.access$1500(**
 CommandRunnerImpl.java:108)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl$**
 ExecutionContext.execute(**CommandRunnerImpl.java:1762)

  at
 com.sun.enterprise.v3.admin.**CommandRunnerImpl$**
 ExecutionContext.execute(**CommandRunnerImpl.java:1674)

  at
 org.glassfish.admin.rest.**resources.admin.**CommandResource.**
 executeCommand(**CommandResource.java:396)

  at
 org.glassfish.admin.rest.**resources.admin.**CommandResource.**
 execCommandSimpInMultOut(**CommandResource.java:234)

  at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)

  at
 sun.reflect.**NativeMethodAccessorImpl.**invoke(**
 NativeMethodAccessorImpl.java:**57)

  at
 sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
 DelegatingMethodAccessorImpl.**java:43)

  at java.lang.reflect.Method.**invoke(Method.java:601)

  at
 org.glassfish.jersey.server.**model.internal.**
 ResourceMethodInvocationHandle**rFactory$1.invoke(**
 ResourceMethodInvocationHandle**rFactory.java:81)

  at
 org.glassfish.jersey.server.**model.internal.**
 AbstractJavaResourceMethodDisp**atcher.invoke(**
 AbstractJavaResourceMethodDisp**atcher.java:125)

  at
 org.glassfish.jersey.server.**model.internal.**
 JavaResourceMethodDispatcherPr**ovider$ResponseOutInvoker.**doDispatch(**
 JavaResourceMethodDispatcherPr**ovider.java:152)

  at
 org.glassfish.jersey.server.**model.internal.**
 AbstractJavaResourceMethodDisp**atcher.dispatch(**
 AbstractJavaResourceMethodDisp**atcher.java:91)

  at
 org.glassfish.jersey.server.**model.ResourceMethodInvoker.**
 invoke(ResourceMethodInvoker.**java:346)

  at
 org.glassfish.jersey.server.**model.ResourceMethodInvoker.**

Re: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Howard W. Smith, Jr.

/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
 
   release targeting Java EE 6. Unless he wants to incorporated new
  features
  that only Java EE 7 can provide, I'd say, stick with what
 currently
  works.
  Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still
  targets
  Java EE 6, or JBoss AS 7 which also targets Java EE 6.
 
 
  On 10/30/2013 02:08 PM, Howard W. Smith, Jr. wrote:
 
Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was
 
  just/recently released (yesterday, I think). Feel free to give
 that
 
  a
 
   try.
 
  TomEE and tomcat8 is and/or will be targeting JEE7.
 
  is it a requirement to deploy to Glassfish 4, or you just want to
  deploy
  to
  your local machine for testing purposes only?
 
  if for testing purposes only, download latest tomee 1.6 snapshot
  and
  Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib
  folder,
  and give them a try. and if you have any tomee-related questions,
  please
  subscribe to tomee user list and ask questions there. they are
  'apache',
  too, and just as helpful there, 'too'. :)
 
 
 
  On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net
  wrote:
 
 Hi Edilmar.
 
   I had the same issues. There are incompatibilities apparently
 with
  JSF
  2.2
  that ships with GlassFish 4. And JSF 2.2 has some much improved
  CDI
  features, such as proper @ViewScope.
 
  Kay
 
 
  On 10/30/2013 01:03 PM, Edilmar Alves wrote:
 
 Hi,
 
   I have an webapp that runs fine in GF3.1.1 using Weld1.1 +
 CODI +
  JPA2 +
  Hibernate4.2.6 + JSF2 + RichFaces4.3.4.
  Then, when I try to deploy in GF4, server.log arises this
 error,
 
  and
 
searching on Internet, some people said this is a
  problem with CODI, that is not compatible with JEE7 projects.
 Is
  this
  true?
  If it is not compatible, is there some alternative
  that makes the same as CODI ConversationScoped for example,
 that
  I
  use
  in
  many places in my webapp?
 
   [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE]
  [NCLS-CORE-00026]
  [javax.enterprise.system.core] [tid: _ThreadID=36
  _ThreadName=admin-listener(5)] [timeMillis: 1375109082206]
  [levelValue:
  1000] [[
 
Exception during lifecycle processing
 
  org.glassfish.deployment.common.DeploymentException:
 CDI
  deployment
  failure:WELD-001408 Unsatisfied dependencies for type
 [Validator]
  with
  qualifiers [@Default] at injection point
  [[UnbackedAnnotatedField]
  @Inject
  private
  org.hibernate.validator.internal.cdi.interceptor.**
  ValidationInterceptor.validator]
 
  at org.glassfish.weld.WeldDeployer.event(
  WeldDeployer.java:225)
 
  at org.glassfish.kernel.event.***
  *EventsImpl.send(EventsImpl.**
  java:131)
 
  at
  org.glassfish.internal.data.ApplicationInfo.load(**
  ApplicationInfo.java:328)
 
  at
  com.sun.enterprise.v3.server.ApplicationLifecycle.**
  deploy(
  ApplicationLifecycle.java:493)
 
  at
  com.sun.enterprise.v3.server.ApplicationLifecycle.**
  deploy(
  ApplicationLifecycle.java:219)
 
  at
 
 org.glassfish.deployment.admin.DeployCommand.execute(***
  *
  DeployCommand.java:491)
 
  at
 
 com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(**
  **
  CommandRunnerImpl.java:527)
 
  at
 
 com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(**
  **
  CommandRunnerImpl.java:523)
 
  at
 java.security.AccessController.doPrivileged(*
  ***
  Native
  Method)
 
  at javax.security.auth.Subject.
  doAs(Subject.java:356)
 
  at
  com.sun.enterprise.v3.admin.CommandRunnerImpl$2.**
  execute(
  CommandRunnerImpl.java:522)
 
  at
  com.sun.enterprise.v3.admin.CommandRunnerImpl.**
  doCommand(
  CommandRunnerImpl.java:546)
 
  at
  com.sun.enterprise.v3.admin.CommandRunnerImpl.**
  doCommand(
  CommandRunnerImpl.java:1423)
 
  at
 
 com.sun.enterprise.v3.admin.CommandRunnerImpl.access$***
  *
  1500(
  CommandRunnerImpl.java:108)
 
  at
  com.sun.enterprise.v3.admin.CommandRunnerImpl$**
  ExecutionContext.execute(CommandRunnerImpl.java:1762

Re: Apache CODI x JEE7 Glassfish4

2013-10-30 Thread Howard W. Smith, Jr.

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: JSF 2.2 status snapshot usage

2013-10-27 Thread Howard W. Smith, Jr.

Nice response, Leonardo.

Chris, it might be best to post your question on tomee's user list.



On Sun, Oct 27, 2013 at 4:44 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 I tried the test provided with the latest snapshot of myfaces 2.2.x and
 with a snapshot of tomee and it is working. There is no any relationship
 between CDI and passthrough elements. From this fragment:

 body jsf:id=body
 form jsf:id=form
 input type=text jsf:id=name
 pt:placeholder=Enter name
 jsf:value=#{helloBean.name}/
 button jsf:action=welcomeWelcome Me/button
 /form
 /body

 Here is the output:

 body id=body
 form id=form name=form method=post
 action=/tomee-test-1.0.0-SNAPSHOT/hello.jsf
 view-source:http://localhost:8080/tomee-test-1.0.0-SNAPSHOT/hello.jsf
 enctype=application/x-www-form-urlencoded
 input id=form:name name=form:name type=text value=
 placeholder=Enter name /
 button id=form:j_id_8 name=form:j_id_8 type=submitWelcome
 Me/button
 input type=hidden name=form_SUBMIT value=1 /
 input type=hidden name=javax.faces.ViewState
 id=j_id__v_0:javax.faces.ViewState:1
 value=KGflqkLizy6aeiWE+tznW4f+m6KKaOQ3GYAzpEGWPUMmMmaR /
 /form
 /body


 regards,

 Leonardo Uribe


 2013/10/27 ChrisHarris ch...@oneseasonmusic.com

  Hi, Howard.
 
  I'm trying to get MyFaces 2.2's Passthrough Elements and CDI working
 with a
  TomEE Snapshot from 2-3 days ago.  When I don't use Passthrough Elements,
  my
  CDI bean is acknowledge.  When I do use Passthrough Elements, my CDI bean
  is
  ignored.
 
  I've posted a simple web app to GitHub:
  https://github.com/MungTheWicked/tomee-test.git
 
  Can you help me pinpoint what the problem is?
 
 
 
  --
  View this message in context:
 
 http://myfaces.10567.n7.nabble.com/JSF-2-2-status-snapshot-usage-tp115852p116323.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: [OT but still JSF]: Clustering, session replication, and database, too

smiling big... while I wrote OP (last night, my time), I did find Thomas's
long discussion[1] with memcached-session-manager's committer/developer
(Martin). and I remember Thomas said that Martin (the mail list) is 'very
helpful', I think Thomas said that on primefaces forum.

Romain, that discussion might help a bit. I did not read it yet.

Thomas, I know that you remember that discussion...that's why you
lightly-and-indirectly mentioned that in primefaces forum. :)

[1]
https://groups.google.com/forum/#!msg/memcached-session-manager/yCTsORhu_3c/noV_IvW-YF0J


On Sun, Oct 20, 2013 at 5:34 AM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:

 JFYI:
 MyFaces+OWB on Tomcat with MSM is working fine.

Re: [OT but still JSF]: Clustering, session replication, and database, too

also, i'm still wondering about how database is replicated while clustering
the app.

On Sun, Oct 20, 2013 at 5:34 AM, Thomas Andraschko 
andraschko.tho...@gmail.com wrote:

 JFYI:
 MyFaces+OWB on Tomcat with MSM is working fine.

Re: [OT but still JSF]: Clustering, session replication, and database, too

romain, i have recognized and (gmail) star'red the mail list topics related
to tomee clustering. have not tried yet, but i don't see (any) mention of
how database is replicated while clustering tomee.

On Sun, Oct 20, 2013 at 2:11 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 PS: if tomee clustering has issues please help us working on it on trunk
 and tomee list

Re: [OT but still JSF]: Clustering, session replication, and database, too

interesting response, Jose', thanks!

for some time, I thought that it might be best to have separate server
(tomee + @EJB/DTO's + tomcat's jdbc + database) which is/becomes the
database tier. I guess I need to learn how to do/make remote calls to EJB
server from JSF web layer like you are doing.

i wonder if this is the typical/common/most-recommended-and-preferred
solution.

hmmm, avoid database replication.

i have even seen tomcat committer (mark thomas slideshow/document on
people.apache.org) mention that clustering your app should be avoided, if
possible (or only used, if necessary). :)

On Sun, Oct 20, 2013 at 1:30 AM, José Luis Cetina maxtorz...@gmail.comwrote:

I have a early experience with a mini cluster 2 servers using tomee +
memcached for session replication+ sticky session but using 1 only server
for database (i mean i dont use db replication). My jsf apps (ear) are
running in this mini cluster everithyng works fine except when i shutdown
tomee for do a re deploy i always see an xhtml parser error. I could never
configure it session replication with tomcat.

In your web apps just use distributable tag in web.xml and all other are
configuration. You can use memcached to not only session replication even
thougth for savr information of your app and with this you can share
information between your nodes and with this you dont persist information
that could be transient.
The result is incredible.

As i sayed i could never configure session replication with tomcat, the
only way i could do it is using memcached session replication.

I dont know if anybody here have any experience with this.

Regards Howard.
El 19/10/2013 22:49, Howard W. Smith, Jr. smithh032...@gmail.com
escribió:

I had a question or two, since I have been reading Java Summit -
Pitfalls
in EE[1] provided by Mark Struberg while having a discussion on tomee
user
list.

The following page stated the following:

Page 134
Clustering

* We use 'asymmetric clustering'
* use sticky sessions
* backup away the session to a memcached after each
request
* do not replicate the session over to other nodes!
* Session-Replication always in node pairs.
* only restore the session from the memcached if a failover
happened
* msm can be integrated into OWB:
http://code.google.com/p/memcached-session-manager/

Since it says, 'We use asymmetric clustering' and other suggestions were
made, I found it appropriate to direct my question(s) to MyFaces 'JSF'
user
list and committers.

is there some type of blog (or two or three) available that discuss how
to
properly cluster a tomcat/tomee/openwebbeans/myfaces JSF web app? also,
how
is the database replicated? I don't ever see database cluster/replication
discussed by JSF developers; i recently had to search for database
cluster
and saw 'replication', which is something i have not had to worry about
since my previous work involved database teams while i was doing
front-end/GUI software.

now that i am doing java ee and jsf, i would love to know how to do
database clustering and/or replicating database while clustering JSF
webapp. Of course, right now, i only have one tomee which references
'apache' derby (which is performing well, but I would love to get my feet
wet and cluster my web app + database). i did search derby's mail list
archives and i learned about sequioa and HA-JDBC (High-Availability
JDBC).

i was hoping to get an answer from MyFaces 'JSF' users/committers...based
on their experience. I think someone told me that they use mysql
(clustering); my preference is still 'apache' derby (smile). please
remember, i'm wondering if any blogs are available that discuss
clustering
tomcat (preference = tomee) + JSF web app (with database) + memcached
session manager.

Thomas has already started writing a blog[2] about this. I'm looking
forward to seeing sample config for it all (if available). :)

[1]

http://people.apache.org/~struberg/eesummit2013/Java%20EE%20Summit%20-%20pitfalls%20in%20EE.pdf

[2]

http://tandraschko.blogspot.com/2013/09/session-replication-clustering-failover.html

Re: [OT but still JSF]: Clustering, session replication, and database, too

On Sun, Oct 20, 2013 at 7:07 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:


 hmmm, avoid database replication.


honestly, I think HA-JDBC[1] (clustering the database) is all I really
need, because my app is quite fast, and only bottleneck is database layer.
I have seen David Blevins or Mark Struberg say that they reverted to
caching much of the data from database (in memory, on startup, I
guess/assume) to improve performance, but i wonder if caching the data is
really (really) necessary/recommended...

[1] http://ha-jdbc.github.io/

Re: [OT but still JSF]: Clustering, session replication, and database, too

interesting response, (and thanks) Mark!

glad you feel that way about clustering (expensive and not worth the
hassle), and scaling out the database for expensive queries/searches is
definitely what I want, because I really think the tomee+ stack is
performing very very well on my fast hardware. sadly, the (one) database
for queries+writes (performance) definitely can be improved!

will have to look into scaling out the database. thanks again!



On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg strub...@yahoo.de wrote:

 DB replication basically works with the transaction log (IBM DB/2
 terminology, in Oracle it's called transfer tables). Each
 update/insert/delete statement gets written into a file and you can pick
 this file up from another node. This secondary node then does exactly the
 same like the first node. See e.g. Master/Slave setup on MySQL.
 Means after a commit, after a few ms the secondary (slave) node has
 exactly the same info as the master node. And if the master node fails,
 then you can easily fall over to the slave node.

 This can also be very helpful to 'scale out' in case you need performance:

 All write stuff is only performed on the master node, but expensive
 queries/searches might be performed on the n replication nodes. Of course
 this needs a special handling in your app, but allows to move the expensive
 queries away from your primary node.

 All other 'real' cluster solutions are really expensive and most of the
 times not worth the hassle imo ;)


 LieGrue,
 strub

 PS: usually clustering of Servlets are done by just 'pairing' up always 2
 different servlet containers (tomcat nodes A+B, C+D) and have full session
 replication on them. Means whenever a request is done it will move the
 whole session content to the paired node.
 With the msm you can get away from this.



 - Original Message -
  From: Howard W. Smith, Jr. smithh032...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Sunday, 20 October 2013, 12:56
  Subject: Re: [OT but still JSF]: Clustering, session replication, and
 database, too
 
  also, i'm still wondering about how database is replicated while
 clustering
  the app.
 
 
  On Sun, Oct 20, 2013 at 5:34 AM, Thomas Andraschko 
  andraschko.tho...@gmail.com wrote:
 
   JFYI:
   MyFaces+OWB on Tomcat with MSM is working fine.

Re: [OT but still JSF]: Clustering, session replication, and database, too

On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg strub...@yahoo.de wrote:

 This can also be very helpful to 'scale out' in case you need performance:

 All write stuff is only performed on the master node, but expensive
 queries/searches might be performed on the n replication nodes. Of course
 this needs a special handling in your app, but allows to move the expensive
 queries away from your primary node.


hmmm, had a question or two, or seeking clarification (or a bit more
details or even a reference to a blog/article/document).

1. scale-out usually mean different physical servers? scaling out multiple
databases on one physical server, usually (or I would assume) means that
the hard drive becomes the bottleneck, if hard drive contain multiple
databases. right?

2. hmmm, had another question, if I remember it, then I can ask it later.

Re: [OT but still JSF]: Clustering, session replication, and database, too

wow, good point. I don't ever create new users in app. currently, the app
is only 'for-office-use' only, but some day, i'm hoping the app will serve
the customers of the business (and endusers have already mentioned
some/different requirements where customers can login and do some stuff in
the app, specific for customers, of course).

i have already learned to cache 'static' data in @ApplicationScoped; a lot
of lists that show up in selectOneMenu, etc..., are instantiated-and-cached
on startup of the app (and inside the @ApplicationScoped bean).

based on your response, I can definitely cache the user data and some of
the 'static' data in the database. hmmm, i think I am doing that too, on a
few of the tables, but I will have to check that.

of course, omnifaces came up with a way for selectOneMenu to avoid the need
to use @EJB to verify elements in the list (via selectone converter, or
something like that)... i am not using that (yet). your idea, to cache the
'static' lists in database is definitely a better (performance) option than
the omnifaces feature.

evidently, i need to cache more data from my database in my
@ApplicationScoped bean. i love that (CDI) @ApplicationScoped bean!



On Sun, Oct 20, 2013 at 8:30 AM, Mark Struberg strub...@yahoo.de wrote:

 With Caching I meant stuff like all the things which do not change often.

 There is a big difference between 'almost static' data and between 'living
 data'.

 E.g. the User data can surely be cached for 30 minutes. How often do you
 add or change a new user in your system?
 Same for e.g. an amazon catalogue. This can be perfectly be cached for at
 least an hour without having to hit the database again.
 Of course not all data can be cached, but lots of things which are kind of
 'configuration like' can. And this can take away a lot of hits from the
 database which is then free to serve other more important stuff.

 LieGrue,
 strub




 - Original Message -
  From: Howard W. Smith, Jr. smithh032...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Sunday, 20 October 2013, 13:19
  Subject: Re: [OT but still JSF]: Clustering, session replication, and
 database, too
 
  On Sun, Oct 20, 2013 at 7:07 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
 
   hmmm, avoid database replication.
 
 
  honestly, I think HA-JDBC[1] (clustering the database) is all I really
  need, because my app is quite fast, and only bottleneck is database
 layer.
  I have seen David Blevins or Mark Struberg say that they reverted to
  caching much of the data from database (in memory, on startup, I
  guess/assume) to improve performance, but i wonder if caching the data is
  really (really) necessary/recommended...
 
 
  [1] http://ha-jdbc.github.io/

Re: [OT but still JSF]: Clustering, session replication, and database, too

just remembered-and-revised 2nd question, below...

On Sun, Oct 20, 2013 at 8:35 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:


 On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg strub...@yahoo.de wrote:

 This can also be very helpful to 'scale out' in case you need performance:

 All write stuff is only performed on the master node, but expensive
 queries/searches might be performed on the n replication nodes. Of course
 this needs a special handling in your app, but allows to move the expensive
 queries away from your primary node.


 hmmm, had a question or two, or seeking clarification (or a bit more
 details or even a reference to a blog/article/document).

 1. scale-out usually mean different physical servers? scaling out multiple
 databases on one physical server, usually (or I would assume) means that
 the hard drive becomes the bottleneck, if hard drive contain multiple
 databases. right?

 2. this needs special handling in your app? can you please clarify?


thanks!

Re: [OT but still JSF]: Clustering, session replication, and database, too

Hmmm, i thought you said that you have EAR on one server and database on
separate server. are you running 2 tomee on same server; one tomee = EAR,
another tomee = database?



On Sun, Oct 20, 2013 at 11:52 AM, José Luis Cetina maxtorz...@gmail.comwrote:

 By the way im not using remote calls. All my apps are in the same ear with
 this i can inject my ejb local interface for calling methods in ejb.
 El 20/10/2013 07:49, Howard W. Smith, Jr. smithh032...@gmail.com
 escribió:

  just remembered-and-revised 2nd question, below...
 
  On Sun, Oct 20, 2013 at 8:35 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  
   On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg strub...@yahoo.de
  wrote:
  
   This can also be very helpful to 'scale out' in case you need
  performance:
  
   All write stuff is only performed on the master node, but expensive
   queries/searches might be performed on the n replication nodes. Of
  course
   this needs a special handling in your app, but allows to move the
  expensive
   queries away from your primary node.
  
  
   hmmm, had a question or two, or seeking clarification (or a bit more
   details or even a reference to a blog/article/document).
  
   1. scale-out usually mean different physical servers? scaling out
  multiple
   databases on one physical server, usually (or I would assume) means
 that
   the hard drive becomes the bottleneck, if hard drive contain multiple
   databases. right?
  
   2. this needs special handling in your app? can you please clarify?
  
  
  thanks!

Re: [OT but still JSF]: Clustering, session replication, and database, too

so, db server is on a separate machine/server on the network, and each EAR
is referencing the (one) db server via IP address?

also, do you have an embedded db server (running inside of tomee and using
tomcat jdbc pooling) or network db server/engine?


On Sun, Oct 20, 2013 at 5:32 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 Ear with all my apps in each server (2 server each with their own ear) then
 each server insert/read in another unique db server.
 El 20/10/2013 16:09, Howard W. Smith, Jr. smithh032...@gmail.com
 escribió:

  Hmmm, i thought you said that you have EAR on one server and database on
  separate server. are you running 2 tomee on same server; one tomee = EAR,
  another tomee = database?
 
 
 
  On Sun, Oct 20, 2013 at 11:52 AM, José Luis Cetina maxtorz...@gmail.com
  wrote:
 
   By the way im not using remote calls. All my apps are in the same ear
  with
   this i can inject my ejb local interface for calling methods in ejb.
   El 20/10/2013 07:49, Howard W. Smith, Jr. smithh032...@gmail.com
   escribió:
  
just remembered-and-revised 2nd question, below...
   
On Sun, Oct 20, 2013 at 8:35 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   

 On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg strub...@yahoo.de
wrote:

 This can also be very helpful to 'scale out' in case you need
performance:

 All write stuff is only performed on the master node, but
 expensive
 queries/searches might be performed on the n replication nodes. Of
course
 this needs a special handling in your app, but allows to move the
expensive
 queries away from your primary node.


 hmmm, had a question or two, or seeking clarification (or a bit
 more
 details or even a reference to a blog/article/document).

 1. scale-out usually mean different physical servers? scaling out
multiple
 databases on one physical server, usually (or I would assume) means
   that
 the hard drive becomes the bottleneck, if hard drive contain
 multiple
 databases. right?

 2. this needs special handling in your app? can you please clarify?


thanks!

Re: [OT but still JSF]: Clustering, session replication, and database, too

interesting. thanks Jose'


On Sun, Oct 20, 2013 at 9:03 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 El 20/10/2013 19:34, Howard W. Smith, Jr. smithh032...@gmail.com
 escribió:
 
  so, db server is on a separate machine/server on the network, and each
 EAR
  is referencing the (one) db server via IP address?
 

 Yes 2 tomee instances each in separete server point to a third server that
 only serve as db server. Thats why y have clustering only in webapps and
 not in db.

  also, do you have an embedded db server (running inside of tomee and
 using
  tomcat jdbc pooling) or network db server/engine?
 
 

 I use tomcat jdbc pooling (tomee with defined connections in tomee.xml)

  On Sun, Oct 20, 2013 at 5:32 PM, José Luis Cetina maxtorz...@gmail.com
 wrote:
 
   Ear with all my apps in each server (2 server each with their own ear)
 then
   each server insert/read in another unique db server.
   El 20/10/2013 16:09, Howard W. Smith, Jr. smithh032...@gmail.com
   escribió:
  
Hmmm, i thought you said that you have EAR on one server and database
 on
separate server. are you running 2 tomee on same server; one tomee =
 EAR,
another tomee = database?
   
   
   
On Sun, Oct 20, 2013 at 11:52 AM, José Luis Cetina 
 maxtorz...@gmail.com
wrote:
   
 By the way im not using remote calls. All my apps are in the same
 ear
with
 this i can inject my ejb local interface for calling methods in
 ejb.
 El 20/10/2013 07:49, Howard W. Smith, Jr. 
 smithh032...@gmail.com
 escribió:

  just remembered-and-revised 2nd question, below...
 
  On Sun, Oct 20, 2013 at 8:35 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  
   On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg 
 strub...@yahoo.de
  wrote:
  
   This can also be very helpful to 'scale out' in case you need
  performance:
  
   All write stuff is only performed on the master node, but
   expensive
   queries/searches might be performed on the n replication
 nodes. Of
  course
   this needs a special handling in your app, but allows to move
 the
  expensive
   queries away from your primary node.
  
  
   hmmm, had a question or two, or seeking clarification (or a bit
   more
   details or even a reference to a blog/article/document).
  
   1. scale-out usually mean different physical servers? scaling
 out
  multiple
   databases on one physical server, usually (or I would assume)
 means
 that
   the hard drive becomes the bottleneck, if hard drive contain
   multiple
   databases. right?
  
   2. this needs special handling in your app? can you please
 clarify?
  
  
  thanks!

Re: [OT but still JSF]: Clustering, session replication, and database, too

how many concurrent users is your app servingnormally or at peak times?

earlier, i think you mentioned response time is quite fast. did you throw
fast/high-performance hardware at db server, so db server responds fasts to
queries/updates?

do you have any expensive queries or updates...that may cause other
endusers to wait for a few seconds (or more)...if multiple users are using
your app, concurrently?

any (other db) performance issues that you'd like to share or you know
can/should be optimized to improve response time since one database is
serving 2 tomee/jsf/ear layer?




On Sun, Oct 20, 2013 at 9:03 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 El 20/10/2013 19:34, Howard W. Smith, Jr. smithh032...@gmail.com
 escribió:
 
  so, db server is on a separate machine/server on the network, and each
 EAR
  is referencing the (one) db server via IP address?
 

 Yes 2 tomee instances each in separete server point to a third server that
 only serve as db server. Thats why y have clustering only in webapps and
 not in db.

  also, do you have an embedded db server (running inside of tomee and
 using
  tomcat jdbc pooling) or network db server/engine?
 
 

 I use tomcat jdbc pooling (tomee with defined connections in tomee.xml)

  On Sun, Oct 20, 2013 at 5:32 PM, José Luis Cetina maxtorz...@gmail.com
 wrote:
 
   Ear with all my apps in each server (2 server each with their own ear)
 then
   each server insert/read in another unique db server.
   El 20/10/2013 16:09, Howard W. Smith, Jr. smithh032...@gmail.com
   escribió:
  
Hmmm, i thought you said that you have EAR on one server and database
 on
separate server. are you running 2 tomee on same server; one tomee =
 EAR,
another tomee = database?
   
   
   
On Sun, Oct 20, 2013 at 11:52 AM, José Luis Cetina 
 maxtorz...@gmail.com
wrote:
   
 By the way im not using remote calls. All my apps are in the same
 ear
with
 this i can inject my ejb local interface for calling methods in
 ejb.
 El 20/10/2013 07:49, Howard W. Smith, Jr. 
 smithh032...@gmail.com
 escribió:

  just remembered-and-revised 2nd question, below...
 
  On Sun, Oct 20, 2013 at 8:35 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  
   On Sun, Oct 20, 2013 at 8:17 AM, Mark Struberg 
 strub...@yahoo.de
  wrote:
  
   This can also be very helpful to 'scale out' in case you need
  performance:
  
   All write stuff is only performed on the master node, but
   expensive
   queries/searches might be performed on the n replication
 nodes. Of
  course
   this needs a special handling in your app, but allows to move
 the
  expensive
   queries away from your primary node.
  
  
   hmmm, had a question or two, or seeking clarification (or a bit
   more
   details or even a reference to a blog/article/document).
  
   1. scale-out usually mean different physical servers? scaling
 out
  multiple
   databases on one physical server, usually (or I would assume)
 means
 that
   the hard drive becomes the bottleneck, if hard drive contain
   multiple
   databases. right?
  
   2. this needs special handling in your app? can you please
 clarify?
  
  
  thanks!

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

2013-10-19 Thread Howard W. Smith, Jr.

On Fri, Oct 18, 2013 at 6:01 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Based on these test results, @PreDestroy of MyFaces 2.2 CDI @ViewScoped
 bean is executed via session invalidation and expiration. :)

 Great work and thank you, Leonardo, Gerhard, and MyFaces team! :)


When MyFaces 2.2.x is bundled with TomEE+ (snapshot), hopefully, I will
remember to start using MyFaces 2.2.x CDI @ViewScoped bean. Until then, I
will keep using MyFaces 2.1.12 and OmniFaces CDI @ViewScoped.

i hope to do more MyFaces 2.2 testing, if/when i have bandwidth and/or
use-case to do so. :)

[OT but still JSF]: Clustering, session replication, and database, too

2013-10-19 Thread Howard W. Smith, Jr.

I had a question or two, since I have been reading Java Summit - Pitfalls
in EE[1] provided by Mark Struberg while having a discussion on tomee user
list.

The following page stated the following:

Page 134
Clustering

Since it says, 'We use asymmetric clustering' and other suggestions were
made, I found it appropriate to direct my question(s) to MyFaces 'JSF' user
list and committers.

is there some type of blog (or two or three) available that discuss how to
properly cluster a tomcat/tomee/openwebbeans/myfaces JSF web app? also, how
is the database replicated? I don't ever see database cluster/replication
discussed by JSF developers; i recently had to search for database cluster
and saw 'replication', which is something i have not had to worry about
since my previous work involved database teams while i was doing
front-end/GUI software.

i was hoping to get an answer from MyFaces 'JSF' users/committers...based
on their experience. I think someone told me that they use mysql
(clustering); my preference is still 'apache' derby (smile). please
remember, i'm wondering if any blogs are available that discuss clustering
tomcat (preference = tomee) + JSF web app (with database) + memcached
session manager.

Thomas has already started writing a blog[2] about this. I'm looking
forward to seeing sample config for it all (if available). :)

[1]
http://people.apache.org/~struberg/eesummit2013/Java%20EE%20Summit%20-%20pitfalls%20in%20EE.pdf

[2]
http://tandraschko.blogspot.com/2013/09/session-replication-clustering-failover.html

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

On Thu, Oct 17, 2013 at 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote:


 You can check here:

 https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

 As soon as the job (#1164) is done, you can take the jars from that
 location (which should be the same).


wish i had good news/report, but the issue seems to still exist. please see
below.

I took latest myfaces 2.2.0 JARs from repository, dropped in tomee/lib,
started tomee (without dropping a new WAR, since WAR has not changed since
my last test).

tomee started and log included the following:

Oct 18, 2013 10:56:10 AM org.apache.myfaces.config.LogMetaInfUtils
logArtifact
INFO: Artifact 'myfaces-api' was found in version
'2.2.0-20131018.053919-2508' from path
'file:/C:/apache-tomee-plus-1.6.0-SNAPSHOT/lib/myfaces-api-2.2.0-20131018.053919-2508.jar'

Oct 18, 2013 10:56:10 AM org.apache.myfaces.config.LogMetaInfUtils
logArtifact
INFO: Artifact 'myfaces-impl' was found in version
'2.2.0-20131018.054743-2505' from path
'file:/C:/apache-tomee-plus-1.6.0-SNAPSHOT/lib/myfaces-impl-2.2.0-20131018.054743-2505.jar'

Oct 18, 2013 10:56:11 AM org.apache.myfaces.util.ExternalSpecifications
isCDIAvailable
INFO: MyFaces CDI support enabled

Oct 18, 2013 10:56:11 AM
org.apache.myfaces.spi.impl.DefaultInjectionProviderFactory
getInjectionProvider
INFO: Using InjectionProvider
org.apache.myfaces.spi.impl.Tomcat7AnnotationInjectionProvider


Test 1: login user, navigate to page which references CDI @ViewScoped bean,
F5/refresh browser to generate another CDI @ViewScoped bean, and logout
user, which invokes HttpSession.invalidate() via CDI @SessionScoped user
bean; @PreDestroy of CDI @ViewScoped bean was not executed. :(

Oct 18, 2013 10:56:31 AM jsf.users.pf_UsersController loginUser
INFO: administrator logged in at 10/18/2013 10:56 AM

Oct 18, 2013 10:56:49 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@6612072e

Oct 18, 2013 10:56:53 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@5421887b

Oct 18, 2013 10:57:03 AM jsf.users.pf_UsersController logout
INFO: administrator logged out at 10/18/2013 10:57 AM


Test 2: same as test 1, but session expire via 1 minute timeout, same
results (@PreDestroy of CDI @viewScoped bean was not executed)

Oct 18, 2013 10:57:50 AM jsf.users.pf_UsersController loginUser
INFO: administrator logged in at 10/18/2013 10:57 AM

Oct 18, 2013 10:58:01 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@432bb463

Oct 18, 2013 10:58:08 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@7049be5a

Oct 18, 2013 10:59:10 AM jsf.users.pf_UsersController sessionTimeout
INFO: administrator session ended at 10/18/2013 10:59 AM


I know I need to isolate/develop a test case, but not much bandwidth right
now; will, hopefully, develop a test case, ASAP.

just wanted to report my test results.

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

Gerhard, you're welcome. since i don't have bandwidth (right now),
maybe/hopefully, you can develop test case(s) per what we're
discussing/testing/reporting here...if you have bandwidth to do so. :)

On Fri, Oct 18, 2013 at 5:14 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

@howard:
that's one of the issues i mentioned during the discussion for MYFACES-3797
and i was going to test it tomorrow.
- thx for testing it and starting this thread.

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/18 Leonardo Uribe lu4...@gmail.com

You can check here:

https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

As soon as the job (#1164) is done, you can take the jars from that
location (which should be the same).

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

Okay, that is great. I'm waiting for the following folders to be
updated
with the latest version:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-api/2.2.0-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-impl/2.2.0-SNAPSHOT/

On Thu, Oct 17, 2013 at 10:47 PM, Leonardo Uribe lu4...@gmail.com
wrote:

I have found the bug. The problem was caused on a refactor, there was
an
old code that skip state saving when view map is empty, but now since
there
is a proxy for that implementing StateHolder, the map can be empty
but
it
holds the view scope key. Since with CDI the beans are stored
internally,
the map keeps empty but the scope is not, and if the view scope key
is
lost
the bean is recreated every time. But the beans are still in session,
and
with the session timeout bug the final result is @PreDestroy is not
called.

Please try again with the latest code, it should work. And please
lets
us
know what happened, if it is working or not.

regards,

Leonardo Uribe

2013/10/17 Leonardo Uribe lu4...@gmail.com

I have committed a fix for the problem with the timeout. But I'm
curious
about this problem, because I tested this scope and specifically
the
@PreDestroy stuff. It should work. But maybe there is a bug
somewhere

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

responses inline below,

On Thu, Oct 17, 2013 at 9:32 PM, Leonardo Uribe lu4...@gmail.com

wrote:

public void onSessionDestroyed()
{
// In CDI case, the best way to deal with this is use a
method
// with @PreDestroy annotation on a session scope bean
// ( ViewScopeBeanHolder.destroyBeans() ). There is no
need
// to do anything else in this location, but it is
advised
// in CDI the beans are destroyed at the end of the
request,
// not when invalidateSession() is called.
FacesContext facesContext =
FacesContext.getCurrentInstance();
if (facesContext != null)
{

I suppose what's going on there is in the context the session
invalidation
is done, FacesContext is null and @PreDestroy is ignored.

I can agree with that.

To be clear two questions:

1. Is manual session expiration working ? I suppose yes.

hmmm does manual session expiration == HttpSession.invalidate()?

When user click Logout button, my app execute/triggers
HttpSession.invalidate(), and @PreDestroy (on CDI @ViewScoped
bean)
is
not
executed.

2. Is session invalidation by a timeout working ? I suppose no.

correct, I just verified that in my app. see below.

- navigated to page that reference CDI @ViewScoped bean,
@PostConstruct
(below) executed

Oct 17, 2013 9:45:18 PM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@a9faef9

changed web.xml, session timeout = 1 minute, so tomee ended
session
via/after timeout, and @PreDestroy on CDI @SessionScoped (below)
executed,

Oct 17, 2013 9:45:53 PM jsf.users.pf_UsersController
sessionTimeout
INFO: administrator session ended at 10/17/2013 09:45 PM

but @PreDestroy on CDI @ViewScoped bean was not executed

I will try to provide an example to test.

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

On Thu, Oct 17, 2013 at 9:04 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 OmniFaces CDI @ViewScoped[1] executes @PreDestroy on session.invalidate()
 and that is what I like/expect, but MyFaces 2.2 CDI @ViewScoped
 implementation is not doing the same.


I am not trying to do any type of cross-forum posting. My goal is to
communicate/share my actual/expected test results.

In production, I am using TomEE 1.6.0 (OWB) + MyFaces 2.1.12 + OmniFaces
1.6(.1) CDI @ViewScoped, which invokes @PreDestroy on session invalidation
'and' expiration. Some minutes ago, I did a test against production app,
and just wanted to show you my 'actual test results' of production (which)
= 'expected test results' of MyFaces 2.2 CDI @ViewScoped.

In production, session timeout = 15 minutes, so I did a test against
production server, and did the 'same' test as Test 2 (session expiration)
in my previous post that included my latest test and test results of
MyFaces 2.2 CDI @ViewScoped.


Test: login user, navigate to page which references CDI @ViewScoped bean,
F5/refresh browser to generate another CDI @ViewScoped bean, and let
session expire via (15-minute) session timeout; @PreDestroy of (OmniFaces)
CDI @ViewScoped bean executed. see below.

Oct 18, 2013 11:20:29 AM jsf.users.pf_UsersController loginUser
INFO: administrator logged in at 10/18/2013 11:20 AM

Oct 18, 2013 11:20:39 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@650707eb

Oct 18, 2013 11:20:42 AM jsf.orders.OrderDocumentBean init
INFO: jsf.orders.OrderDocumentBean@132f168a

-- session expired --

Oct 18, 2013 11:35:43 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@132f168a

Oct 18, 2013 11:35:43 AM jsf.orders.OrderDocumentBean releaseResources
INFO: jsf.orders.OrderDocumentBean@650707eb

Oct 18, 2013 11:35:43 AM jsf.users.pf_UsersController sessionTimeout
INFO: administrator session ended at 10/18/2013 11:35 AM

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

Leonardo, that's great to hear and you're welcome. i'm a very happy MyFaces
user and definitely want to see MyFaces 2.2.x working as
RI/expected/intended/designed/spec'ified. :)

As before, I can wait for repository to be updated, can download, and test,
and can report, accordingly/afterwards.

thanks,
Howard



On Fri, Oct 18, 2013 at 3:05 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 I have committed a mixed solution between @PreDestroy annotation and
 ManagedBeanDestroyerListener. The idea is the first one in destroy the
 beans wins and the second one is just ignored. I have tested it with both
 configurations, so I hope it will work in your application.

 Let us know what happen and thanks Howard for report this. This is the kind
 of help that is very useful for the project in general.

 regards,

 Leonardo Uribe


 2013/10/18 Leonardo Uribe lu4...@gmail.com

  Hi
 
  I was able to reproduce the problem. I have been testing this issue
  against jetty / weld, and this issue comes when using tomcat / owb
  configuration. It seems when the session is destroyed,
  CDIManagedBeanHandlerImpl try to get a reference of ViewScopeBeanHolder
 and
  FlowScopeBeanHolder, but in that point of time the injection does not
 work
  as you can expect and ViewScopeBeanHolder is recreated.
 
  This issue is becoming difficult ...
 
  regards,
 
  Leonardo Uribe
 
 
 
  2013/10/18 Howard W. Smith, Jr. smithh032...@gmail.com
 
  On Thu, Oct 17, 2013 at 9:04 PM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   OmniFaces CDI @ViewScoped[1] executes @PreDestroy on
  session.invalidate()
   and that is what I like/expect, but MyFaces 2.2 CDI @ViewScoped
   implementation is not doing the same.
 
 
  I am not trying to do any type of cross-forum posting. My goal is to
  communicate/share my actual/expected test results.
 
  In production, I am using TomEE 1.6.0 (OWB) + MyFaces 2.1.12 + OmniFaces
  1.6(.1) CDI @ViewScoped, which invokes @PreDestroy on session
 invalidation
  'and' expiration. Some minutes ago, I did a test against production app,
  and just wanted to show you my 'actual test results' of production
 (which)
  = 'expected test results' of MyFaces 2.2 CDI @ViewScoped.
 
  In production, session timeout = 15 minutes, so I did a test against
  production server, and did the 'same' test as Test 2 (session
 expiration)
  in my previous post that included my latest test and test results of
  MyFaces 2.2 CDI @ViewScoped.
 
 
  Test: login user, navigate to page which references CDI @ViewScoped
 bean,
  F5/refresh browser to generate another CDI @ViewScoped bean, and let
  session expire via (15-minute) session timeout; @PreDestroy of
 (OmniFaces)
  CDI @ViewScoped bean executed. see below.
 
  Oct 18, 2013 11:20:29 AM jsf.users.pf_UsersController loginUser
  INFO: administrator logged in at 10/18/2013 11:20 AM
 
  Oct 18, 2013 11:20:39 AM jsf.orders.OrderDocumentBean init
  INFO: jsf.orders.OrderDocumentBean@650707eb
 
  Oct 18, 2013 11:20:42 AM jsf.orders.OrderDocumentBean init
  INFO: jsf.orders.OrderDocumentBean@132f168a
 
  -- session expired --
 
  Oct 18, 2013 11:35:43 AM jsf.orders.OrderDocumentBean releaseResources
  INFO: jsf.orders.OrderDocumentBean@132f168a
 
  Oct 18, 2013 11:35:43 AM jsf.orders.OrderDocumentBean releaseResources
  INFO: jsf.orders.OrderDocumentBean@650707eb
 
  Oct 18, 2013 11:35:43 AM jsf.users.pf_UsersController sessionTimeout
  INFO: administrator session ended at 10/18/2013 11:35 AM

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration

Cool! If your test works against Leonardo's latest changes/fixes, please
post/share your test results (and test steps). Thanks!

On Fri, Oct 18, 2013 at 3:45 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

hi howard,

i just planned a short (re-)test for starting a discussion like this one.

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/18 Howard W. Smith, Jr. smithh032...@gmail.com

Gerhard, you're welcome. since i don't have bandwidth (right now),
maybe/hopefully, you can develop test case(s) per what we're
discussing/testing/reporting here...if you have bandwidth to do so. :)

On Fri, Oct 18, 2013 at 5:14 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:

@howard:
that's one of the issues i mentioned during the discussion for
MYFACES-3797
and i was going to test it tomorrow.
- thx for testing it and starting this thread.

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/18 Leonardo Uribe lu4...@gmail.com

You can check here:

https://builds.apache.org/view/M-R/view/MyFaces/job/myfaces-current22-1/

As soon as the job (#1164) is done, you can take the jars from that
location (which should be the same).

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

Okay, that is great. I'm waiting for the following folders to be
updated
with the latest version:

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-api/2.2.0-SNAPSHOT/

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/myfaces-impl/2.2.0-SNAPSHOT/

On Thu, Oct 17, 2013 at 10:47 PM, Leonardo Uribe lu4...@gmail.com

wrote:

I have found the bug. The problem was caused on a refactor, there
was
an
old code that skip state saving when view map is empty, but now
since
there
is a proxy for that implementing StateHolder, the map can be
empty
but
it
holds the view scope key. Since with CDI the beans are stored
internally,
the map keeps empty but the scope is not, and if the view scope
key
is
lost
the bean is recreated every time. But the beans are still in
session,
and
with the session timeout bug the final result is @PreDestroy is
not
called.

Please try again with the latest code, it should work. And please
lets
us
know what happened, if it is working or not.

regards,

Leonardo Uribe

2013/10/17 Leonardo Uribe lu4...@gmail.com

I have committed a fix for the problem with the timeout. But
I'm
curious
about this problem, because I tested this scope and
specifically
the
@PreDestroy stuff. It should work. But maybe there is a bug
somewhere

regards,

Leonardo Uribe

2013/10/17 Howard W. Smith, Jr. smithh032...@gmail.com

responses inline below,

On Thu, Oct 17, 2013 at 9:32 PM, Leonardo Uribe
lu4...@gmail.com

wrote:

public void onSessionDestroyed()
{
// In CDI case, the best way to deal with this is
use
a
method
// with @PreDestroy annotation on a session scope
bean
// ( ViewScopeBeanHolder.destroyBeans() ). There is
no
need
// to do anything else in this location, but it is
advised
// in CDI the beans are destroyed at the end of the
request,
// not when invalidateSession() is called.
FacesContext facesContext =
FacesContext.getCurrentInstance();
if (facesContext != null)
{

I suppose what's going on there is in the context the
session
invalidation
is done, FacesContext is null and @PreDestroy is ignored.

I can agree with that.

To be clear two questions:

1. Is manual session expiration working ? I suppose yes.

hmmm does manual session expiration ==
HttpSession.invalidate()?

When user click Logout button, my app execute/triggers
HttpSession.invalidate(), and @PreDestroy (on CDI @ViewScoped
bean)
is
not
executed.

2. Is session invalidation by a timeout working ? I suppose
no.

correct

Re: [MyFaces 2.2] invoke @PreDestroy on (CDI) ViewScoped beans upon session expiration