Re: How to make submit button only work if connection is available?

[Mark Struberg]

FTR, I now did the following trick. Of course this could be enhanced with 
multilinguality etc. But it works for me.

function submitIfOnline() {
var xmlHttp = new XMLHttpRequest();
xmlHttp.open("HEAD", "index.http", false); // synchronous
try {
xmlHttp.send();
if (xmlHttp.status == 200) {
return true;
}
} catch (e) {
// nothiing to do;
}

alert("No connection available, please try again later!");
return false;
}



plus



The index.http heck is a convention I use in all projects.
Works so far.

LieGrue,
strub



> Am 19.01.2020 um 17:32 schrieb Thomas Andraschko 
> :
> 
> Hi,
> 
> I never needed something similar but i would do it the same.
> Maybe there are nicer ways, i would try to Google about it first.
> 
> 
> Mark Struberg  schrieb am So., 19. Jan. 2020,
> 16:34:
> 
>> Hi folks!
>> 
>> I'm right now designing a small only survey form with JSF-2.3. The problem
>> is that the survey should gather information from a cellar. And often there
>> is no WiFi nor mobile connection in those rooms. Thus it should not loose
>> data if the user presses the 'Save' button and the connection is not
>> available.
>> 
>> How to do this best?
>> 
>> I thought about an onclick which checks the connection via a ping to a
>> servlet (just returning true) and only then do a jsf.js submit(). If the
>> connection is not present it will present an alert() stating the user
>> should try later when he again has a connection.
>> 
>> Are there some better ways to do this?
>> 
>> txs and LieGrue,
>> strub
>> 
>> 

How to make submit button only work if connection is available?

[Mark Struberg]

Hi folks!

I'm right now designing a small only survey form with JSF-2.3. The problem is 
that the survey should gather information from a cellar. And often there is no 
WiFi nor mobile connection in those rooms. Thus it should not loose data if the 
user presses the 'Save' button and the connection is not available.

How to do this best?

I thought about an onclick which checks the connection via a ping to a servlet 
(just returning true) and only then do a jsf.js submit(). If the connection is 
not present it will present an alert() stating the user should try later when 
he again has a connection.

Are there some better ways to do this?

txs and LieGrue,
strub

Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope

[Mark Struberg]

The main point is: if I have my very own Object I put into the Session myself. 
And for whatever reason I create an InjectionTarget and apply CDI Injection 
into it. Then this _must not leak_. The specs (CDI & Servlet) are very clear 
about that.


LieGrue,
strub


On Monday, 5 September 2016, 8:18, Thony Lundin <thony.lun...@tieto.com> wrote:
>Hi,
>
>
>thankful for every effort, we have solved it temporarily by having a 
>sessionscope bean that keeps tracks of the viewscope beans for each user 
>session. When session expires the sessionscope bean is properly called and we 
>cleanup the references ourselves but this is a "dirty" fix since viewscopes 
>lives now as long as session (which it should not do in many cases) and in 
>fact we should not have to care about cleaning references ourselves :)
>
>
>Red Hat did some fix in EAP 6.1.1 (I believe) related to leaking viewscopes 
>but for some reason I think that fix was done on mojarra side, nothing was 
>changed in JBossWeb (as far as I know).
>
>
>Regards,
>Thony 
>
>
>On 5 September 2016 at 08:02, Mark Struberg <strub...@yahoo.de> wrote:
>
>Having glanced over the jboss code, I suspect they will have mem leaks with 
>Mojarra as well. Maybe that helps. I know a few people from JBoss, will try to 
>ping one of them.
>>
>>LieGrue,
>>Strub
>>
>>> Am 01.09.2016 um 15:24 schrieb Leonardo Uribe <lu4...@gmail.com>:
>>>
>>> Hi
>>>
>>> I'm cc to MyFaces users list, because these issues should be discussed
>>> there.
>>>
>>> It is a known issue, in resume it is JBossWeb fault, because that map
>>> should be a WeakHashMap but synchronized, to ensure the instances are
>>> discarded when the beans are serialised into session (in that case destroy
>>> will not be called). The fix should be done in WebInjectionContainer, but
>>> set org.apache.myfaces.SERIALIZE_ STATE_IN_SESSION
>>> <https://myfaces.apache.org/ core20/myfaces-impl/webconfig. 
>>> html#org_apache_myfaces_ SERIALIZE_STATE_IN_SESSION>
>>> to
>>> false could help to mitigate a bit the leak.
>>>
>>> There is an issue related to @PreDestroy and view scope in
>>>
>>> https://issues.apache.org/ jira/browse/MYFACES-4047
>>>
>>> but I guess it won't help in your case, because the leak is caused by the
>>> map itself.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2016-09-01 3:34 GMT-05:00 Thony Lundin <thony.lun...@tieto.com>:
>>>
>>>> Hi Leonardo,
>>>>
>>>> writing you since you are MyFaces core project lead and want to ask about
>>>> a possible issue in MyFaces 2.2.10 regarding not released viewscope beans.
>>>>
>>>> I have seen on Internet that there was multiple such issues reported for
>>>> mojarra in the past and Red Hat did some fix in their EAP 6.1.1 or
>>>> so (in the mojarra module) to solve this issue.
>>>>
>>>> Problem for us is that we came from using tomcat and went on top of Red
>>>> Hat EAP with JBossWeb and wanted to keep MyFaces (since it provided us with
>>>> best performance and configuration options) but we are hit by this memory
>>>> leak that somehow MyFaces and JBossWeb do not interact properly when a
>>>> viewscope bean is getting invalidated. Problem is that when viewscope is
>>>> invalidated the reference to our controllers are still kept in JBossWeb
>>>> WebInjectionContainer and it is kept there forever, even if session 
>>>> expires?
>>>>
>>>> org.jboss.as.web.deployment. WebInjectionContainer @ 0xc45318d8 | 32 |
>>>> 649,769,928 | 73.07% |- org.jboss.as.web.deployment. 
>>>> ConcurrentReferenceHashMap
>>>> @ 0xc4532518 | 48 | 649,766,792 | 73.07% | '- org.jboss.as.web.deployment.
>>>> ConcurrentReferenceHashMap$ Segment[4] @ 0xc4532548| 32 | 649,766,744 |
>>>> 73.07% | |- org.jboss.as.web.deployment. ConcurrentReferenceHashMap$ 
>>>> Segment
>>>> @ 0xc4532568| 56 | 187,909,296 | 21.13%
>>>>
>>>> Red Hat will not do anything due to that they only support mojarra so I am
>>>> asking if this is something known on MyFaces project and if there is
>>>> something that could be done on MyFaces core side about it (just asking
>>>> since same problem for JBossWeb was solved somehow on mojarra side)
>>>> or if you think this is a JBossWeb fault?
>>>>
>>>> Grateful for any information you can share on this issue.
>>>>
>>>> Best Regards,
>>>> Thony
>>>>
>>
>>
>
>
>

Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope

[Mark Struberg]

Having glanced over the jboss code, I suspect they will have mem leaks with 
Mojarra as well. Maybe that helps. I know a few people from JBoss, will try to 
ping one of them.

LieGrue,
Strub

> Am 01.09.2016 um 15:24 schrieb Leonardo Uribe :
> 
> Hi
> 
> I'm cc to MyFaces users list, because these issues should be discussed
> there.
> 
> It is a known issue, in resume it is JBossWeb fault, because that map
> should be a WeakHashMap but synchronized, to ensure the instances are
> discarded when the beans are serialised into session (in that case destroy
> will not be called). The fix should be done in WebInjectionContainer, but
> set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
> 
> to
> false could help to mitigate a bit the leak.
> 
> There is an issue related to @PreDestroy and view scope in
> 
> https://issues.apache.org/jira/browse/MYFACES-4047
> 
> but I guess it won't help in your case, because the leak is caused by the
> map itself.
> 
> regards,
> 
> Leonardo Uribe
> 
> 
> 2016-09-01 3:34 GMT-05:00 Thony Lundin :
> 
>> Hi Leonardo,
>> 
>> writing you since you are MyFaces core project lead and want to ask about
>> a possible issue in MyFaces 2.2.10 regarding not released viewscope beans.
>> 
>> I have seen on Internet that there was multiple such issues reported for
>> mojarra in the past and Red Hat did some fix in their EAP 6.1.1 or
>> so (in the mojarra module) to solve this issue.
>> 
>> Problem for us is that we came from using tomcat and went on top of Red
>> Hat EAP with JBossWeb and wanted to keep MyFaces (since it provided us with
>> best performance and configuration options) but we are hit by this memory
>> leak that somehow MyFaces and JBossWeb do not interact properly when a
>> viewscope bean is getting invalidated. Problem is that when viewscope is
>> invalidated the reference to our controllers are still kept in JBossWeb
>> WebInjectionContainer and it is kept there forever, even if session expires?
>> 
>> org.jboss.as.web.deployment.WebInjectionContainer @ 0xc45318d8 | 32 |
>> 649,769,928 | 73.07% |- 
>> org.jboss.as.web.deployment.ConcurrentReferenceHashMap
>> @ 0xc4532518 | 48 | 649,766,792 | 73.07% | '- org.jboss.as.web.deployment.
>> ConcurrentReferenceHashMap$Segment[4] @ 0xc4532548| 32 | 649,766,744 |
>> 73.07% | |- org.jboss.as.web.deployment.ConcurrentReferenceHashMap$Segment
>> @ 0xc4532568| 56 | 187,909,296 | 21.13%
>> 
>> Red Hat will not do anything due to that they only support mojarra so I am
>> asking if this is something known on MyFaces project and if there is
>> something that could be done on MyFaces core side about it (just asking
>> since same problem for JBossWeb was solved somehow on mojarra side)
>> or if you think this is a JBossWeb fault?
>> 
>> Grateful for any information you can share on this issue.
>> 
>> Best Regards,
>> Thony
>> 

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

[Mark Struberg]

btw if you use the tomee-maven-plugin then you can automatically 'tune' the 
lib folders with something like this:



build
    plugins
    plugin
    groupIdorg.apache.openejb.maven/groupId
    artifactIdtomee-maven-plugin/artifactId
    version${tomee.mavenplugin.version}/version

    configuration
...
  libs
    
libmysql:mysql-connector-java:${mysql-connector.version}/lib 
    libremove:myfaces-api/lib
    libremove:myfaces-impl/lib
    /libs
    /configuration


for adding jars to your tomee plugin, just use the maven GAV coordinates. If it 
starts with remove:xxx, then it will remove all the jars starting with this 
string.

LieGrue,
strub


On Wednesday, 12 February 2014, 19:02, Karl Kildén karl.kil...@gmail.com 
wrote:
 
Try starting it outside of your IDE. If that works remove and reconnect IDE
to a fresh TomEE on another path with the desired changes under /lib



On 12 February 2014 18:48, maurojava mauro2java2...@gmail.com wrote:

 my jsk is : jdk1.7.0_25
 my tomee :tomee 1.6.0 plus
 i have added myfaces-api2.2jar and myfaces-impl2.2.jar to tomee/lib
 i have removed myfaces 2.1 impl and api
 i not use codi




 --
 View this message in context:
 http://myfaces.10567.n7.nabble.com/myfaces-2-2-foe-replace-myfaces-2-1-into-tomee-tp117127p117135.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: myfaces 2.2 foe replace myfaces 2.1 into tomee

[Mark Struberg]

GAV =  groupId + artifactId + version.

See the sample of the mysql connector


libmysql:mysql-connector-java:${mysql-connector.version}/lib

For myfaces this would be

liborg.apache.myfaces.core:myfaces-api:${myfaces.version}/lib

LieGrue,
strub




On Thursday, 13 February 2014, 19:09, maurojava mauro2java2...@gmail.com 
wrote:
 
escuse me  Mark i not know maven
how i can make the last your indication:
-
for adding jars to your tomee plugin, just use the maven GAV coordinates.
If it starts with remove:xxx, then it will remove all the jars starting
with this string.
---

how i can put the jars dor tomme plugin using the GAV coordinates?


2014-02-13 18:44 GMT+01:00 Mark Struberg [via MyFaces] 
ml-node+s10567n117170...@n7.nabble.com:

 btw if you use the tomee-maven-plugin then you can automatically 'tune'
 the lib folders with something like this:



 build
                 plugins
                     plugin
                         groupIdorg.apache.openejb.maven/groupId
                         artifactIdtomee-maven-plugin/artifactId
                         version${tomee.mavenplugin.version}/version

                         configuration
 ...
                           libs

 libmysql:mysql-connector-java:${mysql-connector.version}/lib
                                 libremove:myfaces-api/lib
                                 libremove:myfaces-impl/lib
                             /libs
                         /configuration


 for adding jars to your tomee plugin, just use the maven GAV coordinates.
 If it starts with remove:xxx, then it will remove all the jars starting
 with this string.

 LieGrue,
 strub


 On Wednesday, 12 February 2014, 19:02, Karl Kildén [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=117170i=0
 wrote:

 Try starting it outside of your IDE. If that works remove and reconnect
 IDE

 to a fresh TomEE on another path with the desired changes under /lib
 
 
 
 On 12 February 2014 18:48, maurojava [hidden 
 email]http://user/SendEmail.jtp?type=nodenode=117170i=1
 wrote:
 
  my jsk is : jdk1.7.0_25
  my tomee :tomee 1.6.0 plus
  i have added myfaces-api2.2jar and myfaces-impl2.2.jar to tomee/lib
  i have removed myfaces 2.1 impl and api
  i not use codi
 
 
 
 
  --
  View this message in context:
 
 http://myfaces.10567.n7.nabble.com/myfaces-2-2-foe-replace-myfaces-2-1-into-tomee-tp117127p117135.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
 
 


 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://myfaces.10567.n7.nabble.com/myfaces-2-2-foe-replace-myfaces-2-1-into-tomee-tp117127p117170.html
  To unsubscribe from myfaces 2.2 foe replace myfaces 2.1 into tomee, click
 herehttp://myfaces.10567.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=117127code=bWF1cm8yamF2YTIwMTFAZ21haWwuY29tfDExNzEyN3wtMTExNzE4NzYyNQ==
 .
 NAMLhttp://myfaces.10567.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://myfaces.10567.n7.nabble.com/myfaces-2-2-foe-replace-myfaces-2-1-into-tomee-tp117127p117173.html

Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Apache CODI x JEE7 Glassfish4

[Mark Struberg]

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

[Mark Struberg]

yea, but that is minor tho what CODI can do.

LieGrue,
strub






 From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Thursday, 31 October 2013, 0:24
Subject: Re: Apache CODI x JEE7 Glassfish4
 


@mark:
the parameter conversationPropagation was added in 1.1.


regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces




2013/10/31 Mark Struberg strub...@yahoo.de

Nope, we didn't touch @ConversationScoped a bit in CDI-1.1.

The main changes in CDI-1.1 have been clarifications. But most of them are 
already implemented in OWB and Weld, even in the CDI-1.0 targetting versions.
There have been a few good Extensions in the Extension area, scanning, etc  
in CDI-1.1.

LieGrue,
strub





- Original Message -
 From: Kay Wrobel kay.wro...@gmx.net
 To: MyFaces Discussion users@myfaces.apache.org
 Cc:
 Sent: Wednesday, 30 October 2013, 22:44
 Subject: Re: Apache CODI x JEE7 Glassfish4

 One could still investigate if @ConversatioScoped has improved in CDI
 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the
 right person to discuss that annotation, but it's a thought.

 On 10/30/2013 04:33 PM, Gerhard Petracek wrote:
  hi edilmar,

  apache deltaspike is the official successor of codi/seam/... (including
  support for ee7+).
  some parts (including codi-conversations) are still on our list, however,
  you can try it with [1] (it's the same code - just different packages
 and
  based on deltaspike).

  @kay (and your comment about conversations):
  std. cdi conversations are available since cdi 1.0 and have many
  disadvantages compared to codi-conversations.
  that was the reason for introducing codi-conversations at all (see e.g.
  [2]) - they are still useful.

  regards,
  gerhard

  [1]
  http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
  [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html

  http://www.irian.at

  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German

  Professional Support for Apache MyFaces



  2013/10/30 Edilmar Alves edili...@gmail.com

  I think CODI is a great replacement for my actual environment, the only
  problem is to deploy in GF4.


  2013/10/30 Edilmar Alves edili...@gmail.com

  Hi,

  I use CODI ConversationScoped and @Inject Conversation because it
 is
  better than original CDI implementation.
  I have many java files using CODI at this time.
  Then, to go back to CDI, I will have to change many files, and I
 don't
  know if the webapp will continue to work 100%,
  because the management of the Conversation object made by CODI is
 great,
  for example it decreases problems like
  LazyException caused by Hibernate with JSF fields.


  2013/10/30 Kay Wrobel kay.wro...@gmx.net

  Also, you might want to check with RichFaces. I found this blog
 
  http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
  release-announcement.html

 http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html
  and the moderator mentions that full JSF 2.2 support is planned
 for
  RichFaces 5. I had some of the same issues with PrimeFaces 3.5
 which was
  incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0
 to come
  out.

  On 10/30/2013 03:17 PM, Kay Wrobel wrote:

  I'm looking at CDI 1.1 spec
 http://docs.jboss.org/cdi/**
  spec/1.1/cdi-spec.html
  http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html
  and ot looks like @ConversationScope is already part of CDI
 1.1, no
  CODI
  needed for that.

  GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 
  http://www.cdi-spec.org/**download/
 http://www.cdi-spec.org/download/
  which is bundled inside the weld-osgi-bundle.jar.

  On 10/30/2013 02:55 PM, Edilmar Alves wrote:

  Hi friends,

  Thanks for help!
  Look at these situations...
  1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour.
 But I use in
  production 3.1.1 because there are many servers using
 my webapp with
  this
  version, and it is not simple to upgrade.
  2) I am testing Glassfish 4/JEE7 because Glassfish is
 the oficial
  server
  approved by the enterprise, I can't change for
 other server. Then, I
  test
  version 4 because there are some other functionalities
 I would like to
  use
  from JEE7 in my webapp, but with CODI it is not
 possible to deploy.
  3) I didn't understand the suggestion to use
 Myfaces 2.2. Has it a
  replacement for the CODI ConversationScoped, for
 example? Because this
  scope is used in many pages of my webapp, the main
 resource from CODI
  that
  I use and need an alternative. I can't use Myfaces,
 for example, to
  change
  Richfaces.


  2013/10/30 Kay Wrobel kay.wro...@gmx.net

    Or he can stick with Glassfish 3.1.2.2, which is
 GlassFish' last
  final

Re: Apache CODI x JEE7 Glassfish4

[Mark Struberg]

Nope, we didn't touch @ConversationScoped a bit in CDI-1.1.

The main changes in CDI-1.1 have been clarifications. But most of them are 
already implemented in OWB and Weld, even in the CDI-1.0 targetting versions.
There have been a few good Extensions in the Extension area, scanning, etc  in 
CDI-1.1.

LieGrue,
strub




- Original Message -
 From: Kay Wrobel kay.wro...@gmx.net
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, 30 October 2013, 22:44
 Subject: Re: Apache CODI x JEE7 Glassfish4
 
 One could still investigate if @ConversatioScoped has improved in CDI 
 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the 
 right person to discuss that annotation, but it's a thought.
 
 On 10/30/2013 04:33 PM, Gerhard Petracek wrote:
  hi edilmar,
 
  apache deltaspike is the official successor of codi/seam/... (including
  support for ee7+).
  some parts (including codi-conversations) are still on our list, however,
  you can try it with [1] (it's the same code - just different packages 
 and
  based on deltaspike).
 
  @kay (and your comment about conversations):
  std. cdi conversations are available since cdi 1.0 and have many
  disadvantages compared to codi-conversations.
  that was the reason for introducing codi-conversations at all (see e.g.
  [2]) - they are still useful.
 
  regards,
  gerhard
 
  [1]
  http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html
  [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2013/10/30 Edilmar Alves edili...@gmail.com
 
  I think CODI is a great replacement for my actual environment, the only
  problem is to deploy in GF4.
 
 
  2013/10/30 Edilmar Alves edili...@gmail.com
 
  Hi,
 
  I use CODI ConversationScoped and @Inject Conversation because it 
 is
  better than original CDI implementation.
  I have many java files using CODI at this time.
  Then, to go back to CDI, I will have to change many files, and I 
 don't
  know if the webapp will continue to work 100%,
  because the management of the Conversation object made by CODI is 
 great,
  for example it decreases problems like
  LazyException caused by Hibernate with JSF fields.
 
 
  2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
  Also, you might want to check with RichFaces. I found this blog 
 
  http://www.bleathem.ca/blog/**2013/09/richfaces-434final-**
  release-announcement.html
 
 http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html
  and the moderator mentions that full JSF 2.2 support is planned 
 for
  RichFaces 5. I had some of the same issues with PrimeFaces 3.5 
 which was
  incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 
 to come
  out.
 
  On 10/30/2013 03:17 PM, Kay Wrobel wrote:
 
  I'm looking at CDI 1.1 spec 
 http://docs.jboss.org/cdi/**
  spec/1.1/cdi-spec.html
  http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html
  and ot looks like @ConversationScope is already part of CDI 
 1.1, no
  CODI
  needed for that.
 
  GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 
  http://www.cdi-spec.org/**download/ 
 http://www.cdi-spec.org/download/
  which is bundled inside the weld-osgi-bundle.jar.
 
  On 10/30/2013 02:55 PM, Edilmar Alves wrote:
 
  Hi friends,
 
  Thanks for help!
  Look at these situations...
  1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. 
 But I use in
  production 3.1.1 because there are many servers using 
 my webapp with
  this
  version, and it is not simple to upgrade.
  2) I am testing Glassfish 4/JEE7 because Glassfish is 
 the oficial
  server
  approved by the enterprise, I can't change for 
 other server. Then, I
  test
  version 4 because there are some other functionalities 
 I would like to
  use
  from JEE7 in my webapp, but with CODI it is not 
 possible to deploy.
  3) I didn't understand the suggestion to use 
 Myfaces 2.2. Has it a
  replacement for the CODI ConversationScoped, for 
 example? Because this
  scope is used in many pages of my webapp, the main 
 resource from CODI
  that
  I use and need an alternative. I can't use Myfaces, 
 for example, to
  change
  Richfaces.
 
 
  2013/10/30 Kay Wrobel kay.wro...@gmx.net
 
    Or he can stick with Glassfish 3.1.2.2, which is 
 GlassFish' last
  final
  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 

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

[Mark Struberg]

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

[Mark Struberg]

Try to avoid any remoting. Regardless whether remote EJB or even worse SOAP. 
The power it takes to transfer all your state to a different node is usually 
more than it takes to render your JSF pages. If you have performance issues 
then rather scale-out by adding another node and have a haproxy or any other 
load balancer with sticky session in front of it. 

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:07
 Subject: 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

[Mark Struberg]

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: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

[Mark Struberg]

 but basically it isn't an issue of codi -
 please file an issue for WAS8.

+1 might probably be a problem of WAS using EJB proxies for CDI beans.

LieGrue,
strub




- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
 adr_gonza...@yahoo.fr
 Cc: 
 Sent: Thursday, April 4, 2013 11:06 AM
 Subject: Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
 hi adrian,
 
 we can do EXTCDI-308 easily, but basically it isn't an issue of codi -
 please file an issue for WAS8.
 
 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/4/3 Adrian Gonzalez adr_gonza...@yahoo.fr
 
  Just created :
   * https://issues.apache.org/jira/browse/EXTCDI-307 (EAR support for
  JBoss)
   * https://issues.apache.org/jira/browse/EXTCDI-308 (EAR support for WAS)
  and attached the corresponding patches.
 
  Please note that these patches doesn't cover support for all the CODI
  modules (I've tested EAR support only for the JSF module).
 
  Regards,
  Adrian
 
 
  - Mail original -
  De : Adrian Gonzalez adr_gonza...@yahoo.fr
  À : MyFaces Discussion users@myfaces.apache.org
  Cc :
  Envoyé le : Mercredi 3 avril 2013 11h52
  Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
  Hello,
 
  I just resolved java.lang.NullPointerException: null on Websphere
  (8.0.0.4) (see [2] below).
 
  This issue was due :
  When a client calls a method with package level access on a CDI bean, WAS
  8.0.0.4 doesn't execute the interceptor chain.
  The call is executed directly on the javassist class (and @Inject fields
  are null in the javassist class - so we get the NPE).
  For now, just setting method visibility to public on
  both JsfRequestLifecycleBroadcaster#broadcastBeforeEvent et
  JsfRequestLifecycleBroadcaster#broadcastAfterEvent resolves this issue.
 
 
  Question is : bug located in Websphere or in CODI ?
  In other workds, does CDI 1.0 supports calling methods with package level
  access ?
  I looked at the CDI spec, but didn't find anything on this matter.
  Interceptor spec 1.1 supports it (from chapter Method interceptors :
  'Around-invoke methods can have public, private, protected, or package
  level access. An
  around-invoke method must not be declared as final or static.')
  If it's in WAS, I can open a PMR for this.
   I will open 2 tickets for EAR support : one for JBoss and another one for
  Websphere and attach both patches.
  Sounds good ?
 
 
  Best regards,
  Adrian
 
 
 
 
 
 
  
  De : Adrian Gonzalez adr_gonza...@yahoo.fr
  À : MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
  strub...@yahoo.de
  Envoyé le : Mardi 26 mars 2013 17h22
  Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
  Hello,
 
  Sorry for the late feedback.
  Currently struggling on making it work with Websphere 8 (as Denis before)
  before sending a patch.
 
  I've corrected locally the IllegalAccessError on 
 DefaultBeanEntryFactory
  [1] (just making DefaultBeanEntryFactory  public corrects the issue).
  Now I get only the NullPointerException
  on JsfRequestLifecycleBroadcaster.broadcastBeforeEvent [2].
  I know I could set classloader to APPLICATION, but as Denis said, it is
  not officially supported by Websphere.
  So I prefer to modify CODI's code (if possible) to be able to use it on
  WAS.
 
  I don't have anymore time this week to work on these issues, so 
 I'll
  follow up next week.
 
  Thanks,
  Adrian
 
 
  [1]
  [3/26/13 16:52:53:494 CET] 00bc
  webapp        E
  com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet
  Error]-[Faces Servlet]: java.lang.RuntimeException: by
  java.lang.IllegalAccessError:
 
 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
                  at
  javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)
 
  at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)
 
  at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)
 
  at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)
 
  [2] java.lang.NullPointerException: null
 
  at
 
 
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:58)
  ~[myfaces-extcdi-bundle-jsf20-1.0.5.nxs1-SNAPSHOT.jar:1.0.5.nxs1-SNAPSHOT]
 
  at
 
 
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:56)
  ~[myfaces-extcdi-bundle-jsf20-1.0.5.nxs1-SNAPSHOT.jar:1.0.5.nxs1-SNAPSHOT]
 
  at
 
 
 org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
  ~[com.ibm.ws.jsf.myfaces.jar:na

Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x

[Mark Struberg]

Hi folks!

a.) I hope you find CODI useful nontheless ;)
b.) if this fix solves the problems, can you please open a JIRA for the EXTCDI 
project and attach the patch?

txs and LieGrue,
strub




- Original Message -
 From: Пестов Алексей pestov.ale...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org; Adrian Gonzalez 
 adr_gonza...@yahoo.fr
 Cc: 
 Sent: Thursday, March 21, 2013 8:38 PM
 Subject: Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
 Adrian, thank you very much for quick response!
 
 I'll try to apply your patch.
 
 
 On Thu, Mar 21, 2013 at 9:38 PM, Adrian Gonzalez 
 adr_gonza...@yahoo.frwrote:
 
  Hi Aleksey,
 
  Here's the patch file (my first one with git).
  I've obtained it executing [1]
 
  I've changed CODI version from 1.0.5 to 1.0.5.nxs1-SNAPSHOT in the same
  commit (so sorry, you have this modification with this patch).
 
 
  Hope this helps,
 
  [1] execute the following line after cloning
  https://github.com/gonzalad/myfaces-extcdi
  git diff d141ac555cb263c6413c6f4ddebbd41bd4768eac^
  d141ac555cb263c6413c6f4ddebbd41bd4768eac on my
 
 
 
 
  - Mail original -
  De : Пестов Алексей pestov.ale...@gmail.com
  À : users@myfaces.apache.org
  Cc :
  Envoyé le : Jeudi 21 mars 2013 18h22
  Objet : Re: CODI ViewAccessScoped issue with EAR on JBoss 7.1.x
 
  Hello. Today I decided to use it and got the same problem. This does not
  work in the EAR to JBoss 7.1.1.
 
  Adrian, could you please make a patch (*.diff) with your solution?
 
  I would also like to know about your option 2)
 
  2. remove @JsfPhaseListener and rely on classic phaseListeners 
 configured
  with faces-config.xml
 
  Can do this in faces-config.xml of my application, not in
  myfaces-extcdi-bundle-jsf20-1.0.5.jar
  ?
 
  Best regards,
 
  Aleksey
 
 
 
 
 -- 
 С уважением,
 Алексей Пестов
 тел. +7 (925) 067-32-13

Re: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml leads to endless loop?

[Mark Struberg]

Hi Heiko!

Does this also happen on Firefox or only on IE? And if so, which IE version 
exactly?

LieGrue,
strub




- Original Message -
 From: it-media.k...@daimler.com it-media.k...@daimler.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Friday, February 1, 2013 8:20 AM
 Subject: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml 
 leads to endless loop?
 
 Hello everone,
 
 I've tried to change the Nag-Screen of the Client Side Window 
 Handler of 
 EXTCDI by specializing ClientConfig in the following way:
 
 @SessionScoped
 @Specializes
 public class MaksClientConfig extends ClientConfig implements Serializable
 {
     /** ID necessary for serialization */
     private static final long serialVersionUID = -3974881285407719139L;
 
     private static final String MAKS_WINDOW_HANDLER_HTML_FILE = 
 insecure/windowhandler.html;
 
     @Override
     public String getWindowHandlerResourceLocation()
     {
         return MAKS_WINDOW_HANDLER_HTML_FILE;
     }
 }
 
 The file insecure/windowhandler.html is a simple COPY of the 
 original 
 file delivered with EXTCDI 1.0.6-SNAPSHOT. When I do so, this ends up in 
 an endless loop in Internet Explorer. The parameter 'windowId' always 
 stays automatedEntryPoint. 
 
 The cookie is once set to something like 
 7742-codiWindowId=automatedEntryPoint and on a second reload to another 
 number e.g. 8631-codiWindowId=automatedEntryPoint, but it cycles here and 
 does not continue.
 
 What do I miss here? 
 
 Thanks,
 
 Best regards,
 
 Heiko
 
 --
 Heiko Kopp / Fa. Vision iT media GmbH
 
 Programming today is a race between software engineers striving to build 
 bigger and better idiot-proof programs, and the universe trying to build 
 bigger and better idiots. So far, the universe is winning. 
 
 If you are not the intended addressee, please inform us immediately that you 
 have received this e-mail in error, and delete it. We thank you for your 
 cooperation.  

Re: Re: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml leads to endless loop?

[Mark Struberg]

Hi Heiko!

I'll create a unit test for it and test it before we kick off the build for the 
release.

LieGrue,
strub




- Original Message -
 From: it-media.k...@daimler.com it-media.k...@daimler.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Friday, February 1, 2013 1:26 PM
 Subject: Re: Re: EXTCDI - Specializing ClientConfig with different 
 WindowHandlerHtml leads to endless loop?
 
 Hello,
 
 it is happening in IE 8 and FF 19 beta 4. Both react in the same way. This 
 only happends as soon as I override the ClientConfig with my own version 
 like this:
 
 @SessionScoped
 @Specializes
 public class MaksClientConfig extends ClientConfig implements Serializable
 {
     /** ID necessary for serialization */
     private static final long serialVersionUID = -3974881285407719139L;
 
     private static final String MAKS_WINDOW_HANDLER_HTML_FILE = 
 insecure/windowhandler.html;
 
     @Override
     public String getWindowHandlerResourceLocation()
     {
         return MAKS_WINDOW_HANDLER_HTML_FILE;
     }
 }
 
 If I set the handler back to its original position like this:
 
 private static final String MAKS_WINDOW_HANDLER_HTML_FILE = 
 static/windowhandler.html;
 
 it works again. 
 
 Very weird!!!
 
 Greets,
 
 Heiko
 
 --
 Heiko Kopp / Fa. Vision iT media GmbH
 
 Programming today is a race between software engineers striving to build 
 bigger and better idiot-proof programs, and the universe trying to build 
 bigger and better idiots. So far, the universe is winning. 
 
 
 
 strub...@yahoo.de 
 01.02.2013 09:46
 Bitte antworten an
 users@myfaces.apache.org
 
 
 An
 users@myfaces.apache.org
 Kopie
 
 Thema
 Re: EXTCDI - Specializing ClientConfig with different WindowHandlerHtml 
 leads to endless loop?
 
 
 
 
 
 
 Hi Heiko!
 
 Does this also happen on Firefox or only on IE? And if so, which IE 
 version exactly?
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
  From: it-media.k...@daimler.com 
 it-media.k...@daimler.com
  To: users@myfaces.apache.org
  Cc: 
  Sent: Friday, February 1, 2013 8:20 AM
  Subject: EXTCDI - Specializing ClientConfig with different 
 WindowHandlerHtml leads to endless loop?
 
  Hello everone,
 
  I've tried to change the Nag-Screen of the Client Side 
 Window 
  Handler of 
  EXTCDI by specializing ClientConfig in the following way:
 
  @SessionScoped
  @Specializes
  public class MaksClientConfig extends ClientConfig implements 
 Serializable
  {
      /** ID necessary for serialization */
      private static final long serialVersionUID = -3974881285407719139L;
 
      private static final String MAKS_WINDOW_HANDLER_HTML_FILE = 
  insecure/windowhandler.html;
 
      @Override
      public String getWindowHandlerResourceLocation()
      {
          return MAKS_WINDOW_HANDLER_HTML_FILE;
      }
  }
 
  The file insecure/windowhandler.html is a simple COPY of the 
  original 
  file delivered with EXTCDI 1.0.6-SNAPSHOT. When I do so, this ends up in 
 
  an endless loop in Internet Explorer. The parameter 'windowId' 
 always 
  stays automatedEntryPoint. 
 
  The cookie is once set to something like 
  7742-codiWindowId=automatedEntryPoint and on a second reload to another 
  number e.g. 8631-codiWindowId=automatedEntryPoint, but it cycles here 
 and 
  does not continue.
 
  What do I miss here? 
 
  Thanks,
 
  Best regards,
 
  Heiko
 
  --
  Heiko Kopp / Fa. Vision iT media GmbH
 
  Programming today is a race between software engineers striving to build 
 
  bigger and better idiot-proof programs, and the universe trying to build 
 
  bigger and better idiots. So far, the universe is winning. 
 
  If you are not the intended addressee, please inform us immediately that 
 you 
  have received this e-mail in error, and delete it. We thank you for your 
 
  cooperation.  
 
 
 
 
 If you are not the intended addressee, please inform us immediately that you 
 have received this e-mail in error, and delete it. We thank you for your 
 cooperation.  

[DISCUSS] new CODI release?

[Mark Struberg]

Hi folks!

I'm tempted to release a new version of CODI. There are a few bugs in the chain 
which would be nice to ship.
If there is no objection, then I'd start with the release task sunday-ish...


txs and LieGrue,
strub

Re: security with JSF app

[Mark Struberg]

Hi Jim!

You could use JAAS and users.xml in tomcat, but I personally would not 
recommend it as all the classic EE based security is (imo) way too complicated 
to handle for what it provides.


You can look at CODI @Secured with an own security Voter [1][2], which is very 
easy to implement against any existing security solution. There will be a 
similar solution for DeltaSpike in the future.

LieGrue,
strub

[1] https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage
[2] 
https://github.com/struberg/lightweightEE/blob/master/gui/src/main/java/de/jaxenter/eesummit/caroline/gui/security/AdminAccessVoter.java


- Original Message -
 From: Jim May jim.webg...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Saturday, January 26, 2013 4:09 AM
 Subject: security with JSF app
 
 Hello,
 
 Sorry for the ignorant questions. I am used to Glassfish and recently moved
 over to Tomcat.
 
 I am trying to setup programmatic security with a JSF app and Tomcat 7. I
 am using a JSF managed bean utilizing the request object's login method to
 login against the security realm. I know that there are different
 configurations for the realms in the JSF apps web.xml. I am choosing FORM
 based authentication and not configuring a login or error page. Since the
 login and logout is being handled by code.
 
 How do I tie a realm name in the web.xml to the realm name in Tomcat's
 server.xml? Do I tie the web.xml realm name to the dataSourceName attribute
 in the Realm entity in server.xml config?
 
 This application is going through a redesign and conversion to JSF, so it
 has a legacy database without encrypted passwords. Ya! I know. Bad!
 Unfortunately, I have inherited this yummy stuff. I plan on changing it
 later to encrypted passwords. Will the JDBC realm work with passwords in
 plain text in the database column or is it going to force an MD5 check? I
 would like to get the redesigned web files up and running while having to
 perform very little modifications to the database.
 
 Thanks,
 
 -- 
 James May
 Software Lead Engineer / Architect
 Java, PHP, .Net, Leader, Mentor
 http://www.jamesmay.me
 

Re: [CODI] Does CODI supports to be deployed in a app server that uses multi-classloader for EARs (was: CODI jar in ear/lib with a WAR = fail in WebSphere v8.5)

[Mark Struberg]

 Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think 
 TomEE 
 uses a single classloader...

Yes, I use it that way. Well, we are not actually using a full EAR but a Tomcat 
with catalina.sharedLoader set to webapps/lib. This means each WAR gets an own 
WebAppClassloader and they share a common ClassLoader. CODI works perfectly 
well in this case.
The only thing you need to make sure is that all the classes needed by CODI are 
also available in the shared ClassLoader. 


E.g. if you move codi-jsf to the shared classpath, then you also need the 
javax.faces classes accessible from there. Of course, you could also keep 
codi-core in the shared loader and move JSF related parts to each webapp.

Both work perfectly fine. In our app we share a few commonly used dialogues and 
JSF resources, thus we also have MyFaces-core available in the shared loader.


LieGrue,
strub




- Original Message -
 From: titou10 titou10.tito...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, January 18, 2013 12:26 PM
 Subject: [CODI]  Does CODI supports to be deployed in a app server that uses 
 multi-classloader for EARs (was: CODI jar in ear/lib with a WAR = fail in 
 WebSphere v8.5)
 
 
 Danke schoen Thomas, you answered my question.
 
 The key thing here for you is using deployment_xml_classloader_policy: 
 single classloader ( WAR classloader policy 
 =application) which is not supported by IBM.
 
 This is what we were using, this was the only way we found to have our apps 
 working with CODI, PARENT_FIRSTx2 is ok for us as our 
 app is less complex (another way is to pack everything in WAR/WEB-INF/lib, 
 codi 
 and other dependents jar and the project EJB jars)
 .
 This...until I opened a PMR by IBM (PM80276 CreationalContext Not Created 
 for Custom Scope Stateful EJB that will be included in 
 WAS v8.5.0.2)  and sent them a very simple ear file demonstrating that CDI 
 custom scoped used in  and EJB caused troubled, so the PMR.
 
 The IBM guy from level 3 support (=lab) gave us a iFix and wrote (quoting 
 him) :
 Also of note to the customer: They need to DISABLE the single class 
 loading for application option, which they have set for thier 
 application, as this is not supported by WebSphere's CDI implementation. If 
 the do not disable the single class loading option then 
 their app may appear to be working correctly, but unexpected problems may 
 occur. 
 
 
 And he pointed me to the WAS v8.5 infocenter link
 
 So I come back to my original question, does CODI support to be deployed in 
 an 
 ear with multi-level classloader?
 Does anyone use CODI in such a way? in Glassfish or JBoss maybe? I think 
 TomEE 
 uses a single classloader...
 
 It is not a classpath problem, but a multi-classloader problem. CODI does not 
 seem to handle this well... Maybe the way ClassUtils 
 loads classes or the PhaseListenerExtension class that handle the JSF 
 lifecycle 
 artefacts (leading to the NPE as decribed before) 
 have some bugs?
 I tried to debug it without success.
 
 (I changed the title of the post to reflect the question)
 
 Le 2013-01-18 03:06, Thomas Herzog a écrit :
 
  Here I sent you our config:
 
  1.application_xml_initilaize_in_order: we faced the iisue that codi wont 
 start properly when the wars are not initialized in order.
 
  2.application_xml_war_order: we ha to initiliaze the new war first because 
 it uses codi, jsf, cdi and so on.
 
  3.deployment_xml_classloader_policy: single classloader, new war 
 PARENT_LAST, rest PARENT_FIRST
 
  4.ear_lib: contains all of our for all projects accessible used util jars.
 
  5.new_war_web_inf_lib: contains all jars only the new war needs access to.
 
  6.websphere_ear_classloader_deployed: See the classloader of the ear on 
 websphere when its deployed.
 
  We needed some time to get codi running because of classloading issues and 
 startup of codi.
 
  Hopefully this will help you J
 
  Mit freundlichen Grüßen
 
  Thomas Herzog
 
  Softwareentwicklung
 
  curecomp Software Services GmbH
 
  Hafenstrasse 47-51
 
  4020 Linz
 
  web: www.curecomp.com
 
  e-Mail: t.her...@curecomp.com
 
  tel: +43 (0)732 9015-5563
 
  mobile: +43 (0)664 8867 9829
 
  -Ursprüngliche Nachricht-
  Von: titou10 titou10 [mailto:titou10.tito...@gmail.com]
  Gesendet: Donnerstag, 17. Jänner 2013 22:51
  An: MyFaces Discussion
  Betreff: Re: Re: [CODI] CODI jar in ear/lib with a WAR = fail in WebSphere 
 v8.5
 
  I was copied  in my previous mail...
 
  Avoid trouble: CDI is only supported with the default WebSphere 
 Application Server class loader policy, Class loader for each WAR 
  file in application, and not with the alternative, single class loader for 
 application setting.
 
 
 http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Fae%2Fcweb_cdi.html
 
  2013/1/17 Thomas Herzog t.her...@curecomp.com 
 mailto:t.her...@curecomp.com:
 
  
 
   I have read the doc in 

Re: CODI: Exclude windowId from certain pages

[Mark Struberg]

Well, then the problem is not the number of windows but the number of sessions 
;)

In pure tomcat you can either restrict that or 'offload' them via a 
configuration. There are SessionManagers which keep n Sessions in memory and if 
this number gets exceeded the LRU ones will get persisted to the file system. 
That way it's almost impossible to trash the Sessions in pure tomcat. 

I have no clue what GlassFish does to prevent this scenario, but this is for 
sure not a MyFaces, nor a CDI, nor a CODI problem ;)

LieGrue,
strub






 From: Andreas Kaiser kaiser.andr...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org 
Sent: Friday, November 30, 2012 10:24 AM
Subject: Re: CODI: Exclude windowId from certain pages
 
Hi

thanks for all answers. I will try to reduce the number of windows per
session.

Also i will try to change my stress test script to be a bit more gently to
my server ( clean login and logout )

BTW. the number of ids is not 500*64 its NumberOfThreadsInJMeter *
LoopCount

in my case 500 * 200 = 10 ( * bytesPerHashMapEntry )

The windows per session limitation will not work in this scenario because
each request gets a new session

Regards


On Fri, Nov 30, 2012 at 8:26 AM, Leonardo Uribe lu4...@gmail.com wrote:

 Anyway, you can only solve the question trying to reduce the param and see
 what happens. 500*64 is a big number.
 On Nov 30, 2012 2:20 AM, Mark Struberg strub...@yahoo.de wrote:

  No Leo, cannot be a problem!
 
  As Gerhard already explained we only keep a configurable number of
  'windows' per Session. Once this limit is exceeded the LRU one will get
  destroyed. It's really a non-issue. The problem Andreas faces must be
  another one. Or it's a bug, but this is really well tested imo.
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Leonardo Uribe lu4...@gmail.com
   To: MyFaces Discussion users@myfaces.apache.org
   Cc:
   Sent: Friday, November 30, 2012 5:47 AM
   Subject: Re: CODI: Exclude windowId from certain pages
  
   Hi
  
   Are you invalidating the session (logout) in some point? Maybe that
  could be
   related to the problem, because if you keep the session active and
 create
   hundreds of different windows, since the session is not released that
  memory
   will not be restored and the stress testing will not be accurate (or
  realistic).
  
   regards,
  
   Leonardo Uribe
  
   2012/11/29 Gerhard Petracek gerhard.petra...@gmail.com:
    hi andreas,
  
    please have a look at WindowContextConfig - see e.g.
    #isUnknownWindowIdsAllowed and #getMaxWindowContextCount
    - it shouldn't be an issue (since you can customize the default
   behaviour).
  
    btw:
    we are doing a lot of such tests (without
  windowId=automatedEntryPoint) and
    never saw an issue - but we don't use glassfish ;)
  
    regards,
    gerhard
  
    http://www.irian.at
  
    Your JSF/JavaEE powerhouse -
    JavaEE Consulting, Development and
    Courses in English and German
  
    Professional Support for Apache MyFaces
  
  
  
    2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
  
    Hi
    thanks for the answer
  
    I will have a look at this.
    BTW. it seems that the the windowId is a potential security issue.
  
    For instance call a side with an unknown windowId. CODI will
 generate
  a
   new
    valid one. Just change the generated one to a new invalid id. CODI
  will
    generate a new one again. Repeat this until you are out of ids or
 the
    server is out of memory ;-)
  
    This is whats happend in my application due to stress testing
  
    Regards
  
  
    On Thu, Nov 29, 2012 at 11:03 PM, Gerhard Petracek 
    gerhard.petra...@gmail.com wrote:
  
     hi andreas,
    
     first of all: welcome @ myfaces!
    
     there are different approaches - e.g. you can use urls with
       windowId=automatedEntryPoint
     (see the javadoc in WindowContextManager)
    
     regards,
     gerhard
    
     http://www.irian.at
    
     Your JSF/JavaEE powerhouse -
     JavaEE Consulting, Development and
     Courses in English and German
    
     Professional Support for Apache MyFaces
    
    
    
     2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
    
      Hi everybody
     
      I have following setup :
     
      Glassfish 3.1.2.2
      Weld
      Java EE6 + JSF + CDI + JPA
      CODI: 1.0.5
     
      My problem:
     
      We use and like the windowId Feature from CODI. But it causes
   some big
      problems on some pages which are specially created for stress
   testing.
     
      These pages are accessed from 500+ clients generated from
   JMeter.
      Every client acts as a own browser.
     
      This pages (RequestScoped) can be accessed without login.
   Therefore
    CODI
      generates a new windowId for every client.
     
      The problem is that the JMeter tests run multiple times. Due
   to this
    the
      Hashmap in JSFWindowContext.java consums a lot

Re: CODI: Exclude windowId from certain pages

[Mark Struberg]

No Leo, cannot be a problem!

As Gerhard already explained we only keep a configurable number of 'windows' 
per Session. Once this limit is exceeded the LRU one will get destroyed. It's 
really a non-issue. The problem Andreas faces must be another one. Or it's a 
bug, but this is really well tested imo.

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, November 30, 2012 5:47 AM
 Subject: Re: CODI: Exclude windowId from certain pages
 
 Hi
 
 Are you invalidating the session (logout) in some point? Maybe that could be
 related to the problem, because if you keep the session active and create
 hundreds of different windows, since the session is not released that memory
 will not be restored and the stress testing will not be accurate (or 
 realistic).
 
 regards,
 
 Leonardo Uribe
 
 2012/11/29 Gerhard Petracek gerhard.petra...@gmail.com:
  hi andreas,
 
  please have a look at WindowContextConfig - see e.g.
  #isUnknownWindowIdsAllowed and #getMaxWindowContextCount
  - it shouldn't be an issue (since you can customize the default 
 behaviour).
 
  btw:
  we are doing a lot of such tests (without windowId=automatedEntryPoint) and
  never saw an issue - but we don't use glassfish ;)
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
 
  Hi
  thanks for the answer
 
  I will have a look at this.
  BTW. it seems that the the windowId is a potential security issue.
 
  For instance call a side with an unknown windowId. CODI will generate a 
 new
  valid one. Just change the generated one to a new invalid id. CODI will
  generate a new one again. Repeat this until you are out of ids or the
  server is out of memory ;-)
 
  This is whats happend in my application due to stress testing
 
  Regards
 
 
  On Thu, Nov 29, 2012 at 11:03 PM, Gerhard Petracek 
  gerhard.petra...@gmail.com wrote:
 
   hi andreas,
  
   first of all: welcome @ myfaces!
  
   there are different approaches - e.g. you can use urls with
     windowId=automatedEntryPoint
   (see the javadoc in WindowContextManager)
  
   regards,
   gerhard
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
   2012/11/29 Andreas Kaiser kaiser.andr...@gmail.com
  
Hi everybody
   
I have following setup :
   
Glassfish 3.1.2.2
Weld
Java EE6 + JSF + CDI + JPA
CODI: 1.0.5
   
My problem:
   
We use and like the windowId Feature from CODI. But it causes 
 some big
problems on some pages which are specially created for stress 
 testing.
   
These pages are accessed from 500+ clients generated from 
 JMeter.
Every client acts as a own browser.
   
This pages (RequestScoped) can be accessed without login. 
 Therefore
  CODI
generates a new windowId for every client.
   
The problem is that the JMeter tests run multiple times. Due 
 to this
  the
Hashmap in JSFWindowContext.java consums a lot of memory 
 until the
Glassfish has no space left which leads into a 100 % CPU 
 usage because
   the
garbage collector tries to free a even the last few bytes.
   
My question is
1. Is it possible to create windowIds only a user is logged 
 in
2. Is there an option to change the default behavior
3. Can i exclude some pages being handled by the codi 
 JSFWindowManager
   
   
   
   
Regards
   
  
 

Re: Migration to TomEE/CODI: very strange AJAX issue during regression testing

[Mark Struberg]

+1

Howard, as most other stuff is now working, we can continue with getting back 
JUEL in place. But please file a tomcat issue for the EL stuff first!

For TomEE it's as easy as for tomcat7. A long time ago I wrote up a description 
in our wiki [1] which is basically still true. 
There is also some info on the juel page [2].



[1] http://wiki.apache.org/myfaces/HowToEnableEl22
[2] http://juel.sourceforge.net/guide/service.html


- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, November 22, 2012 9:48 AM
 Subject: Re: Migration to TomEE/CODI: very strange AJAX issue during 
 regression testing
 
 If there is an EL struggling problem then this is probably a tomcat 
 issue. Tomcat is providing the EL in tomee to my knowledge.
 
 
 Werner
 
 
 Am 22.11.12 00:07, schrieb Howard W. Smith, Jr.:
  I think I just solved this issue as follows:
 
  *CAUSED BY:* p:calendar 
 *readonlyInput=#{pf_usersController.loggedInViaIpad
  == 'Y' ? 'true' : 'false'}*
 
 
      1. Glassfish 3.1.2.2 and MyFaces Core 2.1.9 handles that perfectly
      2. OpenWebBeans and MyFaces Core 2.1.9 seem to struggle with that EL 
 for
      whatever reason
      3. So, I made it easy on OpenWebBeans and moved that EL to
      rendered=..., and conditionally render separate components 
 with a
      readonlyInput=true only for iPad device/endusers
 
  *CODE CHANGES* below:
 
 
  h:outputText value=From: /
  p:calendar id=filterTripDateFrom
       value=#{pf_ordersController.filterTripDateFrom}
       mode=popup showOn=button
       navigator=true effect=fadeIn
       pattern=MM/dd/ size=10
       rendered=#{pf_usersController.loggedInViaIpad == 
 'N'}
       p:ajax partialSubmit=false
       event=dateSelect
  listener=#{pf_ordersController.filterTripDateFromSelected}
       update=:ordersBrowseForm:ordersDataTable
  :ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
  /p:calendar
  p:calendar id=filterTripDateFromOnIpad
       value=#{pf_ordersController.filterTripDateFrom}
       mode=popup showOn=button 
 readonlyInput=true
       navigator=true effect=fadeIn
       pattern=MM/dd/ size=10
       rendered=#{pf_usersController.loggedInViaIpad == 
 'Y'}
       p:ajax partialSubmit=false
       event=dateSelect
  listener=#{pf_ordersController.filterTripDateFromSelected}
       update=:ordersBrowseForm:ordersDataTable
  :ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
  /p:calendar
  h:outputText value=To: /
  p:calendar id=filterTripDateTo
  value=#{pf_ordersController.filterTripDateTo}
       mode=popup showOn=button
       navigator=true effect=fadeIn 
 pattern=MM/dd/ size=10
       rendered=#{pf_usersController.loggedInViaIpad == 
 'N'}
       p:ajax partialSubmit=false
       event=dateSelect
  listener=#{pf_ordersController.filterTripDateToSelected}
       update=:ordersBrowseForm:ordersDataTable
  :ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
  /p:calendar
  p:calendar id=filterTripDateToOnIpad
  value=#{pf_ordersController.filterTripDateTo}
       mode=popup showOn=button 
 readonlyInput=true
       navigator=true effect=fadeIn 
 pattern=MM/dd/ size=10
       rendered=#{pf_usersController.loggedInViaIpad == 
 'Y'}
       p:ajax partialSubmit=false
       event=dateSelect
  listener=#{pf_ordersController.filterTripDateToSelected}
       update=:ordersBrowseForm:ordersDataTable
  :ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status /
  /p:calendar
 
 
 
  On Wed, Nov 21, 2012 at 3:19 PM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  The following is the XHTML for the *FROM* and *TO* p:calendar 
 components
  in PrimeFaces p:dataTable component. Please note that the 
 *mode=popup
  showOn=button* is hardcoded in the xhtml below, and is not
  conditionally dependent on EL.
 
  As the screen captures will show, I am testing this via my
  test/development server, so please do not think I'm testing from 
 iPad
  (since there is EL for iPad devices below).
 
  This issue is not happening in the Production environment (Glassfish
  3.1.2.2 and MyFaces Core 2.1.9).
 
       p:calendar id=filterTripDateFrom
                   
 value=#{pf_ordersController.filterTripDateFrom}
                   mode=popup showOn=button
  readonlyInput=#{pf_usersController.loggedInViaIpad == 'Y' 
 ? 'true' :
  'false'}
                   navigator=true effect=fadeIn
                   pattern=MM/dd/ size=10
           p:ajax partialSubmit=false
                   event=dateSelect
  listener=#{pf_ordersController.filterTripDateFromSelected}
                   update=:ordersBrowseForm:ordersDataTable
  :ordersBrowseForm:formMessages :ordersBrowseForm:_ajax_status 
 /
       /p:calendar
       h:outputText value=To: /
       p:calendar id=filterTripDateTo
  value=#{pf_ordersController.filterTripDateTo}
                   mode=popup showOn=button
  

Re: CODI BeanManagerProvider in @FacesConverter breaks PrimeFaces p:pickList p:ajax event=transfer

[Mark Struberg]

mail came through just  fine


LieGrue,
strub





 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Wednesday, November 21, 2012 7:07 AM
Subject: CODI BeanManagerProvider in @FacesConverter breaks PrimeFaces 
p:pickList p:ajax event=transfer
 
*Resending* this, because I attempted to send this earlier and got an email
response that said my email was undelivered to *burntmail.com*.

Mark,

Please read/see below.

Per your recommendation in an earlier/separate thread,

Please try

*BeanManagerProvider.getInstance().getContextualReference(Yourclass.class);

inside the converter if you need it.
If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI
scopes) then you only need to do this once as you only get a proxy anyway.

LieGrue,
strub*

I tried this, and this breaks PrimeFaces p:pickList p:ajax
event=transfer. See/click URL below for my numerous tests, test results,
and conclusion. :)

Issue 4908 http://code.google.com/p/primefaces/issues/detail?id=4908 in
PrimeFaces Issue Tracker

Is this considered as an Apache CODI defect/issue or a lesson learned?
Please confirm.

Thanks,
Howard

Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped

[Mark Struberg]

well, that should do :)

We are serving up to 40.000 users with now 5GB RAM. But mostly due to lots of 
caches in our app.
Oh and we have 16 webapps. Each user getting their own session in each webapp...

So really nothing to worry about.

LieGrue,
strub




- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, November 21, 2012 11:29 AM
 Subject: Re: Migration to TomEE/CDI complete, regression testing, 
 ViewAccessScoped
 
T he most users that will be using the app concurrently is 4 to 5 users (my
 family), and there are times that they are doing some 'heavy lifting'
 (database retrievals/updates, as well as PDF files generated in memory and
 printed/viewed/emailed/faxed, and occasional data push to Google Calendar
 via Google Calendar API). Next, planning to automatically insert data into
 database from public website's form results.  Hoping to expand the services
 of the 'app' to customers via the public website...one day.
 
 The (JSF/HTML5) web app is accessed in and out of the office on multiple
 platforms (laptops, iPad, multiple Android devices).
 
 
 On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:
 
  Can i ask you how much users serves your app?
  Currently our app takes only 20mb session size with 200 (or 100, can't
  remember exactly) concurrent users and we don't use that much
  View(Access)Scoped beans.
 
  2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
 
   Thomas,
  
   Well, for now, I opt to do/use CDI @RequestScoped, ASAP, since 
 production
   box/server is running Windows 2003 Server, where 4GB RAM is 
 max...shaking
   my head. I'm sure we will upgrade when necessary, but right now 
 that app
  is
   lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 2.1.9 and 
 JUEL
   2.2.5. :)
  
   Looking forward to the performance advantages/gains of OpenWebBeans. 
 :)
  
   Also, this Batoo JPA that you mentioned earlier, because
  EclipseLink/Derby
   and Google Calendar requests/updates are the only 2 bottlenecks in the
  app.
  
   Thanks,
   Howard
  
   On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
Howard, there is nothing against ViewScoped/ViewAccessScoped.
But many data in ViewScoped/ViewAccessScoped leads to high memory
  usage,
   so
it's better to use RequestScoped if possible.
   
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
   
 I'd like to take time to thank you all that helped me 
 migrate from
 Glassfish 3.1.2.2 and JSF Managed beans to TomEE and CDI 
 managed
   beans. I
 think the migration is complete. I am in regression testing
  phase/mode
now.
 :)

 Special shout out to Thomas Andraschko, as his inputs in 
 PrimeFaces
forums
 and blogs, lead/motivated me to migrate from Mojarra 2.1.7 
 to MyFaces
Core
 2.1.8 for fast (AJAX) rendering performance, and then he 
 even
   recommended
 MyFaces Core, OpenWebBeans, JUEL for huge performance gains, 
 and even
 today, he encouraged me to consider Batoo JPA, and because 
 of that,
 TomEE/OpenEJB and Batoo JPA are now discussing integration! 
 :)

 Anyway, Jose, here, recommended CODI @ViewAccessScoped. I 
 think
  Thomas
and
 some other expert users in PrimeFaces Core forum recommended
@RequestScoped
 as much as possible throughout app, and recommended against 
 JSF
@ViewScoped
 as well as CODI @ViewAccessScoped (I hope I'm not 
 misquoting
them...smile).

 Honestly, I have no CDI @RequestScoped beans in my app; I 
 need to
  take
time
 to move some of my code from CDI @SessionScoped to CDI
  @RequestScoped.
 Also, due to issues I experienced injecting EJBs inside of
@FacesConverter
 (which were added to CDI @SessionScoped beans) caused me to 
 move all
  my
 @FacesConverter classes to JSF @RequestScoped beans; that 
 seems to be
 working great, but Mark and Gerhard has already recommended 
 CODI
 @Advanced/etc... to inject beans in @FacesConverter classes. 
 I need
  to
give
 them a try even though I spent hours moving @FacesConverter 
 classes
   from
 CDI beans to JSF Managed beans...during this migration to 
 CDI.

 So, please advise on whether I should use @ViewAccessScoped; 
 pros,
   cons,
 promote/hinder performance, etc...

 OR, should I move to CDI @RequestScoped, ASAP??? :)

 Oh, Romain informed me that tomee.xml JDBC resources 
 automatically
  have
 pooling. I hope that is the case, because as soon as 
 regression
  testing
is
 complete, I would like to push the new CDI version of my JSF 
 web app
  to
 production, and start using some of the other/neat features 
 of CDI,
   like
 CDI events where possible. :)

 Thanks,
 Howard

   
  
 

Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped

[Mark Struberg]

@SessionScoped has the downside that you cannot open multiple browser tabs with 
different data. Think about having a list of Cars and then opening 2 different 
car-edit dialoges in new browser tabs. That would not work using @SessionScoped 
and is the reason why we invented @WindowScoped and consorts.

LieGrue,
strub




- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, November 21, 2012 11:55 AM
 Subject: Re: Migration to TomEE/CDI complete, regression testing, 
 ViewAccessScoped
 
T hanks Gerhard, will take a look.
 
 Honestly, @SessionScoped fits the current design of my app the best, only
 because I'm always returning null or void from bean to JSF
 commandButton/Link actionListener=..., and also, I have index.xhtml 
 which
 is parent to all ui:include src=#{bean.page}.
 
 Honestly, I have not seen any memory issues at all in production, and I'm
 monitoring server log on Production, looking for nullpointerexceptions
 here/there, so I can resolve any/every 'exception' occuring in 
 production,
 even if endusers don't see or 'report' the exception(s) to me. :)
 
 Usually I'm updating the JSF web app software almost daily, but because of
 this migration to TomEE/CDI, my focus has been there, and the server has
 been running well without restart/etc...
 
 
 On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:
 
  hi howard,
 
  you can have a look at [1] (e.g. slide #9)
  the mentioned public application is using codi scopes like
  @ViewAccessScoped without any performance and/or memory issue.
 
  regards,
  gerhard
 
  [1]
  http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
 
   The most users that will be using the app concurrently is 4 to 5 users
  (my
   family), and there are times that they are doing some 'heavy 
 lifting'
   (database retrievals/updates, as well as PDF files generated in memory
  and
   printed/viewed/emailed/faxed, and occasional data push to Google 
 Calendar
   via Google Calendar API). Next, planning to automatically insert data
  into
   database from public website's form results.  Hoping to expand the
  services
   of the 'app' to customers via the public website...one day.
  
   The (JSF/HTML5) web app is accessed in and out of the office on 
 multiple
   platforms (laptops, iPad, multiple Android devices).
  
  
   On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
Can i ask you how much users serves your app?
Currently our app takes only 20mb session size with 200 (or 100, 
 can't
remember exactly) concurrent users and we don't use that much
View(Access)Scoped beans.
   
2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
   
 Thomas,

 Well, for now, I opt to do/use CDI @RequestScoped, ASAP, 
 since
   production
 box/server is running Windows 2003 Server, where 4GB RAM is
   max...shaking
 my head. I'm sure we will upgrade when necessary, but 
 right now that
   app
is
 lighting fast now with Glassfish 3.1.2.2 and MyFaces Core 
 2.1.9 and
   JUEL
 2.2.5. :)

 Looking forward to the performance advantages/gains of 
 OpenWebBeans.
  :)

 Also, this Batoo JPA that you mentioned earlier, because
EclipseLink/Derby
 and Google Calendar requests/updates are the only 2 
 bottlenecks in
  the
app.

 Thanks,
 Howard

 On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko 
 andraschko.tho...@gmail.com wrote:

  Howard, there is nothing against 
 ViewScoped/ViewAccessScoped.
  But many data in ViewScoped/ViewAccessScoped leads to 
 high memory
usage,
 so
  it's better to use RequestScoped if possible.
 
  2012/11/21 Howard W. Smith, Jr. 
 smithh032...@gmail.com
 
   I'd like to take time to thank you all that 
 helped me migrate
  from
   Glassfish 3.1.2.2 and JSF Managed beans to TomEE 
 and CDI managed
 beans. I
   think the migration is complete. I am in 
 regression testing
phase/mode
  now.
   :)
  
   Special shout out to Thomas Andraschko, as his 
 inputs in
  PrimeFaces
  forums
   and blogs, lead/motivated me to migrate from 
 Mojarra 2.1.7 to
   MyFaces
  Core
   2.1.8 for fast (AJAX) rendering performance, and 
 then he even
 recommended
   MyFaces Core, OpenWebBeans, JUEL for huge 
 performance gains, and
   even
   today, he encouraged me to consider Batoo JPA, and 
 because of
  that,
   TomEE/OpenEJB and Batoo JPA are now discussing 
 integration! :)
  
   Anyway, Jose, here, recommended CODI 
 @ViewAccessScoped. I think

Re: Migration to TomEE/CDI complete, regression testing, ViewAccessScoped

[Mark Struberg]

please move this question to the openejb list as this might be a TomEE issue.

LieGrue,
strub






 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Wednesday, November 21, 2012 12:21 PM
Subject: Re: Migration to TomEE/CDI complete, regression testing, 
ViewAccessScoped
 

Can you all tell me why @PreDestroy method on CDI @ApplicationScoped is not 
being invoked when app is undeployed? @PreDestroy on JSF @ApplicationScoped 
Managed bean was invoked when app was undeployed (or app server was shutdown).



On Wed, Nov 21, 2012 at 6:16 AM, Howard W. Smith, Jr. smithh032...@gmail.com 
wrote:

Interesting and thanks for letting me know. I thought I read somewhere that 
CDI (or 'OpenWebBeans') has this ability that you're talking about, but when I 
read about it earlier, i didn't see it referred as @WindowScoped.


Good to know, but the endusers have been trained to 'only' use Google Chrome, 
and no need of opening multiple browser tabs/windows.





On Wed, Nov 21, 2012 at 6:12 AM, Mark Struberg strub...@yahoo.de wrote:

@SessionScoped has the downside that you cannot open multiple browser tabs 
with different data. Think about having a list of Cars and then opening 2 
different car-edit dialoges in new browser tabs. That would not work using 
@SessionScoped and is the reason why we invented @WindowScoped and consorts.


LieGrue,
strub




- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc:

 Sent: Wednesday, November 21, 2012 11:55 AM
 Subject: Re: Migration to TomEE/CDI complete, regression testing, 
 ViewAccessScoped

T hanks Gerhard, will take a look.


 Honestly, @SessionScoped fits the current design of my app the best, only
 because I'm always returning null or void from bean to JSF
 commandButton/Link actionListener=..., and also, I have index.xhtml
 which
 is parent to all ui:include src=#{bean.page}.

 Honestly, I have not seen any memory issues at all in production, and I'm
 monitoring server log on Production, looking for nullpointerexceptions
 here/there, so I can resolve any/every 'exception' occuring in
 production,
 even if endusers don't see or 'report' the exception(s) to me. :)

 Usually I'm updating the JSF web app software almost daily, but because of
 this migration to TomEE/CDI, my focus has been there, and the server has
 been running well without restart/etc...


 On Wed, Nov 21, 2012 at 5:43 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:

  hi howard,

  you can have a look at [1] (e.g. slide #9)
  the mentioned public application is using codi scopes like
  @ViewAccessScoped without any performance and/or memory issue.

  regards,
  gerhard

  [1]
  http://os890.blogspot.co.at/2012/11/slides-apache-myfaces-universe.html

  http://www.irian.at

  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German

  Professional Support for Apache MyFaces



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

   The most users that will be using the app concurrently is 4 to 5 users
  (my
   family), and there are times that they are doing some 'heavy
 lifting'
   (database retrievals/updates, as well as PDF files generated in memory
  and
   printed/viewed/emailed/faxed, and occasional data push to Google
 Calendar
   via Google Calendar API). Next, planning to automatically insert data
  into
   database from public website's form results.  Hoping to expand the
  services
   of the 'app' to customers via the public website...one day.
  
   The (JSF/HTML5) web app is accessed in and out of the office on
 multiple
   platforms (laptops, iPad, multiple Android devices).
  
  
   On Wed, Nov 21, 2012 at 5:20 AM, Thomas Andraschko 
   andraschko.tho...@gmail.com wrote:
  
    Can i ask you how much users serves your app?
    Currently our app takes only 20mb session size with 200 (or 100,
 can't
    remember exactly) concurrent users and we don't use that much
    View(Access)Scoped beans.
   
    2012/11/21 Howard W. Smith, Jr. smithh032...@gmail.com
   
     Thomas,
    
     Well, for now, I opt to do/use CDI @RequestScoped, ASAP,
 since
   production
     box/server is running Windows 2003 Server, where 4GB RAM is
   max...shaking
     my head. I'm sure we will upgrade when necessary, but
 right now that
   app
    is
     lighting fast now with Glassfish 3.1.2.2 and MyFaces Core
 2.1.9 and
   JUEL
     2.2.5. :)
    
     Looking forward to the performance advantages/gains of
 OpenWebBeans.
  :)
    
     Also, this Batoo JPA that you mentioned earlier, because
    EclipseLink/Derby
     and Google Calendar requests/updates are the only 2
 bottlenecks in
  the
    app.
    
     Thanks,
     Howard
    
     On Wed, Nov 21, 2012 at 4:47 AM, Thomas Andraschko 
     andraschko.tho...@gmail.com wrote:
    
  Howard, there is nothing

Re: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI

[Mark Struberg]

Hi Howard!

CODI is a portable CDI _Extension_ and not a CDI container!

CODI runs on Weld, OpenWebBeans, resin, Glassfish, TomEE, JBossAS, etc

LieGrue,
strub



- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, November 21, 2012 9:51 PM
 Subject: TomEE/OpenEJB (OpenWebBeans) with Apache MyFaces CODI
 
 Is it really necessary or encouraged to use Apache MyFaces CODI with TomEE
 1.5 (SNAPSHOT)? Any pros/cons, advantages/disadvantages using them both
 together?
 
 TomEE bundles MyFaces Core 2.1.9 and OpenEJB, but Apache MyFaces CODI is
 'not' bundled with TomEE, for some reason or another.
 
 I've seen blogs encourage JSF developers to 'at least' use latest 
 MyFaces
 Core version and OpenWebBeans for performance reasons, but I don't think I
 saw encouragement to use Apache MyFaces CODI.
 
 
 Thanks,
 Howard
 

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

[Mark Struberg]

you could also have used CODI BeanManagerProvider#getReference to get access to 
the bean.

The support you need out of the box will come in JSF-2.2.


LieGrue,
strub



- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, November 20, 2012 1:56 PM
 Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via 
 facescontext
 
T he goal was to inject bean in facesconverter via CDI, but I don't have
 this need anymore, since faces converter is not an eligible injection
 point, so I opted to use request scoped JSF managed beans that have
 facesconverter defined within the bean. That's working fine. Thanks.
 
 Okay, I can cc myfaces user group as well, going forward. :-)
 On Nov 20, 2012 7:37 AM, Romain Manni-Bucau 
 rmannibu...@gmail.com
 wrote:
 
  i'm still not clear about your goal and where you need injection
 
  maybe share a (runnable) sample to show us what you are talking about
 
  side note: myfaces list can help you a lot about it too
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
 
  2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
 
   Interesting, that will allow you to get instance of beans, if already
   instantiated, and that could have helped in converter, only if beans
   already injected earlier?
   On Nov 20, 2012 7:11 AM, Romain Manni-Bucau 
 rmannibu...@gmail.com
   wrote:
  
was thinking to
   
  
  http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html
getAttributes()
method (depend a bit on your real need)
   
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
   
   
   
   
2012/11/20 Howard W. Smith, Jr. smithh032...@gmail.com
   
 Faces context? Please explain.
  On Nov 20, 2012 1:56 AM, Romain Manni-Bucau 
 
  rmannibu...@gmail.com
 wrote:

  You cant use faces context?
  Le 20 nov. 2012 03:01, Howard W. Smith, Jr. 
 
   smithh032...@gmail.com
a
  écrit :
 
   For minimal changes, I'm adding FacesConverter 
 to JSF
  requestscoped
   managedBean's as per the Stackoverflow answer 
 below:
  
   How can I inject in @FacesConverter?
   http://stackoverflow.com/a/13156834/933054
  
   Yes, this means more classes in the project, but 
 honestly, I have
   not
 had
   to spend much time 'maintaining' my 
 Converter classes at all. I
   just
  tested
   this concept, and I'm not experiencing this 
 exceptioin any more.
  
   While testing the above, I see more exceptions to 
 resolve related
   to
   migrating to CDI. Will let you all know, if I have 
 any more
questions.
  
   Thanks for all the responses/help, so far. :)
  
  
  
   On Mon, Nov 19, 2012 at 7:20 PM, Romain 
 Manni-Bucau
   rmannibu...@gmail.comwrote:
  
If it is a nested class you need it otherwise 
 (class foo in
foo.java
   file)
you dont need it
Le 20 nov. 2012 01:16, Howard W. Smith, 
 Jr. 
 smithh032...@gmail.com
  a
écrit :
   
 Good question. I removed 
 'static', because I didn't see it in
   the
  code
   at
 following URLs:



   
  
 

   
  
 
 https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-DependencyInjection



   
  
 

   
  
 
 http://stackoverflow.com/questions/7531449/cdi-injection-into-a-facesconverter

 
 https://issues.apache.org/jira/browse/EXTCDI-127


 On Mon, Nov 19, 2012 at 4:30 PM, Romain 
 Manni-Bucau
 rmannibu...@gmail.comwrote:

  Why removing static? It means it is 
 no more manageable by
  cdi
 (cdi
   cant
 do
  a new on it)
  Le 19 nov. 2012 22:13, Howard 
 W. Smith, Jr. 
   smithh032...@gmail.com
a
  écrit :
 
   @Advanced was found in the 
 following:
  
   import
  org.apache.myfaces.extensions.cdi.core.api.Advanced;
  
   After some tinkering, I 
 removed 'static' from the
  following
definition,
  
   public static class 
 AddressTypeControllerConverter
   implements
 Converter {
  
   I also added @Advanced to the 
 FacesConverter/Converter,
  and
  latest
 error
  is
   the following:
  
   Nov 19, 2012 4:08:21 PM
  

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

[Mark Struberg]

CDI injection using @Advanced should work perfectly fine. We tested this 
excessively and use it on several containers in production.

I'm curious why it doesn't work for you.

LieGrue,
strub


- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano 
 rmpest...@yahoo.com.br
 Cc: 
 Sent: Tuesday, November 20, 2012 3:13 PM
 Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via 
 facescontext
 
 Rafael,
 
 I saw that page about CODI @Advanced. :)
 
 I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject,
 and then I tried to inject Stateless EJB via @Inject, and that stateless
 EJB was not injected either.
 
 Thanks,
 Howard
 
 On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano 
 rmpest...@yahoo.com.brwrote:
 
  you can also use CODI @Advanced and then inject anything in the
  converter, see [1].
 
  i hope it helps.
 
  [1]:
  https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection
 
 
  Att,
 
  Rafael M. Pestano
 
  Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
  Graduando em Ciência da Computação UFRGS
  http://conventionsframework.org
 
  http://rpestano.wordpress.com/
  @realpestano
 
 
  
   De: Howard W. Smith, Jr. smithh032...@gmail.com
  Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion 
  users@myfaces.apache.org
  Cc: us...@openejb.apache.org us...@openejb.apache.org
  Enviadas: Terça-feira, 20 de Novembro de 2012 11:37
  Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via
  facescontext
 
  Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in
  facesconverter. Thanks.
  On Nov 20, 2012 8:34 AM, Mark Struberg 
 strub...@yahoo.de wrote:
 
   you could also have used CODI BeanManagerProvider#getReference to get
   access to the bean.
  
   The support you need out of the box will come in JSF-2.2.
  
  
   LieGrue,
   strub
  
  
  
   - Original Message -
From: Howard W. Smith, Jr. 
 smithh032...@gmail.com
To: us...@openejb.apache.org; MyFaces Discussion 
   users@myfaces.apache.org
Cc:
Sent: Tuesday, November 20, 2012 1:56 PM
Subject: Re: Migrating to CDI: injecting stateless/facade in 
 Converter
   via facescontext
   
   T he goal was to inject bean in facesconverter via CDI, but I 
 don't have
this need anymore, since faces converter is not an eligible 
 injection
point, so I opted to use request scoped JSF managed beans that 
 have
facesconverter defined within the bean. That's working fine. 
 Thanks.
   
Okay, I can cc myfaces user group as well, going forward. :-)
On Nov 20, 2012 7:37 AM, Romain Manni-Bucau
rmannibu...@gmail.com
wrote:
   
     i'm still not clear about your goal and where you need 
 injection
   
     maybe share a (runnable) sample to show us what you are 
 talking about
   
     side note: myfaces list can help you a lot about it too
   
     *Romain Manni-Bucau*
     *Twitter: @rmannibucau 
 https://twitter.com/rmannibucau*
     *Blog: **http://rmannibucau.wordpress.com/*
     http://rmannibucau.wordpress.com/
     *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
     *Github: https://github.com/rmannibucau*
   
   
   
   
     2012/11/20 Howard W. Smith, Jr. 
 smithh032...@gmail.com
   
      Interesting, that will allow you to get instance of 
 beans, if
  already
      instantiated, and that could have helped in converter, 
 only if
  beans
      already injected earlier?
      On Nov 20, 2012 7:11 AM, Romain Manni-Bucau
rmannibu...@gmail.com
      wrote:
     
       was thinking to
      
     
   
  
  http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html
       getAttributes()
       method (depend a bit on your real need)
      
       *Romain Manni-Bucau*
       *Twitter: @rmannibucau 
 https://twitter.com/rmannibucau*
       *Blog: **http://rmannibucau.wordpress.com/*
       http://rmannibucau.wordpress.com/
       *LinkedIn: 
 **http://fr.linkedin.com/in/rmannibucau*
       *Github: https://github.com/rmannibucau*
      
      
      
      
       2012/11/20 Howard W. Smith, Jr. 
 smithh032...@gmail.com
      
    Faces context? Please explain.
         On Nov 20, 2012 1:56 AM, Romain 
 Manni-Bucau

     rmannibu...@gmail.com
    wrote:
       
     You cant use faces context?
     Le 20 nov. 2012 03:01, Howard W. 
 Smith, Jr.

      smithh032...@gmail.com
       a
     écrit :
    
      For minimal changes, I'm adding 
 FacesConverter
to JSF
     requestscoped
      managedBean's as per the 
 Stackoverflow answer
below:
     
      How can I inject in 
 @FacesConverter?
      
 http://stackoverflow.com/a/13156834/933054
     
      Yes, this means more classes in the 
 project, but
honestly, I have
      not
    had
      to spend much time

Re: Migrating to CDI: @Asynchronous

[Mark Struberg]

Hi!

One of my first advice is to make sure that beans.xml is really there for the 
container.
I've seen this pretty often if someone starts the webapp directly from Eclipse. 
In that case the CDI container sometimes cannot find WEB-INF/beans.xml as 
eclipse doesn't set the classpath entries correctly. 

Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This 
will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from a 
spec perspective.

There's a 30% chance that this is your problem ;)

For the @Asynchronous:

In general I do not really like @Asynchronous in webapps. It's really very 
seldom useful as you need to wait for the result anyway. It also doesn't get 
any Session, Request or Transaction information propagated over and it's not 
guaranteed to succeed. Think about what happens if an Exception gets hit in the 
asynchronous bean? 

This is really only useful in 2 cases:
* fire and forget. If you don't take care if the job succeeds or not, then you 
might use it.

* spawning off multiple jobs and waiting for all of them before returning. 

Still you need to take a lot of care about error handling and similar stuff.


In our big application where we really need asynchronous tasks to be guaranteed 
to get executed we went the classic route which works on the Host since the 
60s: we just write the job into an own 'Tasks' table and process it via an own 
Quartz job. On success, it updates the status. On error it sets the task to a 
failure status and adds information about the cause. 
That way we have a failure safe and restartable implementation. 

LieGrue,
strub


- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: us...@openejb.apache.org; MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, November 20, 2012 3:06 PM
 Subject: Re: Migrating to CDI: @Asynchronous
 
 MyFaces Users,
 
 Please read OP (or my original email below), and then read this email, and
 advise.
 
 Romain,
 
 Yes, I have a code snippet; please continue reading beyond/below first code
 snippet.
 
 
 Below is the code that is called by multiple beans as well as the bean
 where this method is defined.
 
     /*
      * Is it safe to start a new thread in a JSF managed bean?
      * Look at answers by BalusC and David Blevins
      *
 http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
      *
      * Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation
 in Session Beans
      * http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
      */
     @Asynchronous
     public FutureDate updateGoogleCalendarPostEditAsync(Date
 tripDateToBePlacedInQueue) {
 
         String log;
 
         Date tripDate =
 usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
         if (tripDate == null) {
             return new AsyncResult(tripDate);
         }
 
         performingGoogleCalendarMaintenace = true;
 
         try {
 
             if (usersController.googleCalendarHasEvents()) {
                 usersController.deleteEvents(tripDate, tripDate);
             }
 
             String tripDateFrom = displayUtil.getDateFromDateTime(tripDate,
 false);
             String tripDateTo = displayUtil.getDateFromDateTime(tripDate,
 false);
 
             ListOrders list = getFacade().findAllConfirmed(tripDateFrom,
 tripDateTo, true);
 
             if (list != null) {
                 for (Orders o : list) {
 
 usersController.addEventToCalendar(newGoogleCalendarEvent(o));
                 }
             }
 
             log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
  +
                   new DateTime(tripDate).toString(MM/dd/) +
                    processed successfully;
         } catch (Exception e) {
             e.printStackTrace();
             messages.addFormErrorMsg(Error updating Google Calendar,
 (e.getMessage() != null) ? e.getMessage() : );
             log = pf_OrdersController.updateGoogleCalendarPostEditAsync():
  +
                   new DateTime(tripDate).toString(MM/dd/) +
                    processing failed due to exception;
         } finally {
             performingGoogleCalendarMaintenace = false;
         }
         System.out.println(log);
 
         // Return our result
         return new AsyncResult(tripDate);
     }
 
 Below, is code where the @Asynchronous method is *called within the same
 bean*, and is not the last piece of code in the calling method.
 
             /*
              * 1. if tripDate changed, then update Google Calendar for
 original trip date
              * 2. update Google Calendar for current trip date
              */
             if (new
 DateTime(current.getReportDateTime()).toString(MM/dd/).equals(
                  new 
 DateTime(tripDateBeforeEdit).toString(MM/dd/))
 == false) {
                 updateGoogleCalendarPostEditAsync(tripDateBeforeEdit);
             }
             

Re: Migrating to CDI: @Asynchronous

[Mark Struberg]

oh, if you are using OpenEJB/TomEE/ other EE server then you can also use 
@Timeout in an EJB instead of Quartz.

LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: MyFaces Discussion users@myfaces.apache.org; us...@openejb.apache.org 
 us...@openejb.apache.org
 Cc: 
 Sent: Tuesday, November 20, 2012 3:36 PM
 Subject: Re: Migrating to CDI: @Asynchronous
 
 Hi!
 
 One of my first advice is to make sure that beans.xml is really there for the 
 container.
 I've seen this pretty often if someone starts the webapp directly from 
 Eclipse. In that case the CDI container sometimes cannot find 
 WEB-INF/beans.xml 
 as eclipse doesn't set the classpath entries correctly. 
 
 Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This 
 will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from 
 a 
 spec perspective.
 
 There's a 30% chance that this is your problem ;)
 
 For the @Asynchronous:
 
 In general I do not really like @Asynchronous in webapps. It's really very 
 seldom useful as you need to wait for the result anyway. It also doesn't get 
 any Session, Request or Transaction information propagated over and it's not 
 guaranteed to succeed. Think about what happens if an Exception gets hit in 
 the 
 asynchronous bean? 
 
 This is really only useful in 2 cases:
 * fire and forget. If you don't take care if the job succeeds or not, then 
 you might use it.
 
 * spawning off multiple jobs and waiting for all of them before returning. 
 
 Still you need to take a lot of care about error handling and similar stuff.
 
 
 In our big application where we really need asynchronous tasks to be 
 guaranteed 
 to get executed we went the classic route which works on the Host since the 
 60s: 
 we just write the job into an own 'Tasks' table and process it via an 
 own Quartz job. On success, it updates the status. On error it sets the task 
 to 
 a failure status and adds information about the cause. 
 That way we have a failure safe and restartable implementation. 
 
 LieGrue,
 strub
 
 
 - Original Message -
  From: Howard W. Smith, Jr. smithh032...@gmail.com
  To: us...@openejb.apache.org; MyFaces Discussion 
 users@myfaces.apache.org
  Cc: 
  Sent: Tuesday, November 20, 2012 3:06 PM
  Subject: Re: Migrating to CDI: @Asynchronous
 
  MyFaces Users,
 
  Please read OP (or my original email below), and then read this email, and
  advise.
 
  Romain,
 
  Yes, I have a code snippet; please continue reading beyond/below first code
  snippet.
 
 
  Below is the code that is called by multiple beans as well as the bean
  where this method is defined.
 
      /*
       * Is it safe to start a new thread in a JSF managed bean?
       * Look at answers by BalusC and David Blevins
       *
 
 http://stackoverflow.com/questions/6149919/is-it-safe-to-start-a-new-thread-in-a-jsf-managed-bean
       *
       * Java EE 6 Tutorial Chapter 27 Using Asynchronous Method Invocation
  in Session Beans
       * http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
       */
      @Asynchronous
      public FutureDate updateGoogleCalendarPostEditAsync(Date
  tripDateToBePlacedInQueue) {
 
          String log;
 
          Date tripDate =
 
 usersController.queueDateAndOrUpdateGoogleCalendar(tripDateToBePlacedInQueue);
          if (tripDate == null) {
              return new AsyncResult(tripDate);
          }
 
          performingGoogleCalendarMaintenace = true;
 
          try {
 
              if (usersController.googleCalendarHasEvents()) {
                  usersController.deleteEvents(tripDate, tripDate);
              }
 
              String tripDateFrom = displayUtil.getDateFromDateTime(tripDate,
  false);
              String tripDateTo = displayUtil.getDateFromDateTime(tripDate,
  false);
 
              ListOrders list = 
 getFacade().findAllConfirmed(tripDateFrom,
  tripDateTo, true);
 
              if (list != null) {
                  for (Orders o : list) {
 
  usersController.addEventToCalendar(newGoogleCalendarEvent(o));
                  }
              }
 
              log = 
 pf_OrdersController.updateGoogleCalendarPostEditAsync():
   +
                    new DateTime(tripDate).toString(MM/dd/) +
                     processed successfully;
          } catch (Exception e) {
              e.printStackTrace();
              messages.addFormErrorMsg(Error updating Google 
 Calendar,
  (e.getMessage() != null) ? e.getMessage() : );
              log = 
 pf_OrdersController.updateGoogleCalendarPostEditAsync():
   +
                    new DateTime(tripDate).toString(MM/dd/) +
                     processing failed due to exception;
          } finally {
              performingGoogleCalendarMaintenace = false;
          }
          System.out.println(log);
 
          // Return our result
          return new AsyncResult(tripDate);
      }
 
  Below, is code where the @Asynchronous method is *called within the same
  bean

Re: Migrating to CDI: @Asynchronous

[Mark Struberg]

Dropping OpenEJB as we are now back to core JSF and related. I don't want to 
spam them ;)

1.): each container has pros and cons. And each of them needs different 
workarounds in edge cases :)


2.) I'm not using NetBeans, but it's basically the same scenario. In my project 
I opted for only using META-INF/beans.xml and completely dropping 
WEB-INF/beans.xml. This is perfectly fine as per the CDI spec [1].


What is a good example or use case for using CDI events?

Oh there are plenty! You just need to understand that CDI events != messages. 
CDI events are _always_ synchronous and only get delivered to beans in 
currently active contexts. 


E.g. if you fire a CDI event and have a public @SessionScoped class User then 
only the contextual instance 'User' from the current session will receive the 
event. 

You can think about CDI events as a method invocation where you do not know on 
which (and how many) instances you invoke it.


A practical use case. In our application we have a big fat menu. The menu 
content is depending on the language of the user and his privileges. Since this 
can change on a language change or if the user logs in/out, etc most apps 
always re-calculate the whole MenuItem tree from the database. 


What we did in our application is the following: Menu is a @SessionScoped cdi 
bean and we do NOT re-calculate the items for every request. Instead we fire a 
UserSettingsChangedEvent on each language change and login/logout. In the Menu 
bean (and a lot other places) we @Observes UserSettingsChangedEvent and reload 
the menu in that case. 


This performs vastly better and allows us to radically cache lots of things.



LieGrue,
strub

[1] https://issues.jboss.org/browse/CDI-218


 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Cc: us...@openejb.apache.org us...@openejb.apache.org 
Sent: Tuesday, November 20, 2012 3:56 PM
Subject: Re: Migrating to CDI: @Asynchronous
 

Mark,


Cool beans and agreed about @Asynchronous! Since I read about @Asynchronous on 
Stackoverflow.com (a post by David Blevins), I decided to give it a try, but I 
think I did read that 'asynchronous' (runnable, etc...) tasks are not all that 
good in web application.


So, while you were writing your reply, I was already commenting out the call 
to the @Asynchronous method, and I reverted to the synchronous version of the 
method to update Google Calendar. After adding @Asynchronous, I added some 
logic that works better than @Asynchronous, it will not do a google calendar 
update on 'every' database update; I have some strategic processing in place 
that brought the # of google calendar requests down by hundreds and even 
thousands on a daily average.


You know what? I attempted to add to META-INF as well as WEB-INF (some days 
ago), and I already reported (in an earlier post) that that didn't allow my 
web app to start in TomEE (or Glassfish, if I was still using Glassfish when I 
reported that earlier...smile).


In response to Eclipse...hopefully, no offense will be taken, i'm not a user 
of eclipse, I've been a user of NetBeans ever since I started developing JSF 
web application (since last summer, 2011), and I can be the loyal type if 
something or someone treats me good. I was 'loyal' to Mojarra, but then I 
heard about the Mojarra issues updating components via AJAX, so I migrated to 
MyFaces Core (when I heard MyFaces Core 2.1.7+ performs better than Mojarra), 
and then reading one of your posts, Mark, about OpenWebBeans performing fast, 
and JIRA's and many people mentioning that CDI is better than JSF managed 
beans, I decided to migrate to CDI, and determined to use any/all features 
available that is offered by CDI, like events, SSE (server sent events), push 
(like Atmosphere), etc...


Was having trouble using Atmosphere with Glassfish, so decided to give TomEE a 
whirl, since you, Andy Bailey (a friend in PrimeFaces forum), and others 
recommended TomEE. I like all that Glassfish 'markets' (or tries to sell) to 
JSF developers, but I'm liking what I see and hear about TomEE, OpenWebBeans, 
OpenEJB, etc...


What is a good example or use case for using CDI events?

Thanks,
Howard




On Tue, Nov 20, 2012 at 9:36 AM, Mark Struberg strub...@yahoo.de wrote:

Hi!

One of my first advice is to make sure that beans.xml is really there for the 
container.
I've seen this pretty often if someone starts the webapp directly from 
Eclipse. In that case the CDI container sometimes cannot find 
WEB-INF/beans.xml as eclipse doesn't set the classpath entries correctly.

Sometimes it helps to add a META-INF/beans.xml to the webapp classpath. This 
will end up in WEB-INF/classes/META-INF/beans.xml and is perfectly fine from 
a spec perspective.

There's a 30% chance that this is your problem ;)

For the @Asynchronous:

In general I do not really like @Asynchronous in webapps. It's really very 
seldom

Re: Migrating to CDI: injecting stateless/facade in Converter via facescontext

[Mark Struberg]

Nope, I'm mostly using it with @JsfPhaseListeners.


We also don't have unit tests in CODI for converters. 


Please try

BeanManagerProvider.getInstance().getContextualReference(Yourclass.class);

inside the converter if you need it.
If it's a NormalScoped bean (Request-, Application-, SessionScoped, CODI 
scopes) then you only need to do this once as you only get a proxy anyway.

LieGrue,
strub



 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Tuesday, November 20, 2012 4:03 PM
Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via 
facescontext
 

I want to know why it didn't work either. I am using latest version of TomEE 
(1.5 SNAPSHOT), Myfaces 2.1.9, and CODI. Didn't work almost 12 hours ago, when 
I was attempting to use it.


Did you all test @Advanced with @FacesConverter(forClass=someClass.class)?


That's how I was using it, and bean was not injected inside of the converter. 
I read in at least 2 places that stated that @FacesConverter is not an 
elligble injection point, and I think you already told me (within last few 
hours) that this will be available in JSF 2.2. :)





On Tue, Nov 20, 2012 at 9:22 AM, Mark Struberg strub...@yahoo.de wrote:

CDI injection using @Advanced should work perfectly fine. We tested this 
excessively and use it on several containers in production.

I'm curious why it doesn't work for you.


LieGrue,
strub


- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com

 To: MyFaces Discussion users@myfaces.apache.org; Rafael Pestano 
 rmpest...@yahoo.com.br
 Cc:

 Sent: Tuesday, November 20, 2012 3:13 PM
 Subject: Re: Migrating to CDI: injecting stateless/facade in Converter via 
 facescontext

 Rafael,

 I saw that page about CODI @Advanced. :)

 I tried CODI @Advanced, but CDI managed bean was not injected voa @Inject,
 and then I tried to inject Stateless EJB via @Inject, and that stateless
 EJB was not injected either.

 Thanks,
 Howard

 On Tue, Nov 20, 2012 at 9:02 AM, Rafael Pestano
 rmpest...@yahoo.com.brwrote:

  you can also use CODI @Advanced and then inject anything in the
  converter, see [1].

  i hope it helps.

  [1]:
  https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-DependencyInjection


  Att,

  Rafael M. Pestano

  Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
  Graduando em Ciência da Computação UFRGS
  http://conventionsframework.org

  http://rpestano.wordpress.com/
  @realpestano


  
   De: Howard W. Smith, Jr. smithh032...@gmail.com
  Para: Mark Struberg strub...@yahoo.de; MyFaces Discussion 
  users@myfaces.apache.org
  Cc: us...@openejb.apache.org us...@openejb.apache.org
  Enviadas: Terça-feira, 20 de Novembro de 2012 11:37
  Assunto: Re: Migrating to CDI: injecting stateless/facade in Converter via
  facescontext

  Interesting and noted, thanks. Yes, I did hear JSF 2.2 will allow CDI in
  facesconverter. Thanks.
  On Nov 20, 2012 8:34 AM, Mark Struberg
 strub...@yahoo.de wrote:

   you could also have used CODI BeanManagerProvider#getReference to get
   access to the bean.
  
   The support you need out of the box will come in JSF-2.2.
  
  
   LieGrue,
   strub
  
  
  
   - Original Message -
    From: Howard W. Smith, Jr.
 smithh032...@gmail.com
    To: us...@openejb.apache.org; MyFaces Discussion 
   users@myfaces.apache.org
    Cc:
    Sent: Tuesday, November 20, 2012 1:56 PM
    Subject: Re: Migrating to CDI: injecting stateless/facade in
 Converter
   via facescontext
   
   T he goal was to inject bean in facesconverter via CDI, but I
 don't have
    this need anymore, since faces converter is not an eligible
 injection
    point, so I opted to use request scoped JSF managed beans that
 have
    facesconverter defined within the bean. That's working fine.
 Thanks.
   
    Okay, I can cc myfaces user group as well, going forward. :-)
    On Nov 20, 2012 7:37 AM, Romain Manni-Bucau
    rmannibu...@gmail.com
    wrote:
   
     i'm still not clear about your goal and where you need
 injection
   
     maybe share a (runnable) sample to show us what you are
 talking about
   
     side note: myfaces list can help you a lot about it too
   
     *Romain Manni-Bucau*
     *Twitter: @rmannibucau
 https://twitter.com/rmannibucau*
     *Blog: **http://rmannibucau.wordpress.com/*
     http://rmannibucau.wordpress.com/
     *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
     *Github: https://github.com/rmannibucau*
   
   
   
   
     2012/11/20 Howard W. Smith, Jr.
 smithh032...@gmail.com
   
      Interesting, that will allow you to get instance of
 beans, if
  already
      instantiated, and that could have helped in converter,
 only if
  beans
      already injected earlier?
      On Nov 20, 2012 7:11 AM, Romain Manni-Bucau
    rmannibu...@gmail.com
      wrote:
     
       was thinking

Re: Can start in debug, but not in release

[Mark Struberg]

The Hibernate serialisation issues look weird. What is your exact situation? Do 
you have an example of your app to share?

LieGrue,
strub






 From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org 
Sent: Tuesday, November 20, 2012 8:16 PM
Subject: Re: Can start in debug, but not in release
 
hi ludovic,

to get rid of
  ... no
org.apache.myfaces.extensions.cdi.core.api.provider.BeanManagerProvider in
place! ...
you have to ensure that all config-files and owb jar-files you are using
are packaged correctly.

you can compare your war-file e.g. with a war-file of a generated demo
generate it e.g. with #4 of:
mvn archetype:generate -DarchetypeCatalog=
http://people.apache.org/~gpetracek/myfaces/

regards,
gerhard



2012/11/20 l.pe...@senat.fr l.pe...@senat.fr

 Dear all,

 I hope I am in the right forum as a Myfaces/CODI user, it seemed a natural
 entry point to me...

 I have a webapp which perfectly works in debug in eclipse, but does not
 start on the same tomcat 7.0.32 container.

 The app is build with maven. I am using Eclipse juno with wtp integration.

 In eclipse,  tomcat startup parameters are :

 -Dcatalina.base=/home/lpenet/**workspace_cellule/.metadata/.**
 plugins/org.eclipse.wst.**server.core/tmp0 -Dcatalina.home=/opt/apache-*
 *tomcat-7.0.32 -Dwtp.deploy=/home/lpenet/**workspace_cellule/.metadata/.
 **plugins/org.eclipse.wst.**server.core/tmp0/wtpwebapps
 -Djava.endorsed.dirs=/opt/**apache-tomcat-7.0.32/endorsed
 -XX:MaxPermSize=512M -XX:+CMSClassUnloadingEnabled
 -Dorg.apache.el.parser.COERCE_**TO_ZERO=false

 (nothing special to me...)

 In bare tomcat, the following JAVA_OPTS are used :

 JAVA_OPTS=$JAVA_OPTS -XX:MaxPermSize=1024M -XX:+CMSClassUnloadingEnabled
 -Dorg.apache.el.parser.COERCE_**TO_ZERO=false

 (nothing special to me too...).

 Please find enclosed the corresponding logs.

 I also attach my web.xml, beans.xml and faces-context.xml.

 Do you have an idea ? Which logs can I turn on to get more info ?

 Thanks in advance.

 Ludovic Pénet

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

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

[Mark Struberg]

Hi Howard!


JUEL is an Expression Language implementation. It has nothing to do with CDI 
apart from CDI providing an ELResolver. JUEL is much faster than the EL 
interpreter in glassfish, so this is fine.

For your beans getting recognized in EL expressions: 

1.) Do you have a META-INF/beans.xml in all your jars/classpaths which contain 
CDI beans? This files can be empty, they just act as marker files. For the 
webapp you might add one to WEB-INF/beans.xml.


2.) Do your CDI beans you access via EL have a @Named annotation?
This is needed to make them available for ELResolvers.

3.) glassfish has a few nasty integration issues when it comes to pluggin in 
different container parts. Can you try your app on tomee-1.5? [1]. It comes 
with the latest MyFaces out of the box!

LieGrue,
strub


[1] http://tomee.apache.org/downloads.html


- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Saturday, November 17, 2012 10:35 AM
 Subject: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
 
 Web application details:
 JSF 2.1, MyFaces 2.1.9, PrimeFaces 3.4.1 (or 3.5-SNAPSHOT), Glassfish
 3.1.2.2 (build 5), JUEL 2.2.5
 
 From server log:
 INFO: WELD-000900 1.1.8 (Final)
 
 Yesterday, I started migrating from JSF Managed Beans to CDI Managed Beans.
 I referred to Chapter 28 (CDI) of Oracle's Java EE 6
 Tutorialhttp://docs.oracle.com/javaee/6/tutorial/doc/giwhb.htmlas
 well as many other pages I found on the internet.
 
 Finally, the app starts, as I think I completed most steps necessary to
 migrate to CDI managed beans, but now it seems as though my beans are not
 accessible from facelets. As per
 MYFACES-3104https://issues.apache.org/jira/browse/MYFACES-3104,
 I am already using *JUEL 2.2.5* (that is working well with JSF Managed
 Beans in production), so I already had *
 org.apache.myfaces.EXPRESSION_FACTORY* set in web.xml, as well as
 *org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL
 *to *false*, and the last thing I did was add the following to web.xml:
 
     context-param
         
 param-nameorg.apache.myfaces.annotation.SCAN_PACKAGES/param-name
         param-valuepf,jsf.users,jsf.orders/param-value
     /context-param
 
 Which are just a 'few' of the packages that contained beans referenced 
 by
 the initial page of the app (login.xhtml).
 
 My questions:
 
    1. Can someone please advise me of blog/tutorials that list any/all
    steps necessary to migrate MyFaces 2.1.9 / Glassfish 3.1.2.2 web app from
    JSF Managed Beans to CDI?
    2. I am not using MyFaces CODI or OpenWebBeans (yet). I've seen
    OpenWebBeans recommended with MyFaces Core (2.1.7+) for performance
    reasons, and in PrimeFaces forum, I've seen MyFaces Core and MyFaces CODI
    used together by some people. If I should use MyFaces CODI or OpenWebBeans,
    please reply with blog/tutorial/instruction URLs.
 
 My next steps will probably be any/all of the following:
 
    1. Remove JUEL 2.2.5 from the project, and see if I can successfully get
    my pages to render via CDI
    2. Add MyFaces CODI (need to search for a good set of instructions on
    how to do so)
    3. Add OpenWebBeans (same as above, need good set of instructions)
 
 Please confirm/advise. If you need any more details from me (for example,
 for me to reply with my web.xml), then please let me know.
 
 Thanks,
 Howard

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

[Mark Struberg]

If you have troubles starting tomee then don't hesitate to ping us via IRC on 
irc.freenode.net in channel #openejb (tomee s hosted there).

LieGrue,
strub




 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Saturday, November 17, 2012 12:06 PM
Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
 

Mark,


Thank you for the response.


1. Yes, I did add an 'empty' beans.xml to WEB-INF as advised by many places on 
the internet, and the app starts up successfully. I did 'not' have beans.xml 
added to META-INF, since all of my code is in the web app (I created no JARs 
of my own). I just added beans.xml to META-INF (while beans.xhtml already 
exists in WEB-INF), attempted to start glassfish, and I get the following 
error:


INFO: WELD-000900 1.1.8 (Final)
SEVERE: Exception while invoking class org.glassfish.weld.WeldDeployer load 
method
java.lang.NullPointerException
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:504)
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:482)
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:422)


I'm sure the error above means that my web app does not need 'empty' beans.xml 
in META-INF (and WEB-INF), so I will remove beans.xml from META-INF.


2. Yes, all CDI beans (accessed via EL) have @Named annotation, and I am using 
@Inject along with Qualifiers (for classes that extend ancestor classes). 
Below are notes from what I did/completed yesterday for this migration:


Migrate from JSF Managed Beans to CDI Managed Beans


Replace
javax.faces.bean.ManagedBean
with
javax.inject.Named


replace
javax.faces.bean.ManagedProperty
with
javax.inject.Inject


replace
javax.faces.bean.SessionScoped
with
javax.enterprise.context.SessionScoped


replace
javax.faces.bean.ApplicationScoped
with
javax.enterprise.context.ApplicationScoped


replace
@ManagedBean(name = 
with
@Named(


replace
@ManagedProperty(#{.*})
with
@Inject


Migrated applicationScopeBean from JSF ApplicationScoped managed bean to EJB 
@Singleton with @Startup (please disregard this, since the last thing I did 
with this was to migrate it to CDI applicationscoped instead of EJB singleton 
and startup)


Added CDI Qualifier called @Descendant for all descendants of Address, 
EmailAddress, Phone, and PointOfContact controllers


Replace
FacesContext.getCurrentInstance().getExternalContext().getSessionMap()


with @Inject and private instance variable




3. Honestly, I was hoping not to have to migrate to another container like 
Tomcat or TomEE, since I only have little/limited experience with those 
containers (as I attempted to migrate to Tomcat 7.0.32, 1 or 2 weeks ago, but 
too much was involved and I couldn't even get the web app to start). I am open 
to trying TomEE, hopefully, as a last-and-final option. :)



On Sat, Nov 17, 2012 at 5:04 AM, Mark Struberg strub...@yahoo.de wrote:

Hi Howard!


JUEL is an Expression Language implementation. It has nothing to do with CDI 
apart from CDI providing an ELResolver. JUEL is much faster than the EL 
interpreter in glassfish, so this is fine.

For your beans getting recognized in EL expressions:

1.) Do you have a META-INF/beans.xml in all your jars/classpaths which 
contain CDI beans? This files can be empty, they just act as marker files. 
For the webapp you might add one to WEB-INF/beans.xml.


2.) Do your CDI beans you access via EL have a @Named annotation?
This is needed to make them available for ELResolvers.

3.) glassfish has a few nasty integration issues when it comes to pluggin in 
different container parts. Can you try your app on tomee-1.5? [1]. It comes 
with the latest MyFaces out of the box!

LieGrue,
strub


[1] http://tomee.apache.org/downloads.html



- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc:
 Sent: Saturday, November 17, 2012 10:35 AM
 Subject: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

 Web application details:
 JSF 2.1, MyFaces 2.1.9, PrimeFaces 3.4.1 (or 3.5-SNAPSHOT), Glassfish
 3.1.2.2 (build 5), JUEL 2.2.5

 From server log:
 INFO: WELD-000900 1.1.8 (Final)

 Yesterday, I started migrating from JSF Managed Beans to CDI Managed Beans.
 I referred to Chapter 28 (CDI) of Oracle's Java EE 6
 Tutorialhttp://docs.oracle.com/javaee/6/tutorial/doc/giwhb.htmlas

 well as many other pages I found on the internet.

 Finally, the app starts, as I think I completed most steps necessary to
 migrate to CDI managed beans, but now it seems as though my beans are not
 accessible from facelets. As per
 MYFACES-3104https://issues.apache.org/jira/browse/MYFACES-3104,
 I am already using *JUEL 2.2.5* (that is working well with JSF Managed
 Beans in production), so I already had

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

[Mark Struberg]

Hi!

If you look for docs, here they are:

http://tomee.apache.org/documentation.html

LieGrue,
strub








 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: Mark Struberg strub...@yahoo.de 
Cc: MyFaces Discussion users@myfaces.apache.org 
Sent: Saturday, November 17, 2012 1:02 PM
Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
 

Great, thanks Mark. I did download TomEE, and looking at examples (referenced 
on same page as TomEE downloads) and I'm looking at this guide below to ensure 
I am injecting beans correctly.


http://docs.jboss.org/weld/reference/1.0.0/en-US/html/injection.html



On Sat, Nov 17, 2012 at 6:50 AM, Mark Struberg strub...@yahoo.de wrote:

If you have troubles starting tomee then don't hesitate to ping us via IRC on 
irc.freenode.net in channel #openejb (tomee s hosted there).

LieGrue,
strub





 From: Howard W. Smith, Jr. smithh032...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
strub...@yahoo.de
Sent: Saturday, November 17, 2012 12:06 PM
Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed 
Beans



Mark,


Thank you for the response.


1. Yes, I did add an 'empty' beans.xml to WEB-INF as advised by many places 
on the internet, and the app starts up successfully. I did 'not' have 
beans.xml added to META-INF, since all of my code is in the web app (I 
created no JARs of my own). I just added beans.xml to META-INF (while 
beans.xhtml already exists in WEB-INF), attempted to start glassfish, and I 
get the following error:


INFO: WELD-000900 1.1.8 (Final)
SEVERE: Exception while invoking class org.glassfish.weld.WeldDeployer load 
method
java.lang.NullPointerException
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:504)
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:482)
at 
org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:422)


I'm sure the error above means that my web app does not need 'empty' 
beans.xml in META-INF (and WEB-INF), so I will remove beans.xml from 
META-INF.


2. Yes, all CDI beans (accessed via EL) have @Named annotation, and I am 
using @Inject along with Qualifiers (for classes that extend ancestor 
classes). Below are notes from what I did/completed yesterday for this 
migration:


Migrate from JSF Managed Beans to CDI Managed Beans


Replace
javax.faces.bean.ManagedBean
with
javax.inject.Named


replace
javax.faces.bean.ManagedProperty
with
javax.inject.Inject


replace
javax.faces.bean.SessionScoped
with
javax.enterprise.context.SessionScoped


replace
javax.faces.bean.ApplicationScoped
with
javax.enterprise.context.ApplicationScoped


replace
@ManagedBean(name = 
with
@Named(


replace
@ManagedProperty(#{.*})
with
@Inject


Migrated applicationScopeBean from JSF ApplicationScoped managed bean to EJB 
@Singleton with @Startup (please disregard this, since the last thing I did 
with this was to migrate it to CDI applicationscoped instead of EJB 
singleton and startup)


Added CDI Qualifier called @Descendant for all descendants of Address, 
EmailAddress, Phone, and PointOfContact controllers


Replace
FacesContext.getCurrentInstance().getExternalContext().getSessionMap()


with @Inject and private instance variable




3. Honestly, I was hoping not to have to migrate to another container like 
Tomcat or TomEE, since I only have little/limited experience with those 
containers (as I attempted to migrate to Tomcat 7.0.32, 1 or 2 weeks ago, 
but too much was involved and I couldn't even get the web app to start). I 
am open to trying TomEE, hopefully, as a last-and-final option. :)



On Sat, Nov 17, 2012 at 5:04 AM, Mark Struberg strub...@yahoo.de wrote:

Hi Howard!


JUEL is an Expression Language implementation. It has nothing to do with 
CDI apart from CDI providing an ELResolver. JUEL is much faster than the EL 
interpreter in glassfish, so this is fine.

For your beans getting recognized in EL expressions:

1.) Do you have a META-INF/beans.xml in all your jars/classpaths which 
contain CDI beans? This files can be empty, they just act as marker files. 
For the webapp you might add one to WEB-INF/beans.xml.


2.) Do your CDI beans you access via EL have a @Named annotation?
This is needed to make them available for ELResolvers.

3.) glassfish has a few nasty integration issues when it comes to pluggin 
in different container parts. Can you try your app on tomee-1.5? [1]. It 
comes with the latest MyFaces out of the box!

LieGrue,
strub


[1] http://tomee.apache.org/downloads.html



- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc:
 Sent: Saturday, November 17, 2012 10:35 AM
 Subject: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

 Web application details:
 JSF 2.1, MyFaces

Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans

[Mark Struberg]

Hi Howard!

cross-posting to openejb-dev which is the community behind TomEE.

Juel is an Expression Language library which parses the EL expressions and 
invokes the various registered ELResolvers until one of them feels responsible. 

TomEE (like glassfish) contains plain tomcat which has an own EL library in 
jasper-el. 
Please remove juel for now. We will add it back later. also comment out the 
expression factory context-param in your web.xml.

I'm not sure if that helps, but via remote I can only to give you tips until we 
found the problem.


PS: TODO we gonna write up a documentation about how to use JUEL with TomEE.



- Original Message -
 From: Howard W. Smith, Jr. smithh032...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Saturday, November 17, 2012 5:49 PM
 Subject: Re: MyFaces 2.1.9 / Glassfish 3.1.2.2: Migrating to CDI Managed Beans
 
 Okay, I downloaded TomEE 1.5 plus, and trying to start the app.
 
 I have the following in my web.xml:
 
     context-param
         
 param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
         
 param-valuede.odysseus.el.ExpressionFactoryImpl/param-value
     /context-param
 
 The error(s) below leads me to believe that I may need to remove JUEL 2.2.5
 from my web app. Please confirm/advise.
 
 Nov 17, 2012 11:37:24 AM org.apache.catalina.loader.WebappClassLoader
 validateJarFile
 INFO:
 validateJarFile(C:\Users\Public\NetBeansProjects\mcms\build\web\WEB-INF\lib\juel-2.2.5.jar)
 - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
 javax/el/Expression.class
 Nov 17, 2012 11:37:24 AM org.apache.tomee.catalina.TomEEClassLoaderEnricher
 validateJarFile
 WARNING: jar
 'C:\Users\Public\NetBeansProjects\mcms\build\web\WEB-INF\lib\transaction-api-1.1.jar'
 contains offending class: javax.transaction.Transaction. It will be ignored.
 
 
 Nov 17, 2012 11:37:33 AM org.apache.openejb.cdi.CdiAppContextsService
 lazyStartSessionContext
 WARNING: Could NOT lazily initialize session context because of null
 RequestContext
 Nov 17, 2012 11:37:33 AM org.apache.myfaces.webapp.AbstractFacesInitializer
 initFaces
 SEVERE: An error occured while initializing MyFaces: No
 javax.el.ExpressionFactory found. Please provide context-param in
 web.xml: org.apache.myfaces.EXPRESSION_FACTORY
 javax.faces.FacesException: No javax.el.ExpressionFactory found. Please
 provide context-param in web.xml: org.apache.myfaces.EXPRESSION_FACTORY
 at
 org.apache.myfaces.webapp.FaceletsInitilializer.initContainerIntegration(FaceletsInitilializer.java:42)
 
 
 
 
 On Sat, Nov 17, 2012 at 11:22 AM, Gerhard Petracek 
 gerhard.petra...@gmail.com wrote:
 
  hi jose,
 
  just fyi:
  with tomee you don't need weld, because you get openwebbeans
  out-of-the-box.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/11/17 José Luis Cetina maxtorz...@gmail.com
 
   Hi let me tell you my experience.
   I migrate from managedbeans + mojarra + glassfish to myfaces + WELD +
  TomEE
   and now I'm so happy to did so.
  
   Now my app use:
   -Apache TomEE 1.5
   -Apache MyFaces
   -Apache CODI
   -Primefaces 3.4.2
   -Primefaces Mobile
   -Primefaces Extensions 0.6.1
   -PrettyFaces  3.3.3
   -OpenJPA 2.2
   -EJB
   -JdbcRealm for login (my own query for login using any tables in my 
 mysql
   database).
   -WELD
   -And all the excellent Apache stuff
   Etc...
  
   And I'm so happy with this change, the this are more easy to 
 config, use
   more standards, is very very fast, use myfaces and with this you can
  forget
   speed issues.
  
   This project is a maven project, in netbeans 7.2.
  
   If you need some example project I can send you a simple example.
  
   I enhance my jpa entities so easy with maven plugin, run in every IDE 
 and
   other stuff that are excellents
  
   Seriously if have the opportunity and time to migrate do it now you 
 will
  be
   happy.
  
   And one tip maybe you don't need CODI at the beginning. CODI can 
 help in
   many things like type-safe navigations, security, validations,
   prerenders
   events and so on.
  
   Al most forget to tell you the easy Way for drop your jars in lib 
 folder
   and with this decrease your war size, I remember in glassfish 
 sometimes
  it
   wasn't easy.
  
   I recommend you to be alert for changes and fixes in TomEE, because 
 they
   fix issues and update in they trunk svn everyday.
  
   Please suscribe to TomEE mailing lists. Rommain is a great commiter 
 guy
  who
   help immediately with other people.
  
   I hope this experience can help you.
  
   SCJA. Jose Luis Cetina
   maxtorzito
    El 17/11/2012 06:06, Mark Struberg 
 strub...@yahoo.de escribió:
  
Hi!
   
If you look for docs, here they are:
   
http://tomee.apache.org/documentation.html
   
LieGrue,
strub

Re: Non existing views are rendered and throw an exception instead of 404 with myfaces 2.1.9

[Mark Struberg]

Hi!

Please add your findings to https://issues.apache.org/jira/browse/MYFACES-3638

txs and LieGrue,
strub





 From: Marcus Büttner buettner.mar...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org 
Sent: Tuesday, November 13, 2012 5:50 PM
Subject: Non existing views are rendered and throw an exception instead of 404 
with myfaces 2.1.9
 
What happens with views which not exists in myfaces 2.1.9?

I get the following Exception:

org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)


The question is, why a view which not exists is rendered. In MyFaces 2.1.8
there is the same behavior but there the viewId is not taken for
calculating some keys.

In JspViewDeclarationLanguage#buildView the calculated viewId which is null
is taken to do a externalContext.dispatch(viewId). This dispatch returns an
error with status 404. Than it's called:
wrappedResponse.flushToWrappedResponse();

Mojarra does after that a responseComplete, MyFaces does not.
Could that be the problem?

regards
Marcus Büttner

Re: [EXT-CDI] - ClientSideWindowHandler - Nag-Screen on every 'faces-redirect=true'.

[Mark Struberg]

Hi Heiko!

Yes, this is perfectly possible

@SessionScoped
@Specializes
public class YourClientConfig extends ClientConfig implements Serializable {
  @Overrides

  public boolean isClientSideWindowHandlerRequest(FacesContext facesContext) {
    return false; // or implement your own logic based on UserAgent, the URL, 
etc

  }



I'm not quite sure if I really understood your initial problem though. Do you 
have a javascript blocker active for that page?

This intermediate page is almost pure JavaScript and just detects whether you 
are on a new page or not. It will then either request a new windowId (if you 
are on a new browser tab) or re-execute the original request to your target 
page.

LieGrue,
strub


- Original Message -
 From: it-media.k...@daimler.com it-media.k...@daimler.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Thursday, October 18, 2012 9:24 AM
 Subject: [EXT-CDI] - ClientSideWindowHandler - Nag-Screen on every 
 'faces-redirect=true'.
 
 Hello everybody,
 
 I'm currently on the way to port an application to JSF 2.0 + EXT-CDI + 
 Primefaces. For easier handling and better URL-Support I setup EXT-CDI to 
 always do redirects when navigating between pages (via @Page(navigation = 
 NavigationMode.REDIRECT). However, this leads to an annoying problem with 
 the ClientSideWindowHandler that shows a page with something like 'Your 
 browser does not support Javascript'. That is actually not true, and the 
 screen is replaced by the new view.
 
 Is there a way to configure the ClientSideWindowHandler to NOT show this 
 page between redirects? That would be great. Otherwise I think I'll stick 
 to the ServerSideWindowHandler.
 
 Best regards, and thanks for your help,
 
 Heiko
 
 --
 Dr.-Ing. Heiko Kopp / Fa. Vision iT media GmbH
 
 If you are not the intended addressee, please inform us immediately that you 
 have received this e-mail in error, and delete it. We thank you for your 
 cooperation.  

a small CDI related survey

[Mark Struberg]

Hi folks!

I have a slightly offtopic survey for you.

The question is how the current @ApplicationScoped in CDI should behave.
Should it be 1 instance per WAR or 1 instance per EAR?

To make this more clear: in CDI-1.1 we will have both scopes at the end.
Please also note that any scope broader than 1 per WAR file will break 
@Specializes and @Alternatives in WAR files.
So if you have an EAR project and like to use @Specializes or @Alternatives you 
need to do that in a jar on the shared classpath. 



Here is the survey:

http://www.surveymonkey.com/s/9VNXZDB


LieGrue,
strub


PS: having 1 per ear will mean 1 BeanManager for the whole EAR as well, so 
CODI, DeltaSpike and even Seam3 are known to be broken with that 
approach I fear ...

Re: Setting CODI project stage

[Mark Struberg]

Hi Ludovic!

I'm using -Dfaces.PROJECT_STAGE=Development which works perfectly.

In production we have set it via JNDI in tomcats conf/context.xml:

    Environment name=jsf/ProjectStage value=SystemTest 
  type=java.lang.String override=false/

LieGrue,
strub




- Original Message -
 From: l.pe...@senat.fr l.pe...@senat.fr
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Monday, October 8, 2012 2:07 PM
 Subject: Setting CODI project stage
 
 Hi.
 
 How can I configure the CODI project stage ? I crawled the doc but found 
 nothing. In the 
 org/apache/myfaces/extensions/cdi/core/api/projectstage/ProjectStage.java 
 source 
 file, I found the following doc :
 
 53  * pThe following resolution mechanism is used to determine the 
 current ProjectStage:
 54  * ul
 55  *  liTODO specify!/li
 56  * /ul
 57  * /p
 
 I tried to define javax.faces.PROJECT_STAGE=Development as a system property, 
 as 
 found on stackoverflow.com, but this does not seem to work.
 
 Thanks in advance for your help.
 
 Ludovic
 
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: MyFaces CODI within EAR

[Mark Struberg]

Sorry Christian, saw your mail only now. 

You solution makes perfect sense. Didn't know JBoss AS tries to start CDI with 
not having all the ClassPath in place. I sense some more problems will hit you 
in this case. What JBossAS version do you use exactly? I would report this 
issue to the JBoss team. Guess they are happy about such a feedback!

LieGrue,
strub




- Original Message -
 From: Christian Beikov christian.bei...@gmail.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Friday, September 7, 2012 7:36 AM
 Subject: Re: MyFaces CODI within EAR
 
 Well, it took me some time, but I figured out that JBoss AS does not add the 
 JSF 
 stuff to the classpath when starting CODI. The solution for JBoss AS7 to get 
 CODI working when located in EAR/lib finally is:
 
 Add a jboss-deployment-structure.xml file to EAR/META-INF that looks like 
 this:
 
 ?xml version=1.0 encoding=UTF-8?
 jboss-deployment-structure
     !-- Make sub deployments isolated by default, so they cannot see each 
 others
         classes without a Class-Path entry --
 ear-subdeployments-isolatedtrue/ear-subdeployments-isolated
     !-- This corresponds to the top level deployment. For a war this is the
         war's module, for an ear --
     !-- This is the top level ear module, which contains all the classes in
         the EAR's lib folder --
     deployment
         !-- This allows you to define additional dependencies, it is the 
 same
             as using the Dependencies: manifest attribute --
         dependencies
             module name=org.w3c.css.sac /
             module name=net.sourceforge.cssparser /
             module name=com.sun.jsf-impl /
             module name=javax.api /
             module name=javax.faces.api /
             module name=javax.xml.bind.api /
             module name=javax.xml.jaxp-provider /
             module name=com.google.guava /
         /dependencies
     /deployment
 /jboss-deployment-structure
 
 This will make everything that is somehow jsf specific available for the CODI 
 jar. Hope this might help someone else.
 
 Regards,
 Christian
 
 Am 06.09.2012 22:29, schrieb Mark Struberg:
  Hi christian!
 
  Yes, this is perfectly possible. You just have to move all your JSF deps 
 which are needed by CODI to a shared jar  (in an EAR lib).
  myfaces-api.jar myfaces-impl.jar, el, etc. All the stuff which is 
 (transitively) required on the classpath.
 
  I have this scenario running over here with 12 webapps in an EAR (with 
 ClassLoader isolation).
 
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Christian Beikov christian.bei...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc:
  Sent: Thursday, September 6, 2012 10:06 PM
  Subject: MyFaces CODI within EAR
 
  Hello!
 
  I am trying to package the codi jsf 2 bundle 1.0.5 within my ear but I 
 am
  getting some exceptions like:
 
  java.lang.NoClassDefFoundError: javax/faces/bean/ViewScoped
 
  I have placed the bundle in EAR/lib since I have 2 Webapps that use 
 CODI.
  Is it even possible to use CODI in such a scenario? Could you please 
 provide
  some details on how CODI is supposed to be packaged within an EAR?
 
  Regards,
  Christian
 

Re: MyFaces CODI within EAR

[Mark Struberg]

Hi christian!

Yes, this is perfectly possible. You just have to move all your JSF deps which 
are needed by CODI to a shared jar  (in an EAR lib).
myfaces-api.jar myfaces-impl.jar, el, etc. All the stuff which is 
(transitively) required on the classpath.

I have this scenario running over here with 12 webapps in an EAR (with 
ClassLoader isolation).


LieGrue,
strub




- Original Message -
 From: Christian Beikov christian.bei...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, September 6, 2012 10:06 PM
 Subject: MyFaces CODI within EAR
 
 Hello!
 
 I am trying to package the codi jsf 2 bundle 1.0.5 within my ear but I am 
 getting some exceptions like:
 
 java.lang.NoClassDefFoundError: javax/faces/bean/ViewScoped
 
 I have placed the bundle in EAR/lib since I have 2 Webapps that use CODI.
 Is it even possible to use CODI in such a scenario? Could you please provide 
 some details on how CODI is supposed to be packaged within an EAR?
 
 Regards,
 Christian

Re: CODI Page

[Mark Struberg]

Hi José!


Well, interface and class naming is a topic which gets discussed since 25 years 
now (starting with Smalltalk) and I can tell you that there is _no_ common view 
about a naming schema ;)

Anyway, glad it worked out for you and hope you find CODI useful!

LieGrue,
strub



- Original Message -
 From: José Luis Cetina maxtorz...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, June 14, 2012 1:51 PM
 Subject: Re: CODI Page
 
 I didn't see it, Thanks a lot, i will remove the I prefix.
 Can be a good idea  that CODI support  (with base path) the use of the 
 I
 prefix or the able postfix for interfaces, as you know this is the 
 rigth
 way to name an interface.
 For now ill remove the I prefix and name ny interface as my page using the
 naming convention.
 
 Thanks
 El 14/06/2012 04:01, Gerhard Petracek 
 gerhard.petra...@gmail.com
 escribió:
 
  hi jose,
 
  the link [1] i provided shows it already:
  e.g. Pages.Vip.VipContent.class leads to /pages/vip/vipContent.xhtml
 
  (if you have to keep the 'I' prefix for interfaces, you have to 
 provide the
  full base-path (with the current implementation))
 
  regards,
  gerhard
 
  [1] http://s.apache.org/SBP
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/6/14 José Luis Cetina maxtorz...@gmail.com
 
   Is there a way to do it without basepath? I mean, its possible to use
  type
   safe navigation in  CODI with more than one level folder structure?
   El 13/06/2012 21:35, Gerhard Petracek 
 gerhard.petra...@gmail.com
   escribió:
  
hi jose,
   
right now it isn't supported (it doesn't get aggregated), 
 because
   basePath
is more for exceptional/special cases.
typically the used style is more like [1] (as you can see 
 it's a
  simpler
style - e.g. you don't need an explicit usage of
@Page(name=myPageClassName) due to the default naming 
 convention).
   
regards,
gerhard
   
[1] http://s.apache.org/SBP
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/6/13 José Luis Cetina maxtorz...@gmail.com
   
 Hi i have this folder structure

 web/
 public/
 index.xhtml

 then i use this:

 @Page(navigation = Page.NavigationMode.REDIRECT,
  basePath=web/public)
 public interface IPublic extends ViewConfig{
      public @Page(name=index) class Index 
 implements IPublic{}
 }

 this works great.

 But i dont like to use the basePath=web/public, 
 how can i separate?
 What i did, was create an interface like this:

 my root folder:
 @Page(navigation = Page.NavigationMode.REDIRECT, 
 basePath=web)
 public interfaces IWeb extends ViewConfig{
 }

 my folder under root (like web/public)
 @Page(navigation = Page.NavigationMode.REDIRECT, 
 basePath=public)
 public interfaces IPublic extends IWeb{
   //then the page
   public @Page(name=index) class Index 
 implements IPublic{}
 }

 but this doesnt work.

 What is the best way to do it?. Im using CODI 1.0.5



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

   
  
 

Re: Conversation Scope in JSF 2.0

[Mark Struberg]

Hi!

I've not used weblogic 10.x in my projects so far, but Gerhard might know more 
about it.

I would say that there are 2 areas which must get clarified:

a.) is OWB fine storing the @SessionScoped beans in the http session at the end 
of the request? I think this works fine if you enable the FailOver mechanism.

b.)how does the clustering logic of WebLogic work? I have no clue in this 
area...


LieGrue,
strub



- Original Message -
 From: tclam tc...@hkeaa.edu.hk
 To: users@myfaces.apache.org
 Cc: 
 Sent: Friday, May 18, 2012 4:24 AM
 Subject: Re: Conversation Scope in JSF 2.0
 
 
 Thank you very much!
 
 Do you know if this 'FAILOver' mechanism of OWB support in Weblogic 
 10.3.4?
 We are using weblogic as our application server.
 
 
 
 struberg wrote:
 
  The context for handling all CODI @ConversationScoped beans ALREADY get
  stored in a @SessionScoped bean. Thus it will end up in the Session
  somehow. But this is impl and situation depending!
 
  In OWB we do NOT store @SessionScoped beans directly in the Session,
  because the http session is _damn_ slow. Instead we store it in an
  internal map, and only store it over if there is a request for replicating
  the Session. In OWB we call this mechanism 'FailOver'.
 
 
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: tclam tc...@hkeaa.edu.hk
  To: users@myfaces.apache.org
  Cc: 
  Sent: Wednesday, May 16, 2012 10:26 AM
  Subject: Re: Conversation Scope in JSF 2.0
 
 
  Hi struberg,
 
  Do you mean that all the @ConversationScoped bean is already stored in
  @SessionScoped bean in CDI specification?
 
  Or 
 
  Do you mean that I have to wrap a @ConversationScoped bean with another
  @SessionScoped bean in my own coding?
 
 
 
 
  struberg wrote:
 
   Hi!
 
   All the CDI @ConversationScoped gets stored in a @SessionScoped 
 bean
   managed by the CDI container. Finally this will somewhen end up in 
 the
   session (the 'when' is implementation specific).
 
   LieGrue,
   strub
 
 
 
   - Original Message -
   From: tclam tc...@hkeaa.edu.hk
   To: users@myfaces.apache.org
   Cc: 
   Sent: Wednesday, May 16, 2012 9:23 AM
   Subject: Re: Conversation Scope in JSF 2.0
 
 
   Thank you. 
   Have you test the conversation during session replication?
 
   Anyone try MyFaces Orchestra?
 
 
 
   Thomas Andraschko-2 wrote:
 
    I use CODI in an clustered environemnt, no problems till 
 now :)
 
    2012/5/16 tclam tc...@hkeaa.edu.hk
 
 
    I am trying to implement conversation scope in 
 backing bean of 
  JSF for
    our
    application. At first, I am trying to use MyFaces 
 Orchestra. 
  It seems 
   to
    work well. However, I am concerning the case when the 
 
  application
    deployed
    in cluster environment and during session 
 replication. I 
  don't know 
   if
    MyFaces CODI with OpenWebBean is a better choice.
 
    I have two questions to ask:
 
 
    (1) Does MyFaces Orchestra works well in cluster 
 environment? 
  Will the
    conversation maintains after session replication?
 
 
    (2) Does MyFaces CODI have any issues when deployed 
 in cluster
    environment?
    I cannot found any information about this in its 
 document.
    --
    View this message in context:
 
 
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33855502.html
    Sent from the MyFaces - Users mailing list archive at 
 
  Nabble.com.
 
 
 
 
 
   -- 
   View this message in context: 
 
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33856260.html
   Sent from the MyFaces - Users mailing list archive at 
 Nabble.com.
 
 
 
 
  -- 
  View this message in context: 
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33856469.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
 
 
 -- 
 View this message in context: 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33868142.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Conversation Scope in JSF 2.0

[Mark Struberg]

Hi!

All the CDI @ConversationScoped gets stored in a @SessionScoped bean managed by 
the CDI container. Finally this will somewhen end up in the session (the 'when' 
is implementation specific).

LieGrue,
strub



- Original Message -
 From: tclam tc...@hkeaa.edu.hk
 To: users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, May 16, 2012 9:23 AM
 Subject: Re: Conversation Scope in JSF 2.0
 
 
 Thank you. 
 Have you test the conversation during session replication?
 
 Anyone try MyFaces Orchestra?
 
 
 
 Thomas Andraschko-2 wrote:
 
  I use CODI in an clustered environemnt, no problems till now :)
 
  2012/5/16 tclam tc...@hkeaa.edu.hk
 
 
  I am trying to implement conversation scope in backing bean of JSF for
  our
  application. At first, I am trying to use MyFaces Orchestra. It seems 
 to
  work well. However, I am concerning the case when the application
  deployed
  in cluster environment and during session replication. I don't know 
 if
  MyFaces CODI with OpenWebBean is a better choice.
 
  I have two questions to ask:
 
 
  (1) Does MyFaces Orchestra works well in cluster environment? Will the
  conversation maintains after session replication?
 
 
  (2) Does MyFaces CODI have any issues when deployed in cluster
  environment?
  I cannot found any information about this in its document.
  --
  View this message in context:
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33855502.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
 
 
 
 -- 
 View this message in context: 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33856260.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.
 

Re: Conversation Scope in JSF 2.0

[Mark Struberg]

The context for handling all CODI @ConversationScoped beans ALREADY get stored 
in a @SessionScoped bean. Thus it will end up in the Session somehow. But this 
is impl and situation depending!

In OWB we do NOT store @SessionScoped beans directly in the Session, because 
the http session is _damn_ slow. Instead we store it in an internal map, and 
only store it over if there is a request for replicating the Session. In OWB we 
call this mechanism 'FailOver'.



LieGrue,
strub



- Original Message -
 From: tclam tc...@hkeaa.edu.hk
 To: users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, May 16, 2012 10:26 AM
 Subject: Re: Conversation Scope in JSF 2.0
 
 
 Hi struberg,
 
 Do you mean that all the @ConversationScoped bean is already stored in
 @SessionScoped bean in CDI specification?
 
 Or 
 
 Do you mean that I have to wrap a @ConversationScoped bean with another
 @SessionScoped bean in my own coding?
 
 
 
 
 struberg wrote:
 
  Hi!
 
  All the CDI @ConversationScoped gets stored in a @SessionScoped bean
  managed by the CDI container. Finally this will somewhen end up in the
  session (the 'when' is implementation specific).
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: tclam tc...@hkeaa.edu.hk
  To: users@myfaces.apache.org
  Cc: 
  Sent: Wednesday, May 16, 2012 9:23 AM
  Subject: Re: Conversation Scope in JSF 2.0
 
 
  Thank you. 
  Have you test the conversation during session replication?
 
  Anyone try MyFaces Orchestra?
 
 
 
  Thomas Andraschko-2 wrote:
 
   I use CODI in an clustered environemnt, no problems till now :)
 
   2012/5/16 tclam tc...@hkeaa.edu.hk
 
 
   I am trying to implement conversation scope in backing bean of 
 JSF for
   our
   application. At first, I am trying to use MyFaces Orchestra. 
 It seems 
  to
   work well. However, I am concerning the case when the 
 application
   deployed
   in cluster environment and during session replication. I 
 don't know 
  if
   MyFaces CODI with OpenWebBean is a better choice.
 
   I have two questions to ask:
 
 
   (1) Does MyFaces Orchestra works well in cluster environment? 
 Will the
   conversation maintains after session replication?
 
 
   (2) Does MyFaces CODI have any issues when deployed in cluster
   environment?
   I cannot found any information about this in its document.
   --
   View this message in context:
 
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33855502.html
   Sent from the MyFaces - Users mailing list archive at 
 Nabble.com.
 
 
 
 
 
  -- 
  View this message in context: 
 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33856260.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
 
 
 -- 
 View this message in context: 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33856469.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Conversation Scope in JSF 2.0

[Mark Struberg]

 Because of that, we're now in the process of switching to CODI that it's 
 fully serializable, and allows the session to be persisted/distributed.

Yes, but please be aware that the EntityManager is still NOT Serializable! Even 
if some JPA providers claim it, they will loose state on serialisation!

I triggered a discussion on the JPA EG regarding this. See 
http://java.net/jira/browse/JPA_SPEC-21


It's really annoying that JPA is still borked even after so many years :/ Feel 
free to vote for the spec issue as it seems that this still will be ignored 
because of political reasons (the different JPA vendors basically do not agree 
how to solve this best).


LieGrue,
strub



- Original Message -
 From: Freire, Jose Luis (PT - Lisbon) jfre...@deloitte.pt
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, May 16, 2012 10:34 AM
 Subject: RE: Conversation Scope in JSF 2.0
 
 MyFaces Orchestra doesn't support session persistence because the 
 conversation object isn't serializable, and will not work in a cluster 
 environment.
 
 According to the official page 
 (http://myfaces.apache.org/orchestra/index.html, 
 see Limitations) there is still some work to be done.
 
 Because of that, we're now in the process of switching to CODI that it's 
 fully serializable, and allows the session to be persisted/distributed.
 
 -Original Message-
 From: tclam [mailto:tc...@hkeaa.edu.hk]
 Sent: quarta-feira, 16 de Maio de 2012 02:49
 To: users@myfaces.apache.org
 Subject: Conversation Scope in JSF 2.0
 
 
 I am trying to implement conversation scope in backing bean of JSF for our 
 application. At first, I am trying to use MyFaces Orchestra. It seems to work 
 well. However, I am concerning the case when the application deployed in 
 cluster 
 environment and during session replication. I don't know if MyFaces CODI 
 with OpenWebBean is a better choice.
 
 I have two questions to ask:
 
 
 (1) Does MyFaces Orchestra works well in cluster environment? Will the 
 conversation maintains after session replication?
 
 
 (2) Does MyFaces CODI have any issues when deployed in cluster environment?
 I cannot found any information about this in its document.
 --
 View this message in context: 
 http://old.nabble.com/Conversation-Scope-in-JSF-2.0-tp33855502p33855502.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 
  
 *Disclaimer:*
 Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK 
 private 
 company limited by guarantee, and its network of member firms, each of which 
 is 
 a legally separate and independent entity. Please see www.deloitte.com/about 
 for 
 a detailed description of the legal structure of Deloitte Touche Tohmatsu 
 Limited and its member firms.
 Privileged/Confidential Information may be contained in this message. If you 
 are 
 not the addressee indicated in this message (or responsible for delivery of 
 the 
 message to such person), you may not copy or deliver this message to anyone. 
 In 
 such case, you should destroy this message and kindly notify the sender by 
 reply 
 email. Please advise immediately if you or your employer do not consent to 
 Internet email for messages of this kind. Opinions, conclusions and other 
 information in this message that do not relate to the official business of my 
 firm shall be understood as neither given nor endorsed by it.

Re: [CODI] ViewAccessScoped beans without windowId in URL

[Mark Struberg]

Hi folks!

We've done some intense testing and I really suggest to use the windowId url 
parameter and also to use the ClientSideWindowhandler with the windowhandler.js 
and windowhandler.html stuff. If you have customers/users which are used to 
open multiple browser tabs, then this is the only perfectly working solution.

Btw, the windowId in the URL doesn't make any problem because it will get 
checked against the window.name. And if those doesn't fit then we just request 
a new windowId.

LieGrue,
strub



- Original Message -
 From: Rafael Pestano rmpest...@yahoo.com.br
 To: MyFaces Discussion users@myfaces.apache.org; Pavel Arnošt 
 pavel.arn...@loutka.cz
 Cc: 
 Sent: Thursday, May 10, 2012 3:20 PM
 Subject: Re: [CODI] ViewAccessScoped beans without windowId in URL
 
 Hi Pavel,
 
 WindowContextConfig#isUrlParameterSupported should be enough, does serverside 
 demo  work for you? 
 
 http://people.apache.org/~gpetracek/myfaces/codi/demos/serverside_demo_jsf12.zip
 
 
 keep in mind that the bean will not survive to a redirect.
 I hope it helps. 
 
 Att, 
 
 Rafael M. Pestano
 
 Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
 Graduando em Ciência da Computação UFRGS
 http://code.google.com/p/jsf-conventions-framework/
 http://rpestano.wordpress.com
 @realpestano 
 
 
 
 
 De: Pavel Arnošt pavel.arn...@loutka.cz
 Para: users@myfaces.apache.org 
 Enviadas: Quinta-feira, 10 de Maio de 2012 9:41
 Assunto: [CODI] ViewAccessScoped beans without windowId in URL
 
 Hi,
 
 I already read documentation in the wiki and several old posts, but I
 don't still get it - is it possible to use ViewAccessScoped beans
 without windowId in URL? When I disable
 WindowContextConfig#isUrlParameterSupported, windowId is gone but AJAX
 calls now creates new bean instances on requests. In javadoc, there is
 a note about server-side window-handler, how can I use it?
 
 Thanks,
 Regards,
 Pavel Arnost

Re: [CODI] ViewAccessScoped beans without windowId in URL

[Mark Struberg]

Hi Pavel!

Welcome to the MyFaces list!

The windodwId gets propagated in 2 ways:

1.) for GET requests we use the windowId parameter
2.) for POST requests we have it in our viewState. 



Thus the windowId should also be available in AJAX requests. But you don't need 
the URL parameter for it.

LieGrue,
strub



- Original Message -
 From: Pavel Arnost pavel.arn...@loutka.cz
 To: users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, May 8, 2012 12:07 AM
 Subject: [CODI] ViewAccessScoped beans without windowId in URL
 
 
 Hi,
 
 I already read documentation in the wiki and several old posts, but I don't
 still get it - is it possible to use ViewAccessScoped beans without windowId
 in URL? When I disable WindowContextConfig#isUrlParameterSupported, windowId
 is gone but AJAX calls now creates new bean instances on requests. In
 javadoc, there is a note about server-side window-handler, how can I 
 use
 it?
 
 Thanks,
 Regards,
 Pavel Arnost
 -- 
 View this message in context: 
 http://old.nabble.com/-CODI--ViewAccessScoped-beans-without-windowId-in-URL-tp33763549p33763549.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.
 

Re: no parallel ajax requests anymore with JSF 2.1?

[Mark Struberg]

Not having the request/view token properly updated in a sequential way would 
also make it impossible to properly do cross request state forgery prevention.

LieGrue,
strub



- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Monday, April 23, 2012 11:18 AM
 Subject: Re: no parallel ajax requests anymore with JSF 2.1?
 
 Hi
 
 Hard to say whether it is a good or bad feature, since I was not part of 
 the discussion when they went for the serialized model I only can guess 
 why it is like that. As I stated before, not being serialized would pose 
 problems to the backend more precisely to the viewstate history.
 
 You will lose viewstates and in the end will run into a viewexpired 
 exception. Hence my two proposals on how to deal with a long running 
 operation either push it out of the jsf domain or simply poll it while 
 it performs in the background.
 
 The Myfaces Queue Control adheres to the spec and does not allow 
 parallel requests, I dont know about the Richfaces queue whether it is 
 more flexible in this area.
 
 
 
 Werner
 
 
 
 Am 23.04.12 03:47, schrieb Paul Rivera:
  Hi Werner,
 
  I would have to agree with Michael.  Doesn't this spec constraint of 
 having ajax calls serialized make one of the best features of ajax 
 ineffective?  
 Assuming that we can manage these requests properly, I think that there is a 
 real advantage of allowing concurrent ajax calls.  Is there any way of 
 configuring the jsf queue to allow this?
 
 
  Best Regards,
  Paul Rivera
 
 
 
  
    From: Werner Punzwerner.p...@gmail.com
  To: users@myfaces.apache.org
  Sent: Friday, 30 March 2012 6:50 PM
  Subject: Re: no parallel ajax requests anymore with JSF 2.1?
 
  Speaking of the spec, there is a reason why the requests are serialized,
  you simply cannot do it without loosing the viewstate over time for the
  long running request. The best bet to workaround this issue is to
  offload the long running request to something outside of JSF
  Servlet/Restful service whatever.
 
  Another solution would be to trigger a short running request which in
  the backend triggers a background operation which you can poll for being
  finished. That would work within the limits of the JSF spec.
 
 
 
  Werner
 
 
 
  Am 30.03.12 08:46, schrieb Michael Heinen:
  Hi Milo,
 
  are you really 100% sure that this is possible with JSF 2.1 and
  Richfaces 4.2?
  Did you verify that the requests are in parallel via logging or 
 breakpoins?
 
  I tried a few combinations of the richfaces queues which were not
  working in parallel.
  Afaik the richfaces queues are on top of the JSF queue.
  Nick Baleavski from Richfaces said this also (07/2011):
  https://community.jboss.org/message/614023#614023
  JSF 2 does not allow parallel AJAX requests, they are all being 
 queued
  and then sent in the serial order.
 
  Another comment from Richfaces discussions, looking for concurrent
  requests: https://community.jboss.org/message/648601#648601
 
 
  For me this seems to be a major regression in JSF!
  It does support jax now but no Ajax!
  Could anybody explain this to me? It worked well with JSF 1.2.
 
  Now I have to start new threads manually in a web container, which I
  really don't like.
  And the migration to another JSF version is again not estimable at all.
 
  vG
  Michael
 
 
 
  Am 29.03.2012 15:45, schrieb Milo van der Zee:
  Hello Michael,
 
  in RichFaces you could add multiple queues and they won't wait 
 for
  eachother.
 
  MAG,
  Milo van der Zee
 
 
  On Thu, 2012-03-29 at 15:30 +0200, Michael Heinen wrote:
  Hi all,
 
  I'm still converting my application (mayfaces, tomahawk and 
 richfaces)
  from JSF 1.2 to 2.1.
 
  Now I noticed that parallel ajax requests are not working at 
 all!
  E.g. a long running request which calculates something and 
 parallel poll
  requests to fetch status or partial results until the first 
 request is
  finished.
 
  I stumbled over Werner's Blog (at
 
 http://werpublogs.blogspot.de/2011/07/apache-myfaces-jsfjs-queue-control.html)
 
  which contains following statement:
  The official spec enforces following behavior: if you 
 submit an Ajax
  post it is either sent directly if no other submit is running 
 or
  enqueued until the running ajax submit has terminated and then 
 the
  submit is issued.
 
  Question:
  Are there any workarounds to allow parallel requests?
  Or do I have to start new threads manually in my backing beans, 
 which I
  really do not like?
 
  Is there something like a migration guide available?
  I read many documents and ppts about JSF 2 but never read 
 anything about
  this new queing so far.
 
  Michael
 
 
 
 
 
 

Re: Problem with CODI/OWB and PrimeFaces 3.2

[Mark Struberg]

If you like to use EL-2.2 then you should switch to tomcat7-maven-plugin 
instead of using jetty. 


With jetty6 you need to exclude quite a few jetty dependencies from your plugin 
to prevent clashes. Jetty7 and 8 have been behaved completely broken at all. We 
now completely switched away to maven7-maven-plugin instead.


jetty6 was great, but 7 and 8 are poor so far

Hope the jetty community gets back to their original quality again in the 
future!

LieGrue,
strub



- Original Message -
 From: Cédric Durmont cdurm...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, April 17, 2012 11:17 AM
 Subject: Re: Problem with CODI/OWB and PrimeFaces 3.2
 
 Hi guys,
 
 I'm having the same error here, but I'm not using OWB nor CODI :
 -MyFaces 2.0.13 (tried several versions : 2.0.5, 2.0.7, 2.0.9, 2.1.3,
 2.1.7. Issue differs slightly with 2.0.5/2.0.7 , but I still get the
 exception)
 -Trinidad 2.0.1
 - jetty 6.1.6 (embedded/standalone), 7.6.2
 - I have el-impl 2.2 in my classpath (groupId org.glassfish.web in my pom.xml)
 
 
 
 (see stack trace below)
 
 
 This is the part of my xhtml page that causes the error (when
 #{beanProduits.contenuArchives } changes from null to not-null, which
 happens in an actionListener during a full jsf cycle) :
 tr:panelTabbed position=both
         c:forEach items=#{beanProduits.contenuArchives } 
 var=contenu
             tr:showDetailItem text=#{contenu.gauche }
                 tr:panelGroupLayout layout=vertical
                     c:forEach items=#{contenu.droite } 
 var=ligne
                         tr:outputText value=#{ligne }/
                     /c:forEach
                 /tr:panelGroupLayout
             /tr:showDetailItem
         /c:forEach
     /tr:panelTabbed
 
 Note that if I reload the page, the error does not show up again
 (well, until the list is set to null then not-null again)
 
 Do you have any idea, or any workaround like the one in OWB ?
 
 Regards,
 Cedric Durmont
 
 ==
 Stack trace :
 
 java.lang.NoClassDefFoundError: javax/el/ValueReference
     at java.lang.Class.getDeclaredMethods0(Native Method)
     at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
     at java.lang.Class.getDeclaredMethod(Class.java:1935)
     at 
 java.io.ObjectStreamClass.getInheritableMethod(ObjectStreamClass.java:1349)
     at java.io.ObjectStreamClass.access$2200(ObjectStreamClass.java:52)
     at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:448)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.io.ObjectStreamClass.init(ObjectStreamClass.java:413)
     at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106)
     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
     at 
 org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.writeExternal(ContextAwareTagValueExpression.java:201)
     at 
 java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
     at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
     at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146)
     at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146)
     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
     at 
 org.apache.myfaces.shared.util.StateUtils.getAsByteArray(StateUtils.java:273)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:851)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
     at 
 org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:414)
     at 
 org.apache.myfaces.view.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:142)
     at 
 org.apache.myfaces.view.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:126)
     at 
 javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:519)
     at javax.faces.component.UIComponent.encodeAll(UIComponent.java:710)
     at 
 org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:624)
     at 
 

Re: Problem with CODI/OWB and PrimeFaces 3.2

[Mark Struberg]

whoops, tomcat7-maven-plugin of course^^

LieGrue,
strub





- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, April 17, 2012 2:40 PM
 Subject: Re: Problem with CODI/OWB and PrimeFaces 3.2
 
 If you like to use EL-2.2 then you should switch to tomcat7-maven-plugin 
 instead 
 of using jetty. 
 
 
 With jetty6 you need to exclude quite a few jetty dependencies from your 
 plugin 
 to prevent clashes. Jetty7 and 8 have been behaved completely broken at all. 
 We 
 now completely switched away to maven7-maven-plugin instead.
 
 
 jetty6 was great, but 7 and 8 are poor so far
 
 Hope the jetty community gets back to their original quality again in the 
 future!
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: Cédric Durmont cdurm...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc: 
  Sent: Tuesday, April 17, 2012 11:17 AM
  Subject: Re: Problem with CODI/OWB and PrimeFaces 3.2
 
  Hi guys,
 
  I'm having the same error here, but I'm not using OWB nor CODI :
  -MyFaces 2.0.13 (tried several versions : 2.0.5, 2.0.7, 2.0.9, 2.1.3,
  2.1.7. Issue differs slightly with 2.0.5/2.0.7 , but I still get the
  exception)
  -Trinidad 2.0.1
  - jetty 6.1.6 (embedded/standalone), 7.6.2
  - I have el-impl 2.2 in my classpath (groupId org.glassfish.web in my 
 pom.xml)
 
 
 
  (see stack trace below)
 
 
  This is the part of my xhtml page that causes the error (when
  #{beanProduits.contenuArchives } changes from null to not-null, which
  happens in an actionListener during a full jsf cycle) :
  tr:panelTabbed position=both
          c:forEach items=#{beanProduits.contenuArchives } 
  var=contenu
              tr:showDetailItem text=#{contenu.gauche }
                  tr:panelGroupLayout layout=vertical
                      c:forEach items=#{contenu.droite } 
  var=ligne
                          tr:outputText value=#{ligne }/
                      /c:forEach
                  /tr:panelGroupLayout
              /tr:showDetailItem
          /c:forEach
      /tr:panelTabbed
 
  Note that if I reload the page, the error does not show up again
  (well, until the list is set to null then not-null again)
 
  Do you have any idea, or any workaround like the one in OWB ?
 
  Regards,
  Cedric Durmont
 
  ==
  Stack trace :
 
  java.lang.NoClassDefFoundError: javax/el/ValueReference
      at java.lang.Class.getDeclaredMethods0(Native Method)
      at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
      at java.lang.Class.getDeclaredMethod(Class.java:1935)
      at 
  java.io.ObjectStreamClass.getInheritableMethod(ObjectStreamClass.java:1349)
      at java.io.ObjectStreamClass.access$2200(ObjectStreamClass.java:52)
      at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:448)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.io.ObjectStreamClass.init(ObjectStreamClass.java:413)
      at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
      at 
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106)
      at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
      at 
 
 org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.writeExternal(ContextAwareTagValueExpression.java:201)
      at 
  java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)
      at 
 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)
      at 
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
      at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338)
      at 
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146)
      at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1338)
      at 
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1146)
      at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
      at 
 
 org.apache.myfaces.shared.util.StateUtils.getAsByteArray(StateUtils.java:273)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:851)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:886)
      at 
 
 org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:414)
      at 
 
 org.apache.myfaces.view.facelets.tag.ui.UIDebug.writeDebugOutput

Re: Ajax update of a composite component within ui:repeat doesn't work

[Mark Struberg]

Hi Leo!

Did you also try the stuff with composite components inside ui:repeat? 

Default components seem to work, but composite components are probably broken.


Buett will upload a sample code later today.

LieGrue,
strub


- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Monday, April 16, 2012 6:32 PM
 Subject: Re: Ajax update of a composite component within ui:repeat doesn't 
 work
 
 Hi
 
 There was two issues solved in 2.1.7 related to ui:repeat:
 
 https://issues.apache.org/jira/browse/MYFACES-3415
 
 [ui:repeat] field value disappears if validation error exists on current site
 
 https://issues.apache.org/jira/browse/MYFACES-3463
 
 Refactor UIRepeat code to implement PSS algorithm like UIData and fix
 state behavior
 
 The code taken from UIData has been already tested and there are some
 junit tests for ui:repeat, so in theory it should work.
 
 regards,
 
 Leonardo Uribe
 
 2012/4/16 Marcus Büttner buettner.mar...@gmail.com:
  Hi,
 
  This following example works with MyFaces 2.1.6 but not with 2.1.7.
 
  mycc.xhtml:
  cc:interface
     cc:attribute name=state 
 type=ExampleModel.State/
  /cc:interface
 
  cc:implementation
     h:selectBooleanCheckbox 
 value=#{cc.attrs.state.state}
         f:ajax execute=@this render=@form/
     /h:selectBooleanCheckbox
     h:outputText value=State: #{cc.attrs.state.state}/
  /cc:implementation
 
 
  example.xhtml:
  h:form id=form
     ui:repeat value=#{example.states} 
 var=state
         my:mycc state=#{state}/
     /ui:repeat
     my:mycc state=#{example.state}/
  /h:form
 
  In debugger I saw the submitted value of the checkbox is set but this state
  is overridden a little bit later by
  UIRepeate#restoreDescendantComponentStates method which is triggered by
  UIRepeat#setIndex which is called by UIRepeat#visitTree.
 
  Any ideas?
 
  Regards,
  Marcus

Re: problem compatibility Myfaces/Spring

[Mark Struberg]

We'd need the full stack trace. But I don't think it is a MyFaces version 
related issue...

LieGrue,
strub



- Original Message -
 From: ayouB __ ayb-2...@hotmail.fr
 To: users@myfaces.apache.org
 Cc: 
 Sent: Friday, April 13, 2012 1:54 PM
 Subject: RE: problem compatibility Myfaces/Spring
 
 
 Hi,
 
 To tell you the truth, i'm using now MyFaces 2.1.5 with Spring 3.0.0 and i 
 got this error while runing my web project into the tomcat 7 server :
 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 ...
 
 i guess it's caused by a compatibilty between MyFaces/Spring, is that the 
 main cause ?!
 
 PS : I can't change any jar relating to Spring Framework, i'm working on 
 an existng web project based on Spring 3.0.0, the war server is aleady build 
 with Spring 3.0.0
 
 Thanks.                           

Re: Problem with CODI/OWB and PrimeFaces 3.2

[Mark Struberg]

Hi!

I think the origin of the problem is easy to fix.

OpenWebBeans is built in a modular fashion. Unlike lots of other EE6 projects 
MyFaces and OWB also try to stay backward compatible with older spec variants. 
But you have to enable this backward compat mode manually because this 
comeshand-in-hand with loosing some functionality!


The error you see comes from EL-2.2. getValueReference() only got introduced 
with EL-2.2 which tomcat6 doesn't provide out of the box.
http://docs.oracle.com/javaee/6/api/javax/el/ValueReference.html

There are now 3 solutions to solve this problem:

1.) OWB comes with EL-2.2 support out of the box. You can switch OWB back to 
use EL-1.0 by just dropping the webbeans-el10 [1] jar into your classpath. 
That's it!

2.) use Apache Tomcat7. Tomcat7 comes with EL-2.2 support.

3.) If you do not need JSPs then you could also use Tomcat6 with an EL-2.2 
library like juel[2]. 2 years ago I wrote a howto for this. The most important 
stuff are the few steps which shows how to pimp your tomcat and the 
org.apache.myfaces.EXPRESSION_FACTORY context-param.


NOTE: If you decide to stay with EL-1.0 then you will miss LOTS of great 
features!. E.g. in dataTables you now can make use of the new EL-2.2 feature to 
pass arguments to a EL expression.

h:outputText value=#{backingBean.getStatus(currentRow)}/


LieGrue,
strub

[1] 
http://repo1.maven.org/maven2/org/apache/openwebbeans/openwebbeans-el10/1.1.3/
[2] http://juel.sourceforge.net/
[3] http://wiki.apache.org/myfaces/HowToEnableEl22


- Original Message -
 From: PÉNET LUDOVIC l.pe...@senat.fr
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, April 6, 2012 9:25 AM
 Subject: Re: Problem with CODI/OWB and PrimeFaces 3.2
 
 
 Gerhard Petracek a écrit :
  hi ludovic,
 
  first of all: welcome @ myfaces!
 
  if you don't need the security integration with tomcat, you can remove
  openwebbeans-tomcat6 and just add the owb listener in the 
 web.xml
      listener
 
 
 listener-classorg.apache.webbeans.servlet.WebBeansConfigurationListener/listener-class
      /listener
 
  if you need the security integration with tomcat, please send the question
  to the owb-user liste [1].
 Hi Gerhard and thank you for your quick reply.
 
 I removed the openwebbeans-tomcat6 package and the corresponding listener
 declaration.
 
 I still have the same problem.
 
 
 Best regards,
 
 Ludovic
 
 
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: OWB Decorators

[Mark Struberg]

Hi Christian!

It is better we move this one over to the openwebbeans-dev list.

LieGrue,
strub




- Original Message -
 From: Christian Beikov c.bei...@curecomp.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Monday, April 2, 2012 6:46 PM
 Subject: OWB Decorators
 
 Hello there!
 
 I have just found out something that really scared me!
 I am using for this example 2 Decorators for one Interface and a simple 
 implementation, like this:
 
 interface Service extends Serializable{
   public Object getSomething(int value);
   public boolean test(String text);
 }
 
 -
 public class MyService implements Service {
 
   /* Used somewhere else to be able to use decorators and interceptors */
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     return false;
   }
 }
 
 -
 @Decorator
 public abstract class ServiceDecoratorA implements Service {
   @Delegate
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     Object o = delegate.getSomething();
 
     if(/*condition*/){
       return true;
     } else {
       return delegate.test(text);
     }
   }
 }
 
 
 @Decorator
 public abstract class ServiceDecoratorB implements Service {
   @Delegate
   @Inject
   private Service delegate;
 
   public boolean test(String text){
     Object o = delegate.getSomething();
 
     if(/*condition*/){
       return true;
     } else {
       return delegate.test(text);
     }
   }
 }
 
 Invocation(Through EL): #{myService.test('aString')}
 Expected Invocation-Chain: 
 OWB-Proxy.test(String)-...-ServiceDecoratorA.test(String)-ServiceDecoratorB.test(String)-MyService.test(String)
 Actual Invocation-Chain: 
 OWB-Proxy.test(String)-...-ServiceDecoratorA.test(String)-MyService.test(String)
 
 When I call the method test(String) decorator A is accessed when the 
 condition 
 evaluates to false I would expect the next decorator to be called, instead 
 MyService.test(String) is called. If I put the expression 
 delegate.test(String) 
 to the first line in the decorator method, temporary put the result in a 
 local 
 var and return the local vars content, everything works as expected.
 
 I think that the invocation of the delegate mixes up a state of the OWB proxy 
 or 
 so. I have no idea about what happens here but it sucks and I think that this 
 behavior is wrong.
 I fixed this problem right now with temporary saving the delegates return 
 into a 
 local var and the do other invocations on the delegate.
 
 Is this a bug or is it not allowed to call other methods than the decorated 
 one 
 in the decorator method?
 
 Regards,
 
 Christian

Re: MyFaces and CODI

[Mark Struberg]

, thanks.
 
  Att,
  Rafael M. Pestano
  Desenvolvedor Java Cia. de Processamento de Dados do 
 Rio Grande do
   Sul
  Graduando em Ciência da Computação UFRGS
  @realpestano
  http://code.google.com/p/jsf-conventions-framework/
 
 
 
  - Mensagem original -
  De: Gerhard Petracek gerhard.petra...@gmail.com
  Para: MyFaces Discussion 
 users@myfaces.apache.org
  Cc:
  Enviadas: Quarta-feira, 14 de Março de 2012 20:11
  Assunto: Re: MyFaces and CODI
 
  hi rafael,
 
  the easiest approach to test an alternative for this 
 constellation
  is
the
  activation of the ServerSideWindowHandler (it's a 
 std. cdi
   @Alternative
  implementation - you can activate it in the 
 beans.xml file of your
  application).
  (however, please be aware that this alternative 
 implementation has
   some
  disadvantages.)
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/3/14 Rafael Pestano rmpest...@yahoo.com.br
 
   Hi Gerhard, i successfuly added codi and 
 openwebbeans to an
application
   running on weblogic 11g
  
   however its a  legacy application which uses 
 frames, basicaly we
have a
   menu on the left frame that targets the center 
 frame, something
   like:
  
   h:commandLink value=menuLink 
 action=#{myBean.init}
 target=frmDados
   /
  
  
   the problem is, when a add CODI to the application 
 and mark
  myBean
   as
   ViewAccessScoped (and thus the windowId starts to 
 be append to
  the
url)
   the above menuLink always open the center frame in 
 a new browser
   tab.
  
   If i remove CODI and set myBean as 
 RequestScoped(or any other CDI
 Scope)
   the application behaves  as expected.
  
   So i think the windowId generated by CODI  is 
 causing this
  issue, i
 tried
   your solution without success, the windowId isnt 
 removed from the
   url
  and a
   new tab opens when i click in the menuLink.
  
   Any thoughs?
  
  
   thanks for all your help.
  
  
  
   Att,
  
   Rafael M. Pestano
  
   Desenvolvedor Java Cia. de Processamento de Dados 
 do Rio Grande
  do
Sul
   Graduando em Ciência da Computação UFRGS
   @realpestano
   
 http://code.google.com/p/jsf-conventions-framework/
  
  
  
   
   De: Gerhard Petracek 
 gerhard.petra...@gmail.com
   Para: MyFaces Discussion 
 users@myfaces.apache.org
   Enviadas: Sexta-feira, 9 de Março de 2012 12:38
   Assunto: Re: MyFaces and CODI
  
   hi stephen,
  
   that's right [1] doesn't support it.
   werner committed his improvement and you can try 
 [2] and [3] as
  you
see
   them right now.
  
   regards,
   gerhard
  
   [1]
 
   http://old.nabble.com/-CODI--lazy-windowId-drop-script-p31654496.html
   [2] http://s.apache.org/rr
   [3] http://s.apache.org/23p
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
   2012/3/9 Stephen More 
 stephen.m...@gmail.com
  
I was referring to [1]
   

  http://old.nabble.com/-CODI--lazy-windowId-drop-script-p31654496.html
   
I guess I just need to wait until the correct 
 way is tested and
documented in the wiki using:
      [1] http://s.apache.org/rr
     [2] http://s.apache.org/23p
   
   
   
On Fri, Mar 9, 2012 at 9:20 AM, Gerhard 
 Petracek
gerhard.petra...@gmail.com wrote:
 @ mark:
 i just tested it and it works with [1] 
 in combination
 with ClientSideWindowHandler [2].

 regards,
 gerhard

 [1] http://s.apache.org/rr
 [2] http://s.apache.org/23p

 http://www.irian.at

 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 2012/3/9 Mark Struberg 
 strub...@yahoo.de

 Hi Stephen!

 Well, the current approach in CODI 
 is currently under
   discussion
 in
   the
 JSF EG. The whole windowId stuff of 
 CODI might end up in the
 JSF-2.2
   or
2.3
 spec.

 T hat seems to work fine when 
 pasting into a new empty
   window,
 but
  it
  still allows you to copy-paste 
 the url from one

Re: MyFaces and CODI

[Mark Struberg]

Gerhard pinged me that you are using @ViewAccessScoped. In that case I'd 
recomment to debug if the whole Context Extension gets properly registrated.

If the CDI container doesn't know the @ViewAccessScoped annotation then all 
your beans will end up as @Dependent...

LieGrue,
strub


- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Sunday, March 18, 2012 7:42 PM
 Subject: Re: MyFaces and CODI
 
  when i find out what's causing my bean to be instantiated on every ajax 
 call 
  i'll come back here to report.
 
 That sounds familiar - good luck ;)
 
 Which scope does your bean have? You are sure that you are really using CDI 
 javax.enterprise.context.* scopes and not javax.faces.bean.* scopes due to a 
 wrong auto-import  of your IDE?
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: Rafael Pestano rmpest...@yahoo.com.br
  To: MyFaces Discussion users@myfaces.apache.org
  Cc: 
  Sent: Saturday, March 17, 2012 4:34 PM
  Subject: Re: MyFaces and CODI
 
  yeap, i also deployed the server side demo in tomcat and it works as 
 expected, 
  when i find out what's causing my bean to be instantiated on every ajax 
 call 
  i'll come back here to report.
 
  many thanks for the assistance.
   
  Att, 
 
  Rafael M. Pestano
 
  Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
  Graduando em Ciência da Computação UFRGS
  @realpestano
  http://code.google.com/p/jsf-conventions-framework/
 
 
 
  
  De: Gerhard Petracek gerhard.petra...@gmail.com
  Para: MyFaces Discussion users@myfaces.apache.org 
  Enviadas: Sexta-feira, 16 de Março de 2012 22:46
  Assunto: Re: MyFaces and CODI
 
  hi rafael,
 
  i can't reproduce it. i added richfaces to the previous demo as well as 
 a4j
  support to the input component and everything works as expected.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/3/15 Rafael Pestano rmpest...@yahoo.com.br
 
   Hi Gehard,
 
   i didnt got the ideia, do you have any example or a link showing this
   approach?
 
   what i have got til now is:
   1 - WindowContextIdHolderComponent is a jsf component which is added
   dynamically to the view
   2 - this component holds the windowId
   3 - i have,somehow , to keep the windowId the same between requests so 
 my
   ViewAccessScoped bean  is keeped alive - here is where 
 im 
  stuck
 
 
 
 
   Att,
   Rafael M. Pestano
   Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
   Graduando em Ciência da Computação UFRGS
   @realpestano
   http://code.google.com/p/jsf-conventions-framework/
 
 
 
   - Mensagem original -
   De: Gerhard Petracek gerhard.petra...@gmail.com
   Para: MyFaces Discussion users@myfaces.apache.org
   Cc:
   Enviadas: Quinta-feira, 15 de Março de 2012 11:28
   Assunto: Re: MyFaces and CODI
 
   hi rafael,
 
   @ WindowContextIdHolderComponent:
 
   that's the name of the class. you have to resolve the component 
 (by 
  type)
   before the view gets rendered and add it to the ajax enabled a4j 
 components
   via the corresponding java-api.
 
   @ custom approach:
   independent of the concrete approach you would like to use, you just 
 have
   to ensure that the information is available on the server-side (for 
 every
   jsf request which starts the jsf request-lifecycle).
 
   regards,
   gerhard
 
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
 
   Professional Support for Apache MyFaces
 
 
   2012/3/15 Rafael Pestano rmpest...@yahoo.com.br
 
    Hi again,
   
    it will work with a4j as soon as you
    ensure that it gets restored for requests triggered by a4j  
 you 
  mean i
    should send WindowContextIdHolderComponent  within the ajax 
 request?
   
    somethink like a4j:support 
  process=WindowContextIdHolderComponent/ ?
   
    if so whats the id of the generated component?
   
    i also have another question, in the javadoc
    of WindowContextConfig isUrlParameterSuported() says
   
    Specifies if it is allowed to use URL params for forwarding 
 the 
  current
    window-id. (deactivate it e.g. for higher security - in this case 
 
  it's
    required to use a window id provided by a component lib or a 
  server-side
    window-handler
   
    how can i create a component to handle the window id? can i do 
 that 
  with
    an h:inputHidden for example?
   
    thanks for the help.
   
   
   
    Att,
   
    Rafael M. Pestano
   
    Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande 
 do Sul
    Graduando em Ciência da Computação UFRGS
    @realpestano
    http://code.google.com/p/jsf-conventions-framework/
   
   
   
    
    De: Gerhard Petracek gerhard.petra...@gmail.com

Re: MyFaces and CODI

[Mark Struberg]

Oops, overlooked that.

In that case I'd say the following things might get checked.

a.) If you get an AJAX request, does the windowId get propagated properly?
Does a CODI @WindowScoped bean show the correct context, or do you loose it 
with each request?

 - windowId gets lost somewhere

b.) If the WindowScoped bean works, then I'd look if the view might gets 
ditched or wrongly touched due to the additional handling in a4j.
You could set a breakpoint in 
ViewAccessConversationExpirationEvaluator#isExpored() to see whether/when the 
bean gets ditched.

LieGrue,
strub


- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Sunday, March 18, 2012 8:47 PM
 Subject: Re: MyFaces and CODI
 
 hi mark,
 
 since rafael mentioned that it works without a4j and there is no issue with
 a4j in the demo, i don't think that it is such a basic issue.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2012/3/18 Mark Struberg strub...@yahoo.de
 
 
 
  Gerhard pinged me that you are using @ViewAccessScoped. In that case 
 I'd
  recomment to debug if the whole Context Extension gets properly 
 registrated.
 
  If the CDI container doesn't know the @ViewAccessScoped annotation then
  all your beans will end up as @Dependent...
 
  LieGrue,
  strub
 
 
  - Original Message -
   From: Mark Struberg strub...@yahoo.de
   To: MyFaces Discussion users@myfaces.apache.org
   Cc:
   Sent: Sunday, March 18, 2012 7:42 PM
   Subject: Re: MyFaces and CODI
  
    when i find out what's causing my bean to be instantiated on 
 every ajax
   call
    i'll come back here to report.
  
   That sounds familiar - good luck ;)
  
   Which scope does your bean have? You are sure that you are really 
 using
  CDI
   javax.enterprise.context.* scopes and not javax.faces.bean.* scopes 
 due
  to a
   wrong auto-import  of your IDE?
  
   LieGrue,
   strub
  
  
  
   - Original Message -
    From: Rafael Pestano rmpest...@yahoo.com.br
    To: MyFaces Discussion users@myfaces.apache.org
    Cc:
    Sent: Saturday, March 17, 2012 4:34 PM
    Subject: Re: MyFaces and CODI
  
    yeap, i also deployed the server side demo in tomcat and it works 
 as
   expected,
    when i find out what's causing my bean to be instantiated on 
 every ajax
   call
    i'll come back here to report.
  
    many thanks for the assistance.
  
    Att,
  
    Rafael M. Pestano
  
    Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande 
 do Sul
    Graduando em Ciência da Computação UFRGS
    @realpestano
    http://code.google.com/p/jsf-conventions-framework/
  
  
  
    
    De: Gerhard Petracek gerhard.petra...@gmail.com
    Para: MyFaces Discussion users@myfaces.apache.org
    Enviadas: Sexta-feira, 16 de Março de 2012 22:46
    Assunto: Re: MyFaces and CODI
  
    hi rafael,
  
    i can't reproduce it. i added richfaces to the previous demo 
 as well as
   a4j
    support to the input component and everything works as expected.
  
    regards,
    gerhard
  
    http://www.irian.at
  
    Your JSF/JavaEE powerhouse -
    JavaEE Consulting, Development and
    Courses in English and German
  
    Professional Support for Apache MyFaces
  
  
  
    2012/3/15 Rafael Pestano rmpest...@yahoo.com.br
  
     Hi Gehard,
  
     i didnt got the ideia, do you have any example or a link 
 showing this
     approach?
  
     what i have got til now is:
     1 - WindowContextIdHolderComponent is a jsf component which 
 is added
     dynamically to the view
     2 - this component holds the windowId
     3 - i have,somehow , to keep the windowId the same between 
 requests
  so
   my
     ViewAccessScoped bean  is keeped alive - 
 here is where
   im
    stuck
  
  
  
  
     Att,
     Rafael M. Pestano
     Desenvolvedor Java Cia. de Processamento de Dados do Rio 
 Grande do
  Sul
     Graduando em Ciência da Computação UFRGS
     @realpestano
    http://code.google.com/p/jsf-conventions-framework/
  
  
  
     - Mensagem original -
     De: Gerhard Petracek gerhard.petra...@gmail.com
     Para: MyFaces Discussion users@myfaces.apache.org
     Cc:
     Enviadas: Quinta-feira, 15 de Março de 2012 11:28
     Assunto: Re: MyFaces and CODI
  
     hi rafael,
  
     @ WindowContextIdHolderComponent:
  
     that's the name of the class. you have to resolve the 
 component
   (by
    type)
     before the view gets rendered and add it to the ajax enabled 
 a4j
   components
     via the corresponding java-api.
  
     @ custom approach:
     independent of the concrete approach you would like to use, 
 you just
   have
     to ensure that the information is available on the 
 server-side (for
   every
     jsf request which starts the jsf request-lifecycle).
  
     regards,
     gerhard

Re: MyFaces and CODI

[Mark Struberg]

(StartModulesFlow.java:27)
         at 
 weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:1267)
         at 
 weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
         at 
 weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:409)
         at 
 weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:39)
         at 
 weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
         at 
 weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
         at 
 weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
         at 
 weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:150)
         at 
 weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:116)
         at 
 weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
         at 
 weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
         at 
 weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
         at 
 weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
         at 
 weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
         at 
 weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCa
 llbackDeliverer.java:181)
         at 
 weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallback
 Deliverer.java:12)
         at 
 weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliv
 erer.java:67)
         at 
 weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
 18/03/2012 17:10:47 com.sun.faces.config.ConfigureListener contextInitialized
  
 thanks for your time.
 
  
 Att, 
 Rafael M. Pestano
 Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
 Graduando em Ciência da Computação UFRGS
 @realpestano
 http://code.google.com/p/jsf-conventions-framework/
 
 
 
 - Mensagem original -
 De: Gerhard Petracek gerhard.petra...@gmail.com
 Para: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Enviadas: Domingo, 18 de Março de 2012 16:47
 Assunto: Re: MyFaces and CODI
 
 hi mark,
 
 since rafael mentioned that it works without a4j and there is no issue with
 a4j in the demo, i don't think that it is such a basic issue.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2012/3/18 Mark Struberg strub...@yahoo.de
 
 
 
  Gerhard pinged me that you are using @ViewAccessScoped. In that case 
 I'd
  recomment to debug if the whole Context Extension gets properly 
 registrated.
 
  If the CDI container doesn't know the @ViewAccessScoped annotation then
  all your beans will end up as @Dependent...
 
  LieGrue,
  strub
 
 
  - Original Message -
   From: Mark Struberg strub...@yahoo.de
   To: MyFaces Discussion users@myfaces.apache.org
   Cc:
   Sent: Sunday, March 18, 2012 7:42 PM
   Subject: Re: MyFaces and CODI
  
    when i find out what's causing my bean to be instantiated on 
 every ajax
   call
    i'll come back here to report.
  
   That sounds familiar - good luck ;)
  
   Which scope does your bean have? You are sure that you are really 
 using
  CDI
   javax.enterprise.context.* scopes and not javax.faces.bean.* scopes 
 due
  to a
   wrong auto-import  of your IDE?
  
   LieGrue,
   strub
  
  
  
   - Original Message -
    From: Rafael Pestano rmpest...@yahoo.com.br
    To: MyFaces Discussion users@myfaces.apache.org
    Cc:
    Sent: Saturday, March 17, 2012 4:34 PM
    Subject: Re: MyFaces and CODI
  
    yeap, i also deployed the server side demo in tomcat and it works 
 as
   expected,
    when i find out what's causing my bean to be instantiated on 
 every ajax
   call
    i'll come back here to report.
  
    many thanks for the assistance.
  
    Att,
  
    Rafael M. Pestano
  
    Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande 
 do Sul
    Graduando em Ciência da Computação UFRGS
    @realpestano
    http://code.google.com/p/jsf-conventions-framework/
  
  
  
    
    De: Gerhard Petracek gerhard.petra...@gmail.com
    Para: MyFaces Discussion users@myfaces.apache.org

Re: [CODI] ThreadScoped / EntityManager in a new Thread

[Mark Struberg]

Hi Thomas!

Well, we had this problem as well in a Quartz scheduler Extension. And this did 
lead to the CdiControl approach implemented in OpenWebBeans Test and now moved 
to DeltaSpike cdise [1]. Please note that this is not yet finished, but will be 
soon!

The functionality is currently in one API but will be split into two interfaces.

The first one provides the control to container-independently start and stop 
the whole container (OWB or Weld) which can be used to boot CDI in a JavaSE 
environment without having any implementation specific code in your project.

The second part (I still need to factor this out) will give you the ability to 
start and stop contexts in respect to the current thread.
This will again be container independent and hides all the complexity from the 
user.

I hope to be able to finish this work on the weekend (I'm currently pretty busy 
at $$dayjob in a C project)

LieGrue,
strub

[1] 
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/cdise/api/src/main/java/org/apache/deltaspike/cdise/api/CdiContainer.java;h=dc8be0b87f4d350ce0539eec2a43590eeb13e88b;hb=HEAD


- Original Message -
 From: Thomas Andraschko zoi...@googlemail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, March 15, 2012 3:08 PM
 Subject: [CODI] ThreadScoped / EntityManager in a new Thread
 
 Hi,
 
 In our webapp, we have an asynchronous XML sender and receiver and we also
 need db access with transactions in this thread.
 Currently, our EntityManager is procuded in RequestScoped and will not work
 in a new thread.
 
 How can i solve this?
 Does any ThreadScoped implementation exists?
 
 Thanks and best regards,
 Thomas
 

Re: [CODI] ThreadScoped / EntityManager in a new Thread

[Mark Struberg]

using a @TransactionScoped EM is possible, but if you already have all your 
Services using a @RequestScoped EM, then you will not come far...

LieGrue,
strub



- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, March 15, 2012 3:32 PM
 Subject: Re: [CODI] ThreadScoped / EntityManager in a new Thread
 
 hi thomas,
 
 see [1] - you just have to switch to v1.0.4
 
 regards,
 gerhard
 
 [1] https://issues.apache.org/jira/browse/EXTCDI-258
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2012/3/15 Thomas Andraschko zoi...@googlemail.com
 
  Hi,
 
  In our webapp, we have an asynchronous XML sender and receiver and we also
  need db access with transactions in this thread.
  Currently, our EntityManager is procuded in RequestScoped and will not work
  in a new thread.
 
  How can i solve this?
  Does any ThreadScoped implementation exists?
 
  Thanks and best regards,
  Thomas
 
 

Re: how to build a JSF 2.0 (MyFaces/Facelets) Project

[Mark Struberg]

Best is to use Maven. 


$ mvn archetype:generate -DarchetypeGroupId=org.apache.myfaces.buildtools 
-DarchetypeArtifactId=myfaces-archetype-helloworld20-owb

LieGrue,
strub



- Original Message -
 From: ayouB __ ayb-2...@hotmail.fr
 To: users@myfaces.apache.org
 Cc: 
 Sent: Wednesday, March 14, 2012 5:47 PM
 Subject: how to build a JSF 2.0 (MyFaces/Facelets) Project
 
 
 Hello every one,
 
 I have sent a mail before that one where i explained problems i faced while 
 configuring the developpement environnement, unfortunately that let me no 
 where 
 i spent a lot of time trying to find a solution but i didn't anyway thank 
 you all for your replies and your collaboration :)
 The problem now is how to create and configure a jsf project under eclipse 
 helios IDE, what JARs i need, how to dowload them and where can i find them, 
 what version, and where should i put them (in my class path, in my web app 
 ...).
 I'm really confused and i don't know what to do ! Please Help ^_^
 
 Thanks. 
 
 AYOUB                           

Re: JSF 1.2: #{object.class.name} not allowed

[Mark Struberg]

Might be permitted due to security reasons?

Just a guess...

LieGrue,
strub



- Original Message -
 From: Milo van der Zee m...@vanderzee.org
 To: users@myfaces.apache.org
 Cc: 
 Sent: Saturday, March 10, 2012 8:12 AM
 Subject: Re: JSF 1.2: #{object.class.name} not allowed
 
 Strange that you get that error in JSF1.2. I only started getting it in
 JSF2.1. There I could replace the .class with .getClass() and all was
 fine again :)
 
 I agree that it is rather odd. I'm looking forward to the reason 
 'why'
 that some of the experts here might now :)
 
 MAG,
 Milo
 
 
 On Fri, 2012-03-09 at 18:11 -0500, Mike Kienenberger wrote:
  I got this error earlier today.
 
  /pages/notAuthorized.xhtml @42,172 value= to access page
  '#{page.unauthorizedPage.class.name}' The identifier [class] 
 is not a
  valid Java identifier as required by section 1.19 of the EL
  specification (Identifier ::= Java language identifier). This check
  can be disabled by setting the system property
  org.apache.el.parser.SKIP_IDENTIFIER_CHECK to true.
 
  It seems rather odd to me that .class is not an allowed EL
  expression component since Object obviously implements getClass().
 
 

Re: MyFaces and CODI

[Mark Struberg]

Hi Stephen!

Well, the current approach in CODI is currently under discussion in the JSF EG. 
The whole windowId stuff of CODI might end up in the JSF-2.2 or 2.3 spec. 

T hat seems to work fine when pasting into a new empty window, but it
 still allows you to copy-paste the url from one codi window to an
 existing codi window.

Nope, because the windowhandler.js script will first check the window.name. And 
if this is empty/doesn't fit the windowId in the URL, then it will reload the 
page with a freshly requested windowId.

LieGrue,
strub




- Original Message -
 From: Stephen More stephen.m...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, March 9, 2012 1:27 PM
 Subject: Re: MyFaces and CODI
 
 Included in the JSF jar is META-INF/resources/javax.faces/jsf.js which
 enables its use by h:outputScript name=jsf.js 
 library=javax.faces
 target=head/
 
 Should windowhandler.js be moved from the examples into a core library
 so that it can be utilized the same way ?
 
 
 
 On Fri, Mar 9, 2012 at 7:10 AM, Gerhard Petracek
 gerhard.petra...@gmail.com wrote:
  hi stephen,
 
  yes - you can add a small js (see e.g. [1]) to support this use-case.
 
  regards,
  gerhard
 
  [1] http://s.apache.org/YTq
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/3/9 Stephen More stephen.m...@gmail.com
 
  Great. I am mainly interested in WindowScoped i.e. every browser tab
  has its own mini-session.
 
  I see that CODI is adding a ?windowId=595 to keep these conversations
  separate. If a user simply copies the url and pastes in a new tab now
  two browser tabs are sharing the same conversation. How can I prevent
  this ? I want to enforce that EVERY browser tab has its own
  conversation. Perhaps a simple error to the user saying 
 Sorry or
  start a new conversation.
 
  -Thanks
 
  On Fri, Mar 9, 2012 at 3:18 AM, Gerhard Petracek
  gerhard.petra...@gmail.com wrote:
   hi stephen,
  
   (that's an issue with the setup of weld and not related to 
 myfaces codi.)
   however, myfaces codi doesn't need this support - if you 
 also don't need
   cdi support for servlets, filters or listeners, you can run the
  application
   without those features.
  
   regards,
   gerhard
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
   2012/3/9 Stephen More stephen.m...@gmail.com
  
   I too am trying to get a simple example working. I have put 
 together
   this project: 
 http://maven-examples.googlecode.com/svn/trunk/jsf-codi/
  
   mvn jetty:run-war   results in
  
   SEVERE: Unable to create JettyWeldInjector. CDI injection will 
 not be
   available in Servlets, Filters or Listeners
  
   What else do I need to get this simple example working ?
  
   -Thanks
  
   On Thu, Mar 8, 2012 at 11:07 AM, Gerhard Petracek
   gerhard.petra...@gmail.com wrote:
hi jose,
   
first of all: welcome @ myfaces!
   
concrete questions are very welcome and we will improve 
 the wiki
  based on
them.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2012/3/8 José Luis Cetina maxtorz...@gmail.com
   
Hi im so excited to start and use MyFaces and CODI 
 but i cant get any
good documentation in fact i only can get 
 like 2 or 3 mini tutorial
   but
they are really incomplete, can somebody recommend me 
 to some
  tutorial
   or
book to start with *CODI *y see this is an excellent 
 extension, im
   moving
from mojarra and CDI to MyFaces and MyFaces 
 extensions, please where
  i
   can
find value information
   
The only URL where i found a little info is this:

 https://cwiki.apache.org/confluence/display/EXTCDI/Index
   
--

 ---
*SCJA. José Luis Cetina*

 ---
   
  
 

Re: CODI+OWB+Scheduler, ContextNotActiveException

[Mark Struberg]

In fact, asynchronous tasks should not even rely on @SessionScoped or 
@RequestScoped because they do not exist outside a servlet request ;)

LieGrue,
strub



- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, February 17, 2012 10:58 AM
 Subject: Re: CODI+OWB+Scheduler, ContextNotActiveException
 
 hi erwin,
 
 first of all: welcome @ myfaces!
 
 for a conversation a window is needed. therefore, the current conversation
 can't be resolved outside of a faces request.
 since it's possible to destroy the window-context at any time, it isn't
 suggested to use such scopes in an asynchronous task at all.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2012/2/17 Bonhold, Erwin erwin.bonh...@atos.net
 
  Hi all,
 
  at first, CDI + CODI is really cool stuff for building a webapp.
 
  1) Our Environment:
  We are using OWB 1.1.3, CODI 1.0.2 on a Tomcat 7 environment with CODI
  @Transactional.
 
  Database Producer:
   @PersistenceContext(unitName = myunit)
   private EntityManager extendedEntityManager;
 
   @Produces
   @ConversationScoped
   @MyQualifier
   public ExtendedEntityManager createExtendedEntityManager() {
   return new ExtendedEntityManager(this.extendedEntityManager);
   }
 
   public void dispose(@Disposes @Siemens ExtendedEntityManager
  extendedEntityManager) {
   if (extendedEntityManager.isOpen()) {
    extendedEntityManager.close();
   }
   }
 
  -DatabaseService which gets above EntityManager injected
  -OtherServices which getting the database Service injected
 
 
  2) The Problem:
  Using Quartz, Seam Cron or the following class, which creates a thread,
  leads into the same problem.
 
  @ApplicationScoped
  public class ApplicationTimer {
 
   @Inject
   private Log log;
 
   @Inject
   private OtherService otherService; // gets databaseService injected,
  databaseService gets EntityManager injected
 
   public void init() {
   log.info(initialize timer thread);
   try {
    otherService.doSomething(); // WORKS in Context of this
  ApplicationScoped bean
   } catch (Exception e) {
    log.error(e);
   }
 
   Thread timer = new Thread() {
    public void run() {
     while (true) {
      log.info(That's the thread);
      try {
       otherService.doSomething(); // EXCEPTION occurs in Child Thread
       Thread.sleep(5000);
      } catch (Exception e) {
       log.error(e);
      }
     }
    }
   };
   timer.start();
   }
  }
 
  An exception
  javax.enterprise.context.ContextNotActiveException: WebBeans context with
  scope type annotation @ConversationScoped does not exist within current
  thread
  occurs
 
  We also tried to start a (javax) Conversation. Leads into the same
  Excpetion with ... a @RequestScoped does not exist.
 
  The child thread is not in context of a web request, we guess the
  EntityManager have to (as descriped in CODI doc).
 
  But how to solve this problem?
  Is there a possibility to create/provide an appropriate context to the
  child thread or to start scheduled services in another way?
 
 
  Best Regards
  Erwin
 

Re: CODI+OWB+Scheduler, ContextNotActiveException

[Mark Struberg]

Hi Manuel!

Asynchronous Servlet requests are a bit different than manually forking a new 
Thread.
Neither OWB nor Weld use asyncSupported atm.

The CDI EG is already discussing this feature and I guess we will add official 
support for it in CDI-1.1.

LieGrue,
strub



- Original Message -
 From: Manuel Hartl manuel.ha...@kobil.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, February 17, 2012 11:40 AM
 Subject: Re: CODI+OWB+Scheduler, ContextNotActiveException
 
 Hi Mark,
 
 i would slightly disagree to that.
 
 i think it should at least be possible to use Request and SessionScope
 during an AsyncContext of servlet api 3. This AsyncContext is somehow
 associated to a specific servlet request and so IMHO Request- and
 Session-Scopes could be provided.
 
 Greetings,
     Manuel.
 
 
  In fact, asynchronous tasks should not even rely on @SessionScoped or 
 @RequestScoped because they do not exist outside a servlet request ;)
 
  LieGrue,
  strub
 
 
 
  - Original Message -
  From: Gerhard Petracek gerhard.petra...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Cc: 
  Sent: Friday, February 17, 2012 10:58 AM
  Subject: Re: CODI+OWB+Scheduler, ContextNotActiveException
 
  hi erwin,
 
  first of all: welcome @ myfaces!
 
  for a conversation a window is needed. therefore, the current 
 conversation
  can't be resolved outside of a faces request.
  since it's possible to destroy the window-context at any time, it 
 isn't
  suggested to use such scopes in an asynchronous task at all.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/2/17 Bonhold, Erwin erwin.bonh...@atos.net
 
   Hi all,
 
   at first, CDI + CODI is really cool stuff for building a webapp.
 
   1) Our Environment:
   We are using OWB 1.1.3, CODI 1.0.2 on a Tomcat 7 environment with 
 CODI
   @Transactional.
 
   Database Producer:
    @PersistenceContext(unitName = myunit)
    private EntityManager extendedEntityManager;
 
    @Produces
    @ConversationScoped
    @MyQualifier
    public ExtendedEntityManager createExtendedEntityManager() {
    return new ExtendedEntityManager(this.extendedEntityManager);
    }
 
    public void dispose(@Disposes @Siemens ExtendedEntityManager
   extendedEntityManager) {
    if (extendedEntityManager.isOpen()) {
     extendedEntityManager.close();
    }
    }
 
   -DatabaseService which gets above EntityManager injected
   -OtherServices which getting the database Service injected
 
 
   2) The Problem:
   Using Quartz, Seam Cron or the following class, which creates a 
 thread,
   leads into the same problem.
 
   @ApplicationScoped
   public class ApplicationTimer {
 
    @Inject
    private Log log;
 
    @Inject
    private OtherService otherService; // gets databaseService 
 injected,
   databaseService gets EntityManager injected
 
    public void init() {
    log.info(initialize timer thread);
    try {
     otherService.doSomething(); // WORKS in Context of this
   ApplicationScoped bean
    } catch (Exception e) {
     log.error(e);
    }
 
    Thread timer = new Thread() {
     public void run() {
      while (true) {
       log.info(That's the thread);
       try {
        otherService.doSomething(); // EXCEPTION occurs in Child 
 Thread
        Thread.sleep(5000);
       } catch (Exception e) {
        log.error(e);
       }
      }
     }
    };
    timer.start();
    }
   }
 
   An exception
   javax.enterprise.context.ContextNotActiveException: WebBeans 
 context with
   scope type annotation @ConversationScoped does not exist within 
 current
   thread
   occurs
 
   We also tried to start a (javax) Conversation. Leads into the same
   Excpetion with ... a @RequestScoped does not exist.
 
   The child thread is not in context of a web request, we guess the
   EntityManager have to (as descriped in CODI doc).
 
   But how to solve this problem?
   Is there a possibility to create/provide an appropriate context to 
 the
   child thread or to start scheduled services in another way?
 
 
   Best Regards
   Erwin
 
 
 
 -- 
 Dipl. Inform. Manuel Hartl
 Software Architect
 
 FlexSecure-Logo    KobilGroup-Logo
 
 FlexSecure GmbH
 Industriestr. 12
 D - 64297 Darmstadt
 Tel: +49 (0) 6151 501 23-18
 Fax: +49 (0) 6151 501 23-19
 
 E-Mail: ha...@flexsecure.de
 Internet: www.flexsecure.de
 
 Geschäftsführer:
 Erwin Stallenberger, Markus Ruppert
 
 Amtsgericht Darmstadt HRB 8036
 Umsatzsteuernummer: DE 214745269

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

[Mark Struberg]

Hi!

 the short answer is: no - it was never intended to support it.
+1

To add a bit more info. This is not even intended/supported by JSF. You would 
need to hit the server for each and every css, img, js, etc served as resource. 
No caching on the browser side would be possible! By default all JSF containers 
I know set the expires to +2 weeks. So even if you would distinguish e.g. the 
language on the resource side, you would only resolve it for the very first 
page hit! All subsequent language changes would be ignored.

Jakob started a more advanced resource handler and a modified version of it is 
also in the myfaces shared project.

http://www.jakobk.com/2011/11/bachelor-thesis-about-relative-resource-handler/

Jakob and Leo are also JSF Expert Group members and are actively pushing this 
in the JSF-2.2 spec.

LieGrue,
strub




- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, February 16, 2012 5:05 PM
 Subject: Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating 
 ValueExpression
 
 hi christian,
 
 the short answer is: no - it was never intended to support it.
 however, if you provide an use-case which isn't supported, we will discuss
 it.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2012/2/16 Christian Beikov c.bei...@curecomp.com
 
  The more concrete question on the problem i face would probably be:
 
  Is the ViewAccessScope designed to work for a JSF ResourceHandler which is
  called instead of the normal JSF Lifecycle? None of the JSF Phases is
  executed when a ResourceHandler is invoked, so would it actually be
  possible that the VIewAccessScope could work?
 
  Resolving a bean within a ResourceHandler is probably not a big thing and
  should not cause problems. Maybe the primefaces implementation is just
  wrong to put the evaluation out of the JSF Phases and should use a
  PhaseListener instead? I am pretty sure that the evaluation would work when
  it was done within a PhaseListener, correct me if I am wrong.
 
  Am 16.02.2012 16:47, schrieb Gerhard Petracek:
 
  hi christian,
 
  a workaround would be an own ConversationFactory - but that means a lot 
 of
  work.
  since the myfaces codi conversation scopes (the view-access scope is 
 just
  a
  special conversation type) are bound to jsf by default, it wasn't 
 intended
  to support access outside of the jsf request-lifecycle.
  however, you can checkout the source-code [1], fix it and check if the
  rest
  would work as needed for your use-case (and provide the patch 
 afterwards).
  or you provide a simple demo which shows the issue and we will do the
  rest.
 
  regards,
  gerhard
 
  [1] 
 https://svn.apache.org/repos/**asf/myfaces/extensions/cdi/**trunk/https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/
 
  http://www.irian.at
 
  Your JSF/JavaEE powerhouse -
  JavaEE Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
 
  2012/2/16 Christian Beikovc.bei...@curecomp.com
 
   Hello there!
 
  I have a problem with the CODI JSF Scope ViewAccessScope and the
  PrimeFaces ResourceHandler.
 
  Primefaces evaluates a value expression within the resource handler 
 to
  retrieve dynamic content, why and how is not important. The fact 
 is, that
  the ResourceHandler is called before everything else within the JSF
  Lifecycle.
 
  I am using the ViewAccessScope for the bean which should be 
 evaluated
  with
  the value expression within the ResourceHandler. I debugged into it 
 and
  found out that 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.**
  conversation.ViewAccessConversationExpirationEvaluator 
 tries to
 
  retrieve the view root of the FacesContext or more exactly the view 
 id of
  it. The problem is, that the view root is null at that time, so the
  evaluation ends with a NullPointerException in a CODI class.
 
  Who is responsible for this issue? Can anyone suggest me a 
 workaround?
 
  I am using:
 
   * Websphere 8.0.0.2
   * MyFaces, the version shipped with Websphere
   * CODI 1.0.1
   * Primefaces 3.1.1
 
  Here is the full stacktrace:
 
  [16.02.12 16:15:51:496 CET] 002a SystemErr     R
  javax.el.ELException:
  Error reading 'companyLogo' on type 
 com.clevercure.web.sob.bean.**
  SobSupplierRegistrationBean_$$_javassist_920
 
  [16.02.12 16:15:51:496 CET] 002a SystemErr     R     at
  javax.el.BeanELResolver.getValue(BeanELResolver.java:93)
 
  [16.02.12 16:15:51:496 CET] 002a SystemErr     R     at
  javax.el.CompositeELResolver.getValue(CompositeELResolver.**
  **java:55)
 
  [16.02.12 16:15:51:496 CET] 002a SystemErr     R     at
  org.apache.myfaces.el.unified.resolver.
  FacesCompositeELResolver.**
  

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

[Mark Struberg]

The problem with the mechanism introduced in JSF-2.0 is to rely on Expression 
Language evaluation for the dynamic parts. But that doesn't perform well so the 
JSF containers serve it with a cache header. Please checkout Jakobs enhanced 
resource handler [1] (especially the Requirements Wiki page) and based on it 
the myfaces-commons-resourcehandler [2] . It's pluggable.
The issue should be fixed in JSF-2.2 (or latest 2.3, not sure if Ed has it on 
the schedule already).

LieGrue,
strub


[1] 
http://www.jakobk.com/2011/11/bachelor-thesis-about-relative-resource-handler
[2] https://cwiki.apache.org/MYFACES/myfaces-commons-resourcehandler.html



- Original Message -
 From: Carlson, John W. carlso...@llnl.gov
 To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: Java Programmers List j...@llnl.gov
 Sent: Thursday, February 16, 2012 10:36 PM
 Subject: RE: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating 
 ValueExpression
 
 Uh, are you guys saying the FacesContext isn't available in a 
 ResourceHandler?  If it's not available, this is a major pain for people 
 with dynamic resource generation.  Essentially, one would have to pass all 
 the 
 necessary information through the URL, or through a non-JSF session.
 
 I realize that static resource generation is more desirable, and that we're 
 moving towards HTML5 with dynamic stuff happening on the browser.
 
 If this is not fixed with JSF2, then I would say my statement about JSF not 
 being suitable for a readonly/downloads application is still valid.

Re: Skip the Validation Phase of JSF with ExtVal

[Mark Struberg]

Hi!

Something I did sometimes is to use an explicit request parameter combined with 
f:validateBean :


f:validateBean disabled=#{!empty param['check']}
  your stuff

and the button looks like the following:


h:commandButton id=personAddBtn action=#{searchForm.startSearch()} 
value=#{amsg.searchPerson}
    f:param name=check value=false/
/h:commandButton



The reason I don't use immediate=true is that this would skip the 'update 
model' step, thus I would loose all the values entered in the fields.
With my solution, it just passes the values, sets it into the model but does no 
validation so far. Of course, on the 'save' button it will be validated.
Please note that this only works when you have some 'stateful' backing beans, 
e.g CDI (see MyFaces CODI) @SessionScoped, @WindowScoped, @ConversationScoped 
or similar Spring contexts (e.g. MyFaces Orchestra Conversations).



LieGrue,
strub




- Original Message -
 From: Rudy De Busscher rdebussc...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, January 19, 2012 12:19 PM
 Subject: Re: Skip the Validation Phase of JSF with ExtVal
 
 Hello Igor,
 
 There exists an add-on that can do that , see (1).  Don't know how well it
 works with Bean validation, probably not due to the missing
 @SkipValidationSupport on bean validation annotations.
 
 Why is immediate=true not an option?  The actionListener on the button is
 still executed (invoke application phase) so you can create a new empty
 instance of the entity for example.
 
 Regards
 Rudy
 
 (1)
 http://os890.blogspot.com/2009/03/myfaces-extval-add-on-bypassvalidation.html
 
 2012/1/19 Igor Guimarães igorcicomp...@gmail.com
 
  Hello,
 
  Extval provide a way to skip of Validation Phase of processor?
 
  A have a button New, that puting a new itens on my list or 
 create a new
  bean, but the property imediate jumping other phasses too 
 (Update Model
  Values and Invoke Application), and its not applicable for me.
 
  Anybody has a idea?
 
  I will try extends class BeanValidator for check this on method validate,
  but I wanna do this more simple.
 
  Thanks.
 
 
  --
  Igor Luiz Vieira Guimarães
 
 
 
 
 -- 
 Rudy De Busscher
 http://www.c4j.be

Re: Getting Spring beans from CODI bean

[Mark Struberg]

Hi!

Check out the CDISource project

https://github.com/cdisource

It allows to @Inject CDI beans into Spring beans and the other way around.

LieGrue,
strub



- Original Message -
 From: Jiayun jia...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, January 12, 2012 12:53 PM
 Subject: Getting Spring beans from CODI bean
 
 Hi,
 
 Is there any recommended way to get Spring beans from CODI bean?
 
 
 regards,
 jiayun
 

Re: Weird PlexusContainer object in ViewRoot

[Mark Struberg]

MyFaces is faster, but I didn't think that Mojarra is so slow ^^.
Our fat pages (~2000 lines in a complex h:dataTable - more than 300.000 
ELResolver invocations) use to take up to 350ms. Small pages render in 17ms on 
our Server with OWB and MyFaces.

I once tested the fat pages with Glassfish and didn't came under 5 seconds. But 
this was quite some time ago when Weld used to be much slower (we now gave them 
a few hints on performance improvements in the meantme) and the Sun EL impl had 
some serious performance hogs.


Is your test page setup freely available? You might share your findings with 
the Mojarra team. They might be interested to check where they have problematic 
spots.

LieGrue,
strub


- Original Message -
 From: Thomas Andraschko zoi...@googlemail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Saturday, December 31, 2011 4:21 AM
 Subject: Re: Weird PlexusContainer object in ViewRoot
 
 Hi,
 
 so i just did some final tests and these are the result with MyFaces and a
 simple test page.
 The values are not really accurate, i just tested in on my locale system
 with firebug for around 10-15 times.
 
 AJAX PostBacks (Production):
 Before: 32-52ms
 After: 23-37ms
 
 PostBack (Production):
 Before: 27ms
 After: 12ms
 
 The same page with Mojarra:
 
 AJAX PostBacks (Production):
 Before: 148-196ms
 After: 26-50ms
 
 PostBack (Production):
 Before: 140-170ms
 After: 15-27ms
 
 Also if the values are not really accurate, is MyFaces really that much
 faster?
 
 You said that you use a simliar plugin for stateless views.
 How does your plugin work? Some details would be great :)
 
 Best regards
 Thomas
 
 2011/12/30 Thomas Andraschko zoi...@googlemail.com
 
  Hi,
 
  yep, thanks!
  I completly redeveloped it (i also contributed the new code back) and i
  just test it but the improvement is similar - it's much faster!
  I can post the detail later :)
 
 
 
  2011/12/30 Martin Koci martin.kocicak.k...@gmail.com
 
  Hi,
 
  do you mean non-static logger in myfaces UIViewRoot ? That is probably
  problem [1] - I must solve it finally.
 
  I checked quickly statelessjsf - we use similar solution in some jsf
  project - completely stateless views.
 
  Which improvement do you see with myfaces + statelessjsf? The blog [2]
  shows at the first picture time 98ms vs. 7ms : 90% improvement: did you
  get similar results with myfaces?
 
  Regards,
 
  Kočičák
 
  [1] https://issues.apache.org/jira/browse/MYFACES-3266
  [2]
 
 
 http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/
 
  Thomas Andraschko píše v Pá 30. 12. 2011 v 12:43 +0100:
   Hi,
  
   thanks for you answer :)
   Jap, i deploy it with jetty:run.
   I already found the issue, somehow this objects are stored in the
  Logger.
   I changed the code that the logger will be removed before cloning 
 the
   ViewRoot.
   Now it also works with MyFaces :)
  
   Thomas
  
   2011/12/30 Martin Koci martin.kocicak.k...@gmail.com
  
Hi,
   
Plexus container is a IoC container used by Maven, so this 
 must be
bug/feature in maven jetty plugin in combination with 
 statelessjsf. Do
you deploy it with mvn jetty:run?
   
Regards,
   
Kočičák
   
Thomas Andraschko píše v Út 27. 12. 2011 v 15:00 +0100:
 Hi,

 i'm trying to use the statelessjsf addon (It's a 
 addon developed by
 industrieit from rudy but the link is currently offline) 
 for my
 application. In a basic sample application it works with 
 myfaces
  (with
some
 modification) and mojarra.
 Somehow in my real project, i get an exception when the 
 addon is
  trying
to
 clone the viewroot:

 java.lang.IllegalArgumentException: Can not set
 org.codehaus.plexus.PlexusContainer field

  org.codehaus.plexus.archiver.manager.DefaultArchiverManager.container 
 to
 
 org.codehaus.plexus.archiver.manager.DefaultArchiverManager
     at

   
 
 sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
     at

   
 
 sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
     at

   
 
 sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
     at

   
 
 sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)

 This does only occur if i run the application within 
 maven and
  jetty. On
 Tomcat, no exception occurs.
 Where does this Plexus stuff come from? Why is it in the 
 view root?

 Thanks and best regards
 Thomas
   
   
   
 
 
 
 

Re: CODI on WebLogic 12c

[Mark Struberg]

yup, looks like the modularity bug Glassfish had as well. This got fixed by a 
new Weld version + some hacks in the integration code. 


For Glassfish it works if you unpack all your CDI dependencies to 
WEB-INF/classes and merge all the beans.xmls into WEB-INF/beans.xml


LieGrue,
strub



- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: arun.gu...@gmail.com
 Sent: Friday, December 30, 2011 4:38 AM
 Subject: Re: CODI on WebLogic 12c
 
 hi,
 
 ok - thx for the info. i'll file an issue for the first part.
 
 the current issue sounds quite similar to a glassfish/weld integration
 issue we saw months ago.
 
 as you see in the log it doesn't make sense because the bean exists already:
 
 ...
 config implementation:
 org.apache.myfaces.extensions.cdi.core.api.config.CodiCoreConfig$Proxy$_$$_WeldClientProxy
 config implementation:
 org.apache.myfaces.extensions.cdi.core.api.config.CodiCoreConfig
 ...
 
 a portable cdi extension like myfaces codi can't provide a fix btw.
 workaround for it.
 (in some cases it helped to copy the content of the beans.xml to the
 beans.xml of the project.)
 
 however, please contact the wls team and report this issue.
 
 regards,
 gerhard
 
 
 
 2011/12/30 Jiayun jia...@gmail.com
 
  It seems ok on startup with v1.0.1, but I got this exception when browse
  the page:
 
 
  2011/12/30 上午10時53分41秒 TST Notice StdErr 
 BEA-00 十二月 30, 2011
  10:53:41 上午
  org.apache.myfaces.extensions.cdi.core.api.provider.ServiceProvider
  clinit
  資訊:
  org.apache.myfaces.extensions.cdi.core.impl.provider.DefaultServiceProvider
  installed successfully.
  2011/12/30 上午10時53分41秒 TST Notice StdErr 
 BEA-00 十二月 30, 2011
  10:53:41 上午
  org.apache.myfaces.extensions.cdi.core.api.provider.ServiceProvider
  clinit
  資訊:
 
 
 org.apache.myfaces.extensions.cdi.core.impl.provider.DefaultServiceProviderContext
  installed successfully.
  2011/12/30 上午10時53分42秒 TST Notice StdErr 
 BEA-00 十二月 30, 2011
  10:53:42 上午
 
 
 org.apache.myfaces.extensions.cdi.core.impl.projectstage.ProjectStageProducer
  initProjectStage
  資訊: Computed the following CODI ProjectStage: Production
  2011/12/30 上午10時53分49秒 TST Notice LoggingService 
 BEA-320400 The
  log file
 
 
 E:\Oracle1211\Middleware\user_projects\domains\base_domain\servers\AdminServer\logs\base_domain.log
  will be rotated. Reopen the log file if tailing has stopped. This can
  happen on some platforms, such as Windows.
  2011/12/30 上午10時53分49秒 TST Notice LoggingService 
 BEA-320401 The
  log file has been rotated to
 
 
 E:\Oracle1211\Middleware\user_projects\domains\base_domain\servers\AdminServer\logs\base_domain.log00036.
  Log messages will continue to be logged in
 
 
 E:\Oracle1211\Middleware\user_projects\domains\base_domain\servers\AdminServer\logs\base_domain.log.
  2011/12/30 上午10時53分49秒 TST Notice Log Management 
 BEA-170027 The
  server has successfully established a connection with the Domain level
  Diagnostic Service.
  2011/12/30 上午10時53分49秒 TST Notice WebLogicServer 
 BEA-000365 Server
  state changed to ADMIN.
  2011/12/30 上午10時53分49秒 TST Notice WebLogicServer 
 BEA-000365 Server
  state changed to RESUMING.
  2011/12/30 上午10時53分49秒 TST Warning Server 
 BEA-002611 The hostname
  0907234PC01.iead.local, maps to multiple IP addresses: 
 192.168.9.100,
  192.168.56.1, 192.168.169.1, 192.168.177.1,
  fe80:0:0:0:744a:ff59:279d:dba0%10, fe80:0:0:0:c13c:e868:7bc5:a81b%16,
  fe80:0:0:0:14ca:5a87:7e96:d888%17, fe80:0:0:0:f429:1d11:fce1:660f%19.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[1] is now listening on 192.168.169.1:7001 for protocols 
 iiop,
  t3,
  ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[9] is now listening on fe80:0:0:0:0:100:7f:fffe:7001 
 for
  protocols iiop, t3, ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[14] is now listening on 127.0.0.1:7001 for protocols 
 iiop, t3,
  ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default is now listening on 192.168.177.1:7001 for protocols 
 iiop, t3,
  ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[4] is now listening on fe80:0:0:0:0:5efe:c0a8:b101:7001 
 for
  protocols iiop, t3, ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[11] is now listening on fe80:0:0:0:0:5efe:c0a8:964:7001 
 for
  protocols iiop, t3, ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[7] is now listening on 
 fe80:0:0:0:14ca:5a87:7e96:d888:7001 for
  protocols iiop, t3, ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[3] is now listening on 192.168.9.100:7001 for protocols 
 iiop,
  t3,
  ldap, snmp, http.
  2011/12/30 上午10時53分49秒 TST Notice Server 
 BEA-002613 Channel
  Default[12] is now 

Re: How to troubleshoot ViewExpiredException ?

[Mark Struberg]

Another problem can be when being on a Cluster, having ServerSideStateSaving 
enabled and session affinity and/or propagation doesn't work properly.
Because the ViewState is stored in the Session in this case...


LieGrue,
strub



- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Thursday, December 29, 2011 10:49 PM
 Subject: Re: How to troubleshoot ViewExpiredException ?
 
 Not really, the ViewExpired exception just means that
 the current ViewState cannot be found anymore in the view history.
 If you navigate
 to a new page, you basically get a Tabula Rasa aka a new
 ViewState.
 
 Either way if it is the JSF Ajax problem, the javascript workaround
 definitely will fix your issue.
 
 
 Werner
 
 
 Am 29.12.11 22:31, schrieb Rohit Kelapure:
 
  Once this ViewExpiredException occurs does it affect other pages that do
  NOT have multiple forms ?
 
  --Thanks,
  Rohit
 
  On Wed, Dec 28, 2011 at 4:55 PM, Werner Punzwerner.p...@gmail.com  
 wrote:
 
  Do you use multiple forms in conjunction with JSF ajax?
 
  Werner
 
 
  Am 28.12.11 18:30, schrieb Rohit Kelapure:
 
  Dear all,
 
  We have run into an issue with our application in production 
 wherein once
  a
  database rollback occurs, our application state somehow gets messed 
 and we
  repeatedly keep seeing ViewExpiredExceptions like so ...
 
  [12/24/11 3:51:52:301 EST] 03b3 SystemErr     R
  javax.faces.application.**ViewExpiredException: /showItem.xhtml No 
 saved
  view
  state could be found for the view identifier: /showItem.xhtmlnull
  [12/24/11 3:51:52:302 EST] 03b3 SystemErr     R   at
  org.apache.myfaces.lifecycle.**RestoreViewExecutor.execute(**
  RestoreViewExecutor.java:128)**null
  [12/24/11 3:51:52:302 EST] 03b3 SystemErr     R   at
  org.apache.myfaces.lifecycle.**LifecycleImpl.executePhase(**
  LifecycleImpl.java:171)null
  [12/24/11 3:51:52:302 EST] 03b3 SystemErr     R   at
  org.apache.myfaces.lifecycle.**LifecycleImpl.execute(**
  LifecycleImpl.java:118)null
 
  Caused by: javax.faces.application.**ViewExpiredException:
  /showShoppingCart.xhtml No saved view state could be found for the 
 view
  identifier: /showShoppingCart.xhtml
  at
  org.apache.myfaces.lifecycle.**RestoreViewExecutor.execute(**
  RestoreViewExecutor.java:128)
  at
  org.apache.myfaces.lifecycle.**LifecycleImpl.executePhase(**
  LifecycleImpl.java:171)
  at
  org.apache.myfaces.lifecycle.**LifecycleImpl.execute(**
  LifecycleImpl.java:118)
  at com.ibm.faces20.portlet.**FacesPortlet.processAction(**
  FacesPortlet.java:238)
 
  This happens for ALL the JSF  facelets *.xhtml files in our 
 application.
  This is a JSF 2 application.
 
  What is the next step in debugging these ViewExpiredExceptions ?
  For starters I have enabled the trace *
    *=info:org.apache.myfaces.**lifecycle*=all*
  *
 
  *
  All your tips are appreciated.
 
  --Thanks,
  Rohit Kelapure
 
 
 
 
 

Re: JVM optimized memory setting for server

[Mark Struberg]

and please don't give more than 1,6 GB if using a 32 bit JVM!
The more ram you give, the less threads you can spawn on 32 bit JVMs!
This was so bad, that we couldn't even get 100 parallel threads when going near 
1.8GB ;)

I hope not many people need to deal with this stuff nowadays anymore though :)

LieGrue,
strub



- Original Message -
 From: Stephen Connolly stephen.alan.conno...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Monday, December 19, 2011 9:11 PM
 Subject: Re: JVM optimized memory setting for server
 
 if the server us dedicated and has 8gb of ram... you could give 6gb (or 3g
 if a 32bit os as more will nor be used on 32bit os)... BUT when the stop
 the world big Garbage Collection triggers (and it will trigger eventually
 as the last resort to resolve heap fragmentation) then that gc will be 6
 times longer... if your app response time is important then giving more
 memory could cause more of a problem.
 
 - Stephen
 
 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 19 Dec 2011 20:01, Jim May jim.webg...@gmail.com wrote:
 
  I have been doing some research on this topic and I know that there is
  quite a bit of information out there. Unfortunately, I usually do not
  notice articles that recommend JVM tuning setting for servers with X amount
  of memory. I have an issue with a production tomcat server that is running
  two applications. One of the applications has an export all records feature
  AS AN OPTION. The default is export only the 100 rows on the page, but
  sometimes the Admin needs to go to the site and export all records into
  excel for their reporting. Now the admin is triggering the export all
  feature and the server is imploding with out of memory errors for the heap.
 
  This is the current settings:
 
  -Xms256m -Xmx1024m -XX:MaxPermSize=384m -XX:PermSize=256m
 
  I was wondering what you would recommend for JVM tuning settings on a
  server that has 8GB or higher of memory? Are there rules that are usually
  followed in deciding the settings? The server is completely dedicated to
  the two websites and the database runs on a different server.
 
  Thanks,
  --
  James
 
 

Re: JSF2: Behavior change for ui:params

[Mark Struberg]

this is a pretty common problem. How does Mojarra (as RI) behave in such 
situations?

LieGrue,
strub



- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, December 15, 2011 6:15 PM
 Subject: Re: JSF2: Behavior change for ui:params
 
 Hi
 
 Yes, I know, but note the current behavior is the most desirable
 because it prevents
 a lot of side effects (including the ones described on MYFACES-2753 and 
 others)
 and is the closest one with the spec.
 
 regards,
 
 Leonardo Uribe
 

Re: @Inject'ed protected base class member access problem

[Mark Struberg]

+1

It seems the Weld version shipping with Glassfish has quite a few problems with 
any 3-rd party scopes. Not only with CODI but generally with other non-spec 
scopes as well.
E.g. a colleague experienced a complete crash when intercepting 3-rd party 
scoped beans.
Not sure if this still applies to the latest Weld version - but we will pretty 
soon unravel those issues in DeltaSpike I hope.


LieGrue,
strub



- Original Message -
 From: Gerhard Petracek gpetra...@apache.org
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Saturday, December 10, 2011 11:10 PM
 Subject: Re: @Inject'ed protected base class member access problem
 
 hi,
 
 please send the same mail to the weld community. codi doesn't perform the
 injection itself.
 
 thx  regards,
 gerhard
 
 
 
 2011/12/10 oversteer brendanhealey...@yahoo.co.uk
 
 
  In the following code I'm trying to inject a SessionScoped bean into a
  stateless EJB, but I want to do the @Inject in an abstract base class of
  the
  EJB. According to the CDI spec it seems to suggest that this should work:
 
  4.2. Inheritance of member-level metadata
 
  Suppose a class X is extended directly or indirectly by the bean class of a
  managed bean or session bean Y.
 
  If X declares an injected field x then Y inherits x.
 
  What happens is that I can access the inherited protected member
  sessionView
  from TestEjb, but not from code within the base class. When I say can
  access, I mean that the injected member is accessible at runtime and 
 is
  not
  null.
 
  @Named
  @ViewAccessScoped
  public class JsfBean extends implements Serializable {
   @Inject private TestEjb ejb;
 
   SessionView s1 = ejb.getSessionViewChild();  // sessionView injected ok
   SessionView s2 = ejb.getSessionViewBase();  // s2 is null
  }
 
  @Named
  @SessionScoped
  public class SessionView implements Serializable {}
 
  @Stateless
  public class TestEjb extends BaseClass implements Serializable {
 
   public SessionView getSessionViewChild() {
     return sessionView;
   }
  }
 
  public abstract class BaseClass implements Serializable {
     @Inject
     protected SessionView sessionView;
 
     public SessionView getSessionViewBase() {
       return sessionView;
   }
  }
 
  What happens is that s1 is a valid SessionView reference, but s2 is null.
  It
  now turns out that if I change the access of sessionView in BaseClass to
  private, it works, but only if I clean  build before re-deployment. It
  will
  then consistently work - unless I change it back to protected, in which
  case
  it will consistently not work.
 
  I am using MyFaces CODI 1.0.1 in conjunction with Weld from Glassfish 3.1.1
  (v20110404-1554). I am also using JDK 7u1. I'm not really sure what 
 could
  be
  causing this, weld, codi, jdk7??
 
  Thanks.
  --
  View this message in context:
 
 http://old.nabble.com/%40Inject%27ed-protected-base-class-member-access-problem-tp32952025p32952025.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 

Re: CODI - turn off startup config logging?

[Mark Struberg]

In glassfish the best solution is to just use mvn 
dependency:unpack-dependencies into your target/classes before building the war.

Then exclude all jars from WEB-INF/lib. 

See
https://issues.jboss.org/browse/CDI-18
and other issues with BDAs.

LieGrue,
strub



- Original Message -
 From: Gerhard Petracek gerhard.petra...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, December 2, 2011 8:16 PM
 Subject: Re: CODI - turn off startup config logging?
 
 esp. for weld we have the alternative implementation modules. you can use
 them to provide custom implementations (e.g. [1] and [2]) or you are using
 the alternative config modules which use btw. need the alternative
 implementation modules (- you can use something like [3]).
 
 regards,
 gerhard
 
 [1]
 https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/alternative-modules/alternative-configuration-modules/core-alternative-configuration-module/src/main/java/org/apache/myfaces/extensions/cdi/core/alternative/config/AlternativeCodiCoreConfig.java
 [2]
 https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/alternative-modules/alternative-configuration-modules/core-alternative-configuration-module/src/main/resources/META-INF/services/org.apache.myfaces.extensions.cdi.core.api.config.CodiConfig
 [3]
 https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/alternative-modules/alternative-configuration-modules/core-alternative-configuration-module/src/test/resources/myfaces-extcdi.properties
 
 http://www.irian.at
 
 Your JSF/JavaEE powerhouse -
 JavaEE Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 2011/12/2 oversteer brendanhealey...@yahoo.co.uk
 
 
  Gerhard, I'm a glassfish 3.1.1 user, so stuck with weld. I tried
  @Specializes
  with no luck. Maybe
  I need to stick with the logging!
 
 
  Gerhard Petracek wrote:
  
   hi,
  
   that depends on your environment (in combination with owb it's 
 easy [1]
   and
   in combination with weld it's more complex and depends on the 
 version you
   have to use) - see [2].
  
   regards,
   gerhard
  
   [1] http://goo.gl/zsFfe
   [2]
  
 
 https://cwiki.apache.org/confluence/display/EXTCDI/Alternative+Configuration
  
   http://www.irian.at
  
   Your JSF/JavaEE powerhouse -
   JavaEE Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
   2011/12/2 oversteer brendanhealey...@yahoo.co.uk
  
  
   I'm afraid I'm non the wiser for this - do I extend 
 CodeCoreConfig and
   override the function? If so
   does this need to be in an @ApplicationScoped bean? Do I need any 
 other
   annotations like @Enhanced
   or @Advanced? is there anything else I need to do to ensure that 
 the
   overridden method is called on
   startup? What would be really great is an example.
  
   Thanks.
  
  
   Gerhard Petracek wrote:
   
hi,
   
see CodiCoreConfig#isConfigurationLoggingEnabled
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
   
2011/12/1 oversteer brendanhealey...@yahoo.co.uk
   
   
   
Hi, can anyone tell me how to lose this from my server 
 log? I
  couldn't
see
anything in the
docs.
   
Used JSF implementation: Mojarra v2.1.3-FCS
config implementation:

 org.apache.myfaces.extensions.cdi.jsf.api.config.JsfModuleConfig
      method:      isUseViewConfigsAsNavigationCasesEnabled
      value:       true
      method:      
 isInvalidValueAwareMessageInterpolatorEnabled
      value:       true
      method:      isInitialRedirectEnabled
      value:       true
      method:      isAlwaysKeepMessages
      value:       true
      ...
   
Thanks.
--
View this message in context:
   
  
 
 http://old.nabble.com/CODI---turn-off-startup-config-logging--tp32898132p32898132.html
Sent from the MyFaces - Users mailing list archive at 
 Nabble.com.
   
   
   
   
  
   --
   View this message in context:
  
 
 http://old.nabble.com/CODI---turn-off-startup-config-logging--tp32898132p32904085.html
   Sent from the MyFaces - Users mailing list archive at Nabble.com.
  
  
  
  
 
  --
  View this message in context:
 
 http://old.nabble.com/CODI---turn-off-startup-config-logging--tp32898132p32904409.html
  Sent from the MyFaces - Users mailing list archive at Nabble.com.
 
 

Re: IBM RAD with JUnit and AbstractCdiAwareTest

[Mark Struberg]

Hi Christian!

Since you added all WebSphere-8.0 libs you don't need the openwebbeans-* jars 
(WS includes them already).

Btw, the myfaces-extcdi-test was developed to perform quick standalone tests. 

For testing a full EE server you might better use Arquillian. 

I'm not sure if there is already a final arquillian-connector for WS-8 but it's 
at least work in progress [1].

There is of course one for openwebbeans standalone too.


LieGrue,
strub


[1] http://community.jboss.org/message/559002



- Original Message -
 From: Christian Beikov c.bei...@curecomp.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Thursday, November 24, 2011 1:01 PM
 Subject: IBM RAD with JUnit and AbstractCdiAwareTest
 
 Hello!
 
 I finally got myself to try out the JUnit-CDI tests but the actual result is 
 dissappointing. I added the following libraries to the build path of a 
 project:
 
 myfaces-extcdi-base-test-infrastructure-1.0.1.jar
 myfaces-extcdi-bundle-jsf20-1.0.1.jar
 myfaces-extcdi-cargo-support-module-1.0.1.jar
 myfaces-extcdi-jsf-support-module-1.0.1.jar
 myfaces-extcdi-junit-support-module-1.0.1.jar
 myfaces-extcdi-owb-support-module-1.0.1.jar
 myfaces-test20-1.0.4.jar
 openwebbeans-impl-1.1.2.jar
 openwebbeans-spi-1.1.2.jar
 
 and also the Websphere 8.0 libs.
 My first test case is minimal:
 
 @RunWith(JUnit4.class)
 public class CoreExceptionHandlerTest extends 
 org.apache.myfaces.extensions.cdi.test.junit4.AbstractCdiAwareTest{
 
     @Inject
     private CoreExceptionHandlerTestBean bean;
 
     @Test
     public void testCoreExceptionHandler() {
         try {
             bean.provokeException();
         } catch (Exception e) {
             fail();
         }
     }
 }
 
 When i try to run it, I get the following Exception:
 
 java.lang.NullPointerException
     at 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.isServletContextAwareContainer(TestContainerFactory.java:142)
     at 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.getNewCdiTestContainer(TestContainerFactory.java:120)
     at 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.createTestContainer(TestContainerFactory.java:56)
     at 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.before(AbstractCdiAwareTestStrategy.java:73)
     at 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.beforeMethod(AbstractCdiAwareTestStrategy.java:44)
     at 
 org.apache.myfaces.extensions.cdi.test.junit4.AbstractCdiAwareTest.beforeMethod(AbstractCdiAwareTest.java:37)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
     at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
     at java.lang.reflect.Method.invoke(Method.java:611)
     at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
     at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
     at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
     at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
     at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
     at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
     at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
     at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
     at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
     at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
     at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
     at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
     at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
     at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
 
 java.lang.NullPointerException
     at 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.after(AbstractCdiAwareTestStrategy.java:87)
     at 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.afterMethod(AbstractCdiAwareTestStrategy.java:54)
     at 
 org.apache.myfaces.extensions.cdi.test.junit4.AbstractCdiAwareTest.afterMethod(AbstractCdiAwareTest.java:47)
     at 

Re: IBM RAD with JUnit and AbstractCdiAwareTest

[Mark Struberg]

One of the reasons why you will get a NPE is because the openwebbeans version 
shipped with WAS is customized and integrates much deeper with the EJB 
container, JPA, JMX etc shipping with WAS. OpenWebBeans provides a lot of SPIs 
to extend it's features. And in WAS there are a lot owb-plugins being used to 
integrate with other WAS features. 


But myfaces-test only boots the 'core' thus many of the registered owb-plugins 
will fail to boot this way. 

Maybe any of the folks close to IBM or any other WAS user can help with the 
Arquillian setup?

Btw, maven is really easy if you use the right archetype ;)


LieGrue,
strub



- Original Message -
 From: Christian Beikov c.bei...@curecomp.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Thursday, November 24, 2011 1:45 PM
 Subject: Re: IBM RAD with JUnit and AbstractCdiAwareTest
 
 I already tried to get Arquillian to work but it seems to be very hard 
 to get it working in IBM RAD without maven.
 Just right now I am trying to get all libs I need to successfully run a 
 test, but as I said, without maven it's a pain...
 
 I still don't understand why these CdiAware tests throw a NPE...
 
 Regards,
 Christian
 
 Am 24.11.2011 13:17, schrieb Mark Struberg:
  Hi Christian!
 
  Since you added all WebSphere-8.0 libs you don't need the 
 openwebbeans-* jars (WS includes them already).
 
  Btw, the myfaces-extcdi-test was developed to perform quick standalone 
 tests.
 
  For testing a full EE server you might better use Arquillian.
 
  I'm not sure if there is already a final arquillian-connector for WS-8 
 but it's at least work in progress [1].
 
  There is of course one for openwebbeans standalone too.
 
 
  LieGrue,
  strub
 
 
  [1] http://community.jboss.org/message/559002
 
 
 
  - Original Message -
  From: Christian Beikovc.bei...@curecomp.com
  To: users@myfaces.apache.org
  Cc:
  Sent: Thursday, November 24, 2011 1:01 PM
  Subject: IBM RAD with JUnit and AbstractCdiAwareTest
 
  Hello!
 
  I finally got myself to try out the JUnit-CDI tests but the actual 
 result is
  dissappointing. I added the following libraries to the build path of a 
 project:
 
  myfaces-extcdi-base-test-infrastructure-1.0.1.jar
  myfaces-extcdi-bundle-jsf20-1.0.1.jar
  myfaces-extcdi-cargo-support-module-1.0.1.jar
  myfaces-extcdi-jsf-support-module-1.0.1.jar
  myfaces-extcdi-junit-support-module-1.0.1.jar
  myfaces-extcdi-owb-support-module-1.0.1.jar
  myfaces-test20-1.0.4.jar
  openwebbeans-impl-1.1.2.jar
  openwebbeans-spi-1.1.2.jar
 
  and also the Websphere 8.0 libs.
  My first test case is minimal:
 
  @RunWith(JUnit4.class)
  public class CoreExceptionHandlerTest extends
  org.apache.myfaces.extensions.cdi.test.junit4.AbstractCdiAwareTest{
 
       @Inject
       private CoreExceptionHandlerTestBean bean;
 
       @Test
       public void testCoreExceptionHandler() {
           try {
               bean.provokeException();
           } catch (Exception e) {
               fail();
           }
       }
  }
 
  When i try to run it, I get the following Exception:
 
  java.lang.NullPointerException
       at
 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.isServletContextAwareContainer(TestContainerFactory.java:142)
       at
 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.getNewCdiTestContainer(TestContainerFactory.java:120)
       at
 
 org.apache.myfaces.extensions.cdi.test.TestContainerFactory.createTestContainer(TestContainerFactory.java:56)
       at
 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.before(AbstractCdiAwareTestStrategy.java:73)
       at
 
 org.apache.myfaces.extensions.cdi.test.strategy.AbstractCdiAwareTestStrategy.beforeMethod(AbstractCdiAwareTestStrategy.java:44)
       at
 
 org.apache.myfaces.extensions.cdi.test.junit4.AbstractCdiAwareTest.beforeMethod(AbstractCdiAwareTest.java:37)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
       at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
       at java.lang.reflect.Method.invoke(Method.java:611)
       at
 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
       at
 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
       at
 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
       at
 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
       at
 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
       at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
       at
 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
       at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193

Re: OWB Decorator problem

[Mark Struberg]

hi Christian!

guess this was meant for u...@openwebbeans.apache.org? :)

LieGrue,
strub



- Original Message -
 From: Christian Beikov christian.bei...@gmail.com
 To: users@myfaces.apache.org
 Cc: 
 Sent: Monday, November 7, 2011 7:16 PM
 Subject: OWB Decorator problem
 
 Hello there!
 
 I have a problem with OWB that does not occur on WELD and I wasn't able to 
 find a solution for that yet.
 I am using OWB 1.0 shipped with IBM WAS 8.0.0.1 and the scenario is like this:
 
 class A implements Service{}
 class ADecorator implements Service{}
 class InterceptorImpl{}
 
 Now I call a method of the Service interface and the call is delegated to the 
 decorator as expected. The decorator passes the call to the underlying 
 implementation and the impl throws an exception. Now the decorator does not 
 see 
 the concrete exception that occurred in the impl but an 
 InvocationTargetException and within that, the actual exception.
 
 Am I wrong or should I see the actual exception and not the 
 InvocationTargetException? I can't even add an Interceptor to the decorator 
 methods to generically unwrap that exception, because AroundInvoke 
 interceptors 
 are not called if they are applied on decorators. Is that the expected 
 behavior 
 too?
 
 Thanks in advance!
 
 Regards,
 Christian

Re: Warning with CODI and MyFaces

[Mark Struberg]

hi Thomas!

Which CODI version are you using and which server environment (OWB or Weld)?
Is there any example project to reproduce this issue?


LieGrue,
strub



- Original Message -
 From: Thomas Andraschko zoi...@googlemail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Friday, October 28, 2011 2:05 PM
 Subject: Warning with CODI and MyFaces
 
 Hi,
 
 i get following warning from OWB:
 WARNUNG: No suitable constructor found for injection target class : [class
 org.apache.myfaces.shared.context.SwitchAjaxExceptionHandlerWrapperImpl].
 produce() method does not work!
 28.10.2011 14:00:42
 org.apache.webbeans.component.creation.AnnotatedTypeBeanCreatorImpl
 defineConstructor
 WARNUNG: No suitable constructor found for injection target class : [class
 org.apache.myfaces.context.MyFacesExceptionHandlerWrapperImpl]. produce()
 method does not work!
 
 How can i solve this? This warnings will be logged on each request and will
 blow up my logs :)
 
 Best regards
 Thomas

Re: My Faces Tunning

[Mark Struberg]

 - Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support 
 the browser back button!

And once a user opens another browser tab all will crash :(

The missing windowId support is really a pitty in the JSF spec, and we 
currently think hard about how to solve this (at least in MyFaces).
Until then all the stored views are shared accross all open browser tabs.

The best thing you can do to reduse Session space is to use 
ClientSideStateSaving

LieGrue,
strub


- Original Message -
 From: Michael Heinen mhn4...@googlemail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: 
 Sent: Tuesday, October 18, 2011 9:36 AM
 Subject: Re: My Faces Tunning
 
 A few thoughts:
 - Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support 
 the browser back button!
 - try to reduce the number of components (e.g. conditionally controls 
 can be excluded at compile time via c:if or via dynamic includes instead 
 of visibleOnUserRole or rendered checks).
 - facelets instead of jsps
 - plain html tags where possible
 - short component ids
 
 Michael
 
 
 
 Am 17.10.2011 22:16, schrieb Boyd, David (Corporate):
  All,
 
 
 
  I am doing some investigation into how to shrink the amount of session
  memory our JSF application is consuming on a per user basis.
 
 
 
  We are using MyFaces 1.1.7 and Tomahawk 1.1.5 running on IBM Websphere
  7.0 patch 19. (Not able to upgrade either of these items at this time)
 
 
 
  IBM's guideline is that the session size should be less then 5k -
  average around 2.5k in order not to impact performance of the server and
  session replication.  We are currently using Memory to Memory but
  looking at moving to database as suggested by IBM.
 
 
 
  Our site was running at about 35M per user.  We changed the number of
  view states from 100 to 10 and that dropped it down to around 4M.
 
 
 
  We have several backing beans which are currently session scope and are
  looking at changing them to request scope.
 
 
 
  I also found the following:
  http://www.econsulting.nl/images/pdf/Tuning%20JSF%20Applications-%20J-Sp
  ring%202008.pdf which seems to have a lot of information concerning how
  JSF handles certain content on the pages.  This is still under
  investigation to make sure what is stated make sense.
 
 
 
  I have also read somewhere that regardless if the managed backing bean
  is session or request scope is that the view state will still have the
  bean and its content.  So the view state size will not change.  Looking
  for clarification on this one.
 
 
 
  The questions is are others facing the same issue in which JSF
  applications tend to consume a lot of memory for a given users session?
 
 
 
 
  What are some of the best practices to reduce this size if any or is
  this just the way when using JSF?
 
 
 
  Issues with session replication on IBM WebSphere when running a JSF
  application?
 
 
 
  What we see as a result of this is that in the event a user hops to
  another server, the session data is not present due to how large the
  data is and how long it takes to replicate.  User experience issues.
 
 
 
  We had seen an issue in which it appeared that changes to the object in
  the session was not being updated correctly and have done some session
  management tuning in which we customize the settings so that all session
  attributes are written out.  Looking at the .jar file it does appear
  that myFaces is making the call correctly when the contents of the
  object in the session changes.  So WebSphere session listener should be
  picking up that change.
 
 

Re: My Faces Tunning

[Mark Struberg]

+1 mem is barely a problem these days.

Actually we are serving 60.000++ users per day without any mem problems (w 100 
views/session ServerSide-StateSaving).
We need some low GB mem on our 48GB RAM server...

Even if you have 1MB of session mem per user then you can serve tons of users.


LieGrue,
strub





From: Tobias Eisentrager teisentrae...@googlemail.com
To: MyFaces Discussion users@myfaces.apache.org
Sent: Tuesday, October 18, 2011 10:46 PM
Subject: Re: My Faces Tunning

David,

Usually memory is the problem - but sometimes there are also CPU problems -
you can run WebSphere for example on the Mainframe. Compared to a Linux Box
CPU time can be expensive there.

Are you running on a 64 bit Architecture? Memory is not that expensive these
days ;-)

What is you total memory usage?

Toby

On Tue, Oct 18, 2011 at 10:42 PM, Boyd, David (Corporate) 
david.b...@adesa.com wrote:

 Scott,

 With your comment below but do you feel is a more realistic targeted
 size for session size with JSF?

 All,

 Based on some of the comments, is this not an issue for others that make
 use of this Technology or did we basically implement it incorrectly -
 from the way the .jsp are created to how we are managing the backing
 beans?



 -Original Message-
 From: Scott O'Bryan [mailto:darkar...@gmail.com]
 Sent: Monday, October 17, 2011 4:58 PM
 To: users@myfaces.apache.org
 Subject: Re: My Faces Tunning

 Wow..  Looks like you've done a lot, but I personally think 5K is
 unrealistic.  Your right.  Essentially JSF stores your component tree in

 memory.

 You MAY be able to enable client-side state saving which should free you

 up some memory at the expense of storing the entire view tree on the
 client.  Additionally, a framework like orchestra or something home
 grown may allow you to get rid of managed beans quicker.

 One other thing.  I don't know how Websphere works, but I know in the
 case of WLS, it only serializes object when they are added to the
 session.  While this means they may need to be added again if they are
 updated, it's not subject to this limitation your describing.  I'm
 wondering if WebSphere has some settings on the replication which might
 get you some better results.

 Scott

 On 10/17/2011 02:16 PM, Boyd, David (Corporate) wrote:
  All,
 
 
 
  I am doing some investigation into how to shrink the amount of session
  memory our JSF application is consuming on a per user basis.
 
 
 
  We are using MyFaces 1.1.7 and Tomahawk 1.1.5 running on IBM Websphere
  7.0 patch 19. (Not able to upgrade either of these items at this time)
 
 
 
  IBM's guideline is that the session size should be less then 5k -
  average around 2.5k in order not to impact performance of the server
 and
  session replication.  We are currently using Memory to Memory but
  looking at moving to database as suggested by IBM.
 
 
 
  Our site was running at about 35M per user.  We changed the number of
  view states from 100 to 10 and that dropped it down to around 4M.
 
 
 
  We have several backing beans which are currently session scope and
 are
  looking at changing them to request scope.
 
 
 
  I also found the following:
 
 http://www.econsulting.nl/images/pdf/Tuning%20JSF%20Applications-%20J-Sp
  ring%202008.pdf which seems to have a lot of information concerning
 how
  JSF handles certain content on the pages.  This is still under
  investigation to make sure what is stated make sense.
 
 
 
  I have also read somewhere that regardless if the managed backing bean
  is session or request scope is that the view state will still have the
  bean and its content.  So the view state size will not change.
 Looking
  for clarification on this one.
 
 
 
  The questions is are others facing the same issue in which JSF
  applications tend to consume a lot of memory for a given users
 session?
 
 
 
 
  What are some of the best practices to reduce this size if any or is
  this just the way when using JSF?
 
 
 
  Issues with session replication on IBM WebSphere when running a JSF
  application?
 
 
 
  What we see as a result of this is that in the event a user hops to
  another server, the session data is not present due to how large the
  data is and how long it takes to replicate.  User experience issues.
 
 
 
  We had seen an issue in which it appeared that changes to the object
 in
  the session was not being updated correctly and have done some session
  management tuning in which we customize the settings so that all
 session
  attributes are written out.  Looking at the .jar file it does appear
  that myFaces is making the call correctly when the contents of the
  object in the session changes.  So WebSphere session listener should
 be
  picking up that change.
 
 

RE: codi and webservices

[Mark Struberg]

Hi Pieter!

This is more a CDI container question than a CODI question :)
From the stacktrace you posted in an older post I saw that you are using 
Apache OpenWebBeans, right? good decision btw :D  

Since I know a little bit about OWB, I'll try to explain ;)

Basically any Servlet inside your webapp already should have all things 
correctly setup. If you are interested in the details then check OWBs 
WebBeansConfigurationListener. If you are using CXFNonSpringServlet then the 
Servlet itself will not be created by CDI, so the servlet instance itself is 
not a CDI-managed object (Maybe there is some CXFCdiServlet in the future...) 
This basically means that any @Inject inside this class will not get injected.

In this case you can use CODIs BeanManagerProvider to get access to a CDI 
managed bean manually.
I use this trick with an old JAX-RS stack as well.

hope this helps!

LieGrue,
strub


--- On Sat, 7/9/11, Pieter Martin pieter.mar...@gmail.com wrote:

 From: Pieter Martin pieter.mar...@gmail.com
 Subject: RE: codi and webservices
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Saturday, July 9, 2011, 8:28 AM
 Hi,
 
 Is there any support for having a webservice request
 happening inside a cdi/codi world. In particular I am using
 apache cxf in jetty, starting up the CXFNonSpringServlet
 which does the magic. So I imagine somehow this servlet's
 requests needs to be wrapped in a codi life cycle similar to
 how faces works.
 
 Is this possible?
 
 Thanks
 Pieter
 

Re: codi and webservices

[Mark Struberg]

You might try using OpenWebBeans + OpenEJB. Those 2 play really well together, 
and EJB contains MDB. Not sure though if the MDB impl in OpenEJB already works 
together with CDI. David, I guess you know more than I about that, mind to 
share your thoughts?

txs and LieGrue,
strub

--- On Sat, 7/9/11, Pieter Martin pieter.mar...@gmail.com wrote:

 From: Pieter Martin pieter.mar...@gmail.com
 Subject: Re: codi and webservices
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Saturday, July 9, 2011, 3:24 PM
 Thanks, yes I am using OpenWebBeans
 and happily so. I tried the 
 BeanManagerProvider and things are working well.
 
 I reckon I will have the same issue with regards to jms,
 when I get 
 round to putting hornetq or ApacheMq into Jetty?
 
 Thanks
 Pieter
 
 
 On 09/07/2011 11:32, Mark Struberg wrote:
  Hi Pieter!
 
  This is more a CDI container question than a CODI
 question :)
   From the stacktrace you posted in an older post
 I saw that you are using Apache OpenWebBeans, right? good
 decision btw :D
 
  Since I know a little bit about OWB, I'll try to
 explain ;)
 
  Basically any Servlet inside your webapp already
 should have all things correctly setup. If you are
 interested in the details then check OWBs
 WebBeansConfigurationListener. If you are using
 CXFNonSpringServlet then the Servlet itself will not be
 created by CDI, so the servlet instance itself is not a
 CDI-managed object (Maybe there is some CXFCdiServlet in the
 future...) This basically means that any @Inject inside this
 class will not get injected.
 
  In this case you can use CODIs BeanManagerProvider to
 get access to a CDI managed bean manually.
  I use this trick with an old JAX-RS stack as well.
 
  hope this helps!
 
  LieGrue,
  strub
 
 
  --- On Sat, 7/9/11, Pieter Martinpieter.mar...@gmail.com 
 wrote:
 
  From: Pieter Martinpieter.mar...@gmail.com
  Subject: RE: codi and webservices
  To: MyFaces Discussionusers@myfaces.apache.org
  Date: Saturday, July 9, 2011, 8:28 AM
  Hi,
 
  Is there any support for having a webservice
 request
  happening inside a cdi/codi world. In particular I
 am using
  apache cxf in jetty, starting up the
 CXFNonSpringServlet
  which does the magic. So I imagine somehow this
 servlet's
  requests needs to be wrapped in a codi life cycle
 similar to
  how faces works.
 
  Is this possible?
 
  Thanks
  Pieter
 
 

Re: @Disposes and webapp shutdown and @Singleton/@ApplicationScope

[Mark Struberg]

Hi!

Please note that javax.inject.Singleton is completely underspecified!
I suggest to not use it at all ;)

LieGrue,
strub

--- On Fri, 7/8/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:

 From: Gerhard Petracek gerhard.petra...@gmail.com
 Subject: Re: @Disposes and webapp shutdown and @Singleton/@ApplicationScope
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Friday, July 8, 2011, 7:31 AM
 hi pieter,
 
 in the end you have to shutdown one of both scopes first.
 if you change the
 behaviour, you would have a problem the other way round.
 please always use @ApplicationScoped instead of @Singleton
 (in terms of cdi
 @Singleton isn't specified very clearly - it's part of jsr
 330 which doesn't
 say a lot about it).
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2011/7/8 Pieter Martin pieter.mar...@gmail.com
 
  Hi,
 
  I have an application scoped producer method together
 with a disposer which
  sits in a @javax.inject.Singleton scoped class.
 
  @Singleton
  public class DbProducer implements Serializable {
     @ApplicationScopedDb
     @Produces
     @ApplicationScoped
     public NakedGraph
 getApplicationScopedNakedGraph**() {
         logger.info(produce
 Application scoped db);
         NakedGraph db =
 createNakedGraph();
         return db;
     }
 
     public void
 closeApplicationScoped(@**Disposes @ApplicationScopedDb
  NakedGraph db) {
         logger.info(shutdown
 Application scoped db);
         if (db != null) {
            
 db.shutdown();
         }
     }
  }
 
  On shutting down jetty I get the following exception.
 
  SEVERE: Exception thrown while destroying bean
 instance :
  [Name:null,WebBeans Type:PRODUCERMETHOD,API
 Types:[com.tinkerpop.**
 
 blueprints.pgm.Graph,java.io.**Serializable,org.nakeduml.**
 
 tinker.runtime.NakedGraph,com.**tinkerpop.blueprints.pgm.**
 
 IndexableGraph,java.lang.**Object,com.tinkerpop.**blueprints.pgm.**
  TransactionalGraph],**Qualifiers:[javax.enterprise.**
 
 inject.Any,org.nakeduml.**tinker.runtime.**ApplicationScopedDb]]
  java.lang.NullPointerException
     at
 org.apache.webbeans.component.**ProducerMethodBean.**disposeDefault(
  **ProducerMethodBean.java:346)
     at
 org.apache.webbeans.component.**ProducerMethodBean.dispose(**
  ProducerMethodBean.java:306)
     at
 org.apache.webbeans.component.**ProducerMethodBean.**
  destroyInstance(**ProducerMethodBean.java:298)
     at
 org.apache.webbeans.component.**AbstractOwbBean.**
  destroyCreatedInstance(**AbstractOwbBean.java:277)
     at
 org.apache.webbeans.portable.**creation.AbstractProducer.**
  dispose(AbstractProducer.java:**91)
     at
 org.apache.webbeans.component.**InjectionTargetWrapper.**dispose(**
  InjectionTargetWrapper.java:**116)
     at
 org.apache.webbeans.component.**AbstractOwbBean.destroy(**
  AbstractOwbBean.java:242)
     at
 org.apache.webbeans.context.**AbstractContext.**destroyInstance(**
  AbstractContext.java:257)
     at
 org.apache.webbeans.context.**AbstractContext.destroy(**
  AbstractContext.java:279)
     at
 org.apache.webbeans.web.**context.WebContextsService.**
 
 destroyApplicationContext(**WebContextsService.java:485)
     at
 org.apache.webbeans.web.**context.WebContextsService.**
  endContext(WebContextsService.**java:200)
     at
 org.apache.webbeans.web.**context.WebContextsService.**
  destroy(WebContextsService.**java:155)
     at
 org.apache.webbeans.lifecycle.**AbstractLifeCycle.**stopApplication(
  **AbstractLifeCycle.java:149)
     at
 org.apache.webbeans.web.**lifecycle.**WebContainerLifecycle.**
  stopApplication(**WebContainerLifecycle.java:87)
     at
 org.apache.webbeans.servlet.**WebBeansConfigurationListener.**
 
 contextDestroyed(**WebBeansConfigurationListener.**java:96)
     at
 org.eclipse.jetty.server.**handler.ContextHandler.doStop(**
  ContextHandler.java:679)
     at
 org.eclipse.jetty.servlet.**ServletContextHandler.doStop(**
  ServletContextHandler.java:**143)
     at
 org.eclipse.jetty.webapp.**WebAppContext.doStop(**
  WebAppContext.java:473)
     at
 org.eclipse.jetty.util.**component.AbstractLifeCycle.**
  stop(AbstractLifeCycle.java:**83)
     at
 org.eclipse.jetty.server.**handler.HandlerCollection.**
  doStop(HandlerCollection.java:**245)
     at
 org.eclipse.jetty.util.**component.AbstractLifeCycle.**
  stop(AbstractLifeCycle.java:**83)
     at
 org.eclipse.jetty.server.**handler.HandlerWrapper.doStop(**
  HandlerWrapper.java:101)
     at
 org.eclipse.jetty.server.**Server.doStop(Server.java:319)
     at
 org.eclipse.jetty.util.**component.AbstractLifeCycle.**
  stop(AbstractLifeCycle.java:**83)
     at
 org.nakeduml.jetty.StartJetty$**MonitorThread.run(StartJetty.**
  java:92)
 
 
  Some investigation shows that the base exception is a
 
  new ContextNotActiveException(**WebBeans context
 with scope type
  annotation @ + scopeType.getSimpleName() +  does not
 exist 

Re: MyFaces - Thread issues under High load

[Mark Struberg]

Most importantly: which JDK/JRE are you running WebLogic under? And which 
weblogic version do you use?

You have definitely checked diskfree? (df -h) and mem is also no concern?
Are you running a 32 or 64 bit JVM?
Under 32 bit JVMs you could easily run out of available threads (the higher you 
tune your -Xmx, the LOWER the amount of available threads get!) 


Just a few random ideas...

LieGrue,
strub

--- On Mon, 7/4/11, Martin Koci martin.kocicak.k...@gmail.com wrote:

 From: Martin Koci martin.kocicak.k...@gmail.com
 Subject: Re: MyFaces - Thread issues under High load
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Monday, July 4, 2011, 7:29 PM
 Hi,
 
 what is [STUCK] thread? Is that something special from
 WebLogic thread
 pooler? 
 All threads are accessing same
 java.beans.PropertyDescriptor.getReadMethod but this method
 is
 synchronized. So one on them is holding
 java.beans.PropertyDescriptor
 instance as monitor and the others are trying access same
 critical area.
 One of the STUCKs is suspicious: it probably entered
 critical area on
 PropertyDescriptor forever. But it should not happen: this
 is API from
 JRE and myfaces use it only - this looks very  odd. 
 
 Suggestions:
 
 1) set thread timeout if possible. I don't know weblogic
 but thread
 executors can kill thread it it does not end in reasonable
 time.
 
 2) Is JVM eating 100% of CPU? If so then hotspot can cause
 this type of
 problem - I remement similar problem few year ago - update
 to newer
 version of JVM solved it. What JVM/version do you use?
 
 3) Is problem repeatable? Do you perform stress test or is
 this problem
 from production deployment?
 
 
 Regards,
 
 Kočičák
 
 Rajadurai_p píše v Po 04. 07. 2011 v 11:17 -0700:
  Hi,
  I have attached a weblogic server thread dump file
 collected under high load
  and when the server was irresponsive. You will find
 almost all the threads
  (active  stuck) pointing to the same stack trace
 which is My faces/
  Tomahawk related. Kindly let me know your views.
  
  Thanks
  
  
  Matt Benson-2 wrote:
   
   It looks to me as though you are using the JSF
 reference
   implementation.  The only code I see from
 myfaces in your stack trace
   is Tomahawk.
   
   Matt
   
   On Wed, Jun 29, 2011 at 4:39 AM,
 Rajadurai_p  wrote:
  
   Hi,
   we are facing problems in MyFaces framework
 under high load. Bulk of the
   application container threads (weblogic) are
 stuck upon a same stack
   trace.
   I have pasted a sample stack trace below.
 Kindly help.
  
   We use JSF 1.2, MyFaces 1.2.9, Tomahawk 1.1.9
  RichFaces 3.3.3.
  
  
  
  
  
 java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:158)
  
  
 javax.faces.component._ComponentAttributesMap.getComponentProperty(_ComponentAttributesMap.java:382)
  
  
 javax.faces.component._ComponentAttributesMap.get(_ComponentAttributesMap.java:227)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.renderHTMLAttribute(HtmlRendererUtils.java:584)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.renderHTMLAttributes(HtmlRendererUtils.java:598)
  
  
 org.apache.myfaces.custom.htmlTag.HtmlTagRenderer.encodeBegin(HtmlTagRenderer.java:73)
        
   
 javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:600)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:525)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:511)
  
  
 org.apache.myfaces.custom.htmlTag.HtmlTagRenderer.encodeChildren(HtmlTagRenderer.java:111)
  
  
 javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:627)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:528)
  
  
 org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:511)
  
  
 org.apache.myfaces.custom.htmlTag.HtmlTagRenderer.encodeChildren(HtmlTagRenderer.java:111)
  
  
 javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:627)
        
   
 org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:277)
        
   
 org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:258)
  
  
 org.richfaces.renderkit.AbstractGridRenderer.encodeOneRow(AbstractGridRenderer.java:96)
  
  
 org.richfaces.renderkit.AbstractRowsRenderer.process(AbstractRowsRenderer.java:83)
        
   
 org.ajax4jsf.model.SequenceDataModel.walk(SequenceDataModel.java:101)
        
   
 org.ajax4jsf.component.UIDataAdaptorBase.walk(UIDataAdaptorBase.java:1156)
  
  
 org.richfaces.renderkit.AbstractRowsRenderer.encodeRows(AbstractRowsRenderer.java:104)
  
  
 org.richfaces.renderkit.AbstractRowsRenderer.encodeRows(AbstractRowsRenderer.java:88)
  
  
 org.richfaces.renderkit.AbstractRowsRenderer.encodeChildren(AbstractRowsRenderer.java:137)
  
  
 javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:627)
  

Re: @ViewAccessScoped PreDestroy

[Mark Struberg]

Just for making this clear: we do _not_ suggest to use a plain a href...! 
Please use h:outputLink instead (since JSF-2.
This will render a a href for you but will also manage all the view params if 
you like, etc. You can also add f:param children to pass parameters without 
having to do some string juggling.

LieGrue,
strub

--- On Fri, 6/24/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:

 From: Gerhard Petracek gerhard.petra...@gmail.com
 Subject: Re: @ViewAccessScoped PreDestroy
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Friday, June 24, 2011, 5:46 PM
 hi pieter,
 
 to avoid side-effects you should always use such jsf
 components.
 if you really have to use a plain link - the solution would
 be:
    a
 href=#{facesContext.externalContext.request.contextPath}/myPage.xhtml?windowId=#{currentWindow.id}My
 Page/a
 that's for sure more verbose than the version with h:link:
    h:link value=My Page
 outcome=myPage/
 
 @ViewScoped:
 besides some other disadvantages, that's the behaviour
 specified by jsf2.
 codi doesn't implement this scope itself. it just provides
 an adapter for
 cdi which delegates to the default implementation of jsf2.
 so it's better to use one of the scopes which are
 completely implemented by
 codi itself.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 2011/6/24 Pieter Martin pieter.mar...@gmail.com
 
  Hi,
 
  Thanks for the reply and demo.
 
  I see the difference is that I have been navigating to
 the new pages via a
  browser url get request.
  I tried it now with a h:link / and then the
 @PreDestroy gets called.
 
  Is it suppose to work via get request?
 
  Thanks
  Pieter
 
 
 
 
  On 24/06/2011 19:01, Gerhard Petracek wrote:
 
  hi pieter,
 
  based on the archetype i created a demo [1].
  i just added a view-access-scoped bean and
 accessed it on the second page.
  in the @PostConstruct callback a message gets
 added which you can see on
  the
  page.
  the @PreDestroy callback writes the message to the
 console because the
  bean
  gets destroyedafter  the rendering
 process (if it wasn't accessed by the
  new page) - so you won't see a message on the page
 (if you would add one
  like in the @PostConstruct callback).
 
  you can start the demo e.g. with:
  mvn clean jetty:run-exploded -PjettyConfig
 
  regards,
  gerhard
 
  [1]
  http://people.apache.org/~**gpetracek/myfaces/codi/demos/**
  view-access-scope-demo.ziphttp://people.apache.org/~gpetracek/myfaces/codi/demos/view-access-scope-demo.zip
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
  2011/6/24 Pieter Martinpieter.mar...@gmail.com**
 
   Hi,
 
  I have tested as you mentioned but the
 @PreDestroy still does not get
  called.
 
  I am using the jsf application as generated
 with the maven archetype.
 
  I am however running it in embedded jetty
 mode, i.e. view a main method.
  I have a META-INF/beans.xml in the
 src/main/resources dir.
 
  page1 = helloWorld.xhtml which references the
 WindowScoped
  HelloWorldController
  page2 = testViewAccessScoped.xhtml which
 references a ViewAccessScoped
  bean
  - PostConstruct called
  page1 = helloWorld.xhtml, ViewAccessScoped -
 PreDestroy not called, as
  expected
  page1, again = helloWorld.xhtml,
 ViewAccessScoped - PreDestroy not
  called,
  expected it to be called
  page3 = helloWorld2.xhtml which references the
 WindowScoped
  HelloWorldController - PreDestroy not called,
 expected it to be called
  page4 = testViewAccessScoped2.xhtml which
 references a different
  ViewAccessScoped bean - PostConstruct called,
 PreDestroy not called
  page2 = testViewAccessScoped.xhtml which
 references a ViewAccessScoped
  bean
  - PostConstruct called and PreDestroy called
 on page4's ViewAccessScoped
  bean
 
 
  I can only get PreDestroy called if I navigate
 from a ViewAccessScoped
  directly to another ViewAccessScoped page.
 
  Using @ViewScoped I can not get PreDestroyed
 to be called at all.
  Using @ViewScoped if I F5 on the page
 @PostConstruct is called everytime
  and @PreDestroy never
 
  Thanks
  Pieter
 
 
 
  On 23/06/2011 23:11, Gerhard Petracek wrote:
 
   hi pieter,
 
  first of all welcome @ myfaces!
  as long as the bean is referenced by a
 page - the bean will be available
  for
  the next page. after rendering the first
 page which doesn't use the
  view-access scoped bean it will be
 destroyed (that's independent of
  other
  beans).
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
  2011/6/23 Pieter Martinpieter.mar...@gmail.com
 
   Hi,
 
  I trying to use @ViewAccessScoped
 beans but am not getting the expected
  behavior.
 
  I notice that 

Re: [FYI] testing CODI and Seam3 with glassfish

[Mark Struberg]

Hi Arun!

One of the simplest examples is our CODI playground jsf20 example [1]. 
Well, our examples are made for standalone usage. So please just remove the 
openwebbeans stuff from the WAR and cut down other dependencies which are not 
needed on a full EE server. 

With Glassfish-3.1 you will almost immediately fall over this very nasty 
mojarra bug (fixed in the meantime):
http://java.net/jira/browse/GLASSFISH-15905
This is a really weird thing and has nothing to do with Weld. It is just an 
incompletely initialized FacesContext. I also faced other weird errors of this 
kind when starting glassfish under load (jmeter running against it). There 
might be some startup problems, but it's hard to create a stable test case for 
it, so I didn't report it.

Matthias Wessendorf tried to work around the mentioned bug and found a bunch of 
other major issues in only a few hours testing. A few of them are still open 
and unfixed! Just check your Jira for reporter='mwessendorf'.

gf-3.2 looks a good bit better.


LieGrue,
strub


[1]
$ svn co https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk codi
$ cd examples/jsf-playground/hello_myfaces-codi_jsf20/
$ mvn clean install
and then strip the WAR file

--- On Sat, 5/28/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:

 From: Gerhard Petracek gerhard.petra...@gmail.com
 Subject: Re: [FYI] testing CODI and Seam3 with glassfish
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Saturday, May 28, 2011, 9:04 PM
 hi arun,
 
 welcome @ our mailing-list!
 
 most issues faced by our users are specific to weld and/or
 glassfish in
 combination with bigger portable extensions and sometimes
 even with simpler
 cases.
 if you test the same implementation with openwebbeans and
 a
 servlet-container like tomcat or owb and a jee5 app-server,
 it just works.
 
 however, several issues are quite specific. e.g. we have
 users who can use
 the fine-grained modules of codi with glassfish and others
 see
 deployment-issues with the same setup and have to use the
 all-in-one jar as
 a workaround.
 we already filed weld as well as glassfish issues, if an
 issue was
 reproducible.
 
 anyway, the first version which worked in most of our
 (still quite simple)
 tests is the latest snapshot of glassfish v3.2. even the
 combination of
 glassfish v3.1 + weld v1.1.1 has major issues for some
 (quite common)
 use-cases.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 2011/5/28 Arun Gupta arun.gu...@gmail.com
 
  Hi Kito,
 
  Google alerts showed me this message and raised my
 curiosity. I wanted
  to find out how bad GlassFish is broken :-)
 
  CDI 1.1 discussions are all happening in open and you
 can support your case
  at:
 
  https://lists.jboss.org/mailman/listinfo/cdi-dev
 
  or githib:
 
  https://github.com/pmuir/cdi/wiki
 
  -Arun
 
  On Sat, May 28, 2011 at 1:08 PM, Kito Mann kito.m...@virtua.com
 wrote:
   Hello Arun,
  
   Glad to see you here. Not only is it good for
 CDI, but it's good for me,
   since I'm looking into using Glassfish.
  
   While you're on it, please push for portlet
 support in Weld :-).
   ---
   Kito D. Mann | twitter: kito99 | Author, JSF in
 Action
   Virtua, Inc. | http://www.virtua.com | JSF/Java EE
 training and
  consulting
   http://www.JSFCentral.com - JavaServer Faces FAQ, news,
 and info |
  twitter:
   jsfcentral
   +1 203-404-4848 x3
  
   * Listen to the latest headlines in the JSF and
 Java EE newscast:
  
  http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
   * See you at JAX and JSF Summit 2011 June 20-23rd
 in San Jose:
   http://jaxconf.com/
  
  
   On Sat, May 28, 2011 at 4:04 PM, arungupta arun.gu...@gmail.com
 wrote:
  
  
   Hi Mark,
  
  
   struberg wrote:
   
The result:
   
Please skip glassfish-3.1 !
   
It's really completely broken. It has
 lots of errors not only in Weld
  but
also in the Mojarra integration it ships
 (from minor glitches to not
finding the FacesContext because the
 lookup integration seems
  completely
messed up)!
Most of my tested projects even refused
 to start at all!
   
  
   Can you share more details of your tests ?
 Did you file any bugs ? I
  know
   several folks using GlassFish in production
 with Mojarra + PrimeFaces +
   CDI.
  
  
   struberg wrote:
   
The solution: use glassfish-3.2-SNAPSHOT
 (*)!
I was at least able to start a few
 samples successfully. There are
  still
   a
few fixes needed (moving around
 beans.xml info, extracting jars to
WEB-INF/classes, EAR scenario completely
 fucked up when using
   Extensions),
but for a WAR deployment it's
 sufficient...
   
  
   GlassFish 3.2 has Weld 1.1 so that might have
 solved some of the issues
  you
   faced.
  
  
   struberg wrote:
   
Oh yea, I did a 'bit' more than just a
 simple hello webworld

[FYI] testing CODI and Seam3 with glassfish

[Mark Struberg]

Hi folks!

Since we got _lots_ of CODI bug reports recently in this area, I spent the 
afternoon with testing a few CDI projects with glassfish-3.1. Not only CODI but 
also Seam3 and a few private JSR-299 Extensions.

The result:

Please skip glassfish-3.1 !

It's really completely broken. It has lots of errors not only in Weld but also 
in the Mojarra integration it ships (from minor glitches to not finding the 
FacesContext because the lookup integration seems completely messed up)! 
Most of my tested projects even refused to start at all!


The solution: use glassfish-3.2-SNAPSHOT (*)!
I was at least able to start a few samples successfully. There are still a few 
fixes needed (moving around beans.xml info, extracting jars to WEB-INF/classes, 
EAR scenario completely fucked up when using Extensions), but for a WAR 
deployment it's sufficient...

Oh yea, I did a 'bit' more than just a simple hello webworld - but not too 
much. The projects were still pretty small.

LieGrue,
strub

(*) if you are bound to using glassfish - otherwise just use 
tomcat+myfaces+openwebbeans+openejb ;)

Re: AW: CODI @ViewAccessScoped not cleaned up?

[Mark Struberg]

I'm not really conviced that we should implement workarounds for such clearly 
broken weld issues. 

Thomas, did you already file a bug report in Weld marking this as blocker? 
Really, we should at least link to them in our sources (+jira) and asap get rid 
of this workaround in OUR source again. Otherwise we will end up with 
unmaintainable CODI sources.

LieGrue,
strub
 
--- On Sat, 5/21/11, Ing.Thomas Kernstock t.kernst...@e-technologies.at wrote:

 From: Ing.Thomas Kernstock t.kernst...@e-technologies.at
 Subject: AW: CODI @ViewAccessScoped not cleaned up?
 To: 'MyFaces Discussion' users@myfaces.apache.org
 Date: Saturday, May 21, 2011, 1:17 AM
 that's what I expected :-) The
 chances that weld causes the problem where
 rather huge  (as we discussed earlier).
 have a good one
 thomas
 
 
 -Ursprüngliche Nachricht-
 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
 
 Gesendet: Freitag, 20. Mai 2011 21:08
 An: MyFaces Discussion
 Betreff: Re: CODI @ViewAccessScoped not cleaned up?
 
 hi thomas,
 
 this part of codi hasn't changed since the first release
 whereas weld
 changed a lot.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2011/5/20 Ing.Thomas Kernstock t.kernst...@e-technologies.at
 
  Hi Gerhard,
 
  I Think you are right - this problem exists either
 since Codi 0.9.4 or 
  Glassfish3.1(Weld 1.1.1). This explains why I see
 extra database 
  updates (in my logfiles) of entities that should have
 been destroyed 
  allready. On Glassfish 3.0.1 with CODI 0.9.3 this
 worked fine !
 
  best regards
  Thomas
 
  ___
  -Ursprüngliche Nachricht-
  Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
  Gesendet: Freitag, 20. Mai 2011 19:35
  An: MyFaces Discussion
  Betreff: Re: CODI @ViewAccessScoped not cleaned up?
 
  hi gernot,
 
  @PreDestroy will be called after rendering the first
 page which 
  doesn't use the bean.
  it looks like a weld bug (i see the same with weld
 v1.1.1).
  i tested it with owb and it works as expected.
  i'll have a look at it, if there is a possible
 workaround for weld.
 
  regards,
  gerhard
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 
 
  2011/5/20 Gernot Pfingstl gernot.pfing...@gmx.at
 
   Hi,
  
   I'm using Glassfish 3.1 and CODI 0.9.5
  
   I've a bean A annotated with @ViewAccessScoped.
  
   Bean A is used in page1.xhtml. If page1 is called
 from page1 the 
   state of the bean is preserved (as expected).
  
   Then I navigate to page2.xhtml (which does not
 have any reference to 
   bean A), an then I navigate (from page2) to
 page3.xhtml (which also 
   does not have any reference to bean A).
   At this point I supposed bean A has bean
 invalidated/removed - but a 
   @PreDestroy is never calles
  
   Now I navigate (from page3) to page1.xhtml - and
 bean A has the 
   previous values and not an inital state.
  
   Do I misunderstand the @ViewAccessScoped or is
 there something wrong?
  
   regards,
   Gernot
  
 
 
 

Re: AW: CODI @ViewAccessScoped not cleaned up?

[Mark Struberg]

there is no SPI in the CDI spec which is not important for all users. 
Extensions are a core mechanism and needs to work.

We _must_ file a Weld issue in any case if we find an error. Maybe it might be 
our fault and they can help to clarify this...

This is just like this funyn guy telling Matze that an 'average developer' will 
not code Extensions, thus - low prio GF bug. 
This assumption is plain wrong and Glassfish folks already figured this. 
Because if an Extension developer cannot implement his Extension, then a 
'casual developer' cannot use this extension...

Who has stacktraces, info about this issue? Thomas or Gerhard one of you please 
file a Weld bug - big thanks!

Of course if we find something in OWB which you think it should just work, then 
please file a jira issue against OWB too - txs!

LieGrue,
strub 


--- On Sat, 5/21/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:

 From: Gerhard Petracek gerhard.petra...@gmail.com
 Subject: Re: AW: CODI @ViewAccessScoped not cleaned up?
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Saturday, May 21, 2011, 10:26 AM
 hi mark,
 
 it would be nice if we don't need workarounds for weld.
 however, we already have several workarounds. without them
 codi wouldn't
 work in combination with weld. the same is true for
 mojarra. and we can't
 just ignore both reference implementations for
 months/years.
 
 in this case it's a very special caching bug which came in
 due to the
 performance improvements in weld v1.1.1. usually you won't
 see it - we just
 have a very special constellation (since we (re-)use a spi
 which was
 designed for application developers).
 
 for sure we can file a weld issue. however, since it's a
 quite special
 constellation, they would give it a very low priority.
 there are way more
 weld bugs which are more important.
 
 regards,
 gerhard
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 2011/5/21 Mark Struberg strub...@yahoo.de
 
  I'm not really conviced that we should implement
 workarounds for such
  clearly broken weld issues.
 
  Thomas, did you already file a bug report in Weld
 marking this as blocker?
  Really, we should at least link to them in our sources
 (+jira) and asap get
  rid of this workaround in OUR source again. Otherwise
 we will end up with
  unmaintainable CODI sources.
 
  LieGrue,
  strub
 
  --- On Sat, 5/21/11, Ing.Thomas Kernstock t.kernst...@e-technologies.at
  wrote:
 
   From: Ing.Thomas Kernstock t.kernst...@e-technologies.at
   Subject: AW: CODI @ViewAccessScoped not cleaned
 up?
   To: 'MyFaces Discussion' users@myfaces.apache.org
   Date: Saturday, May 21, 2011, 1:17 AM
   that's what I expected :-) The
   chances that weld causes the problem where
   rather huge  (as we discussed earlier).
   have a good one
   thomas
  
  
   -Ursprüngliche Nachricht-
   Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
  
   Gesendet: Freitag, 20. Mai 2011 21:08
   An: MyFaces Discussion
   Betreff: Re: CODI @ViewAccessScoped not cleaned
 up?
  
   hi thomas,
  
   this part of codi hasn't changed since the first
 release
   whereas weld
   changed a lot.
  
   regards,
   gerhard
  
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
  
  
   2011/5/20 Ing.Thomas Kernstock t.kernst...@e-technologies.at
  
Hi Gerhard,
   
I Think you are right - this problem exists
 either
   since Codi 0.9.4 or
Glassfish3.1(Weld 1.1.1). This explains why
 I see
   extra database
updates (in my logfiles) of entities that
 should have
   been destroyed
allready. On Glassfish 3.0.1 with CODI 0.9.3
 this
   worked fine !
   
best regards
Thomas
   
___
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 20. Mai 2011 19:35
An: MyFaces Discussion
Betreff: Re: CODI @ViewAccessScoped not
 cleaned up?
   
hi gernot,
   
@PreDestroy will be called after rendering
 the first
   page which
doesn't use the bean.
it looks like a weld bug (i see the same
 with weld
   v1.1.1).
i tested it with owb and it works as
 expected.
i'll have a look at it, if there is a
 possible
   workaround for weld.
   
regards,
gerhard
   
http://www.irian.at
   
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
   
2011/5/20 Gernot Pfingstl gernot.pfing...@gmx.at
   
 Hi,

 I'm using Glassfish 3.1 and CODI 0.9.5

 I've a bean A annotated with
 @ViewAccessScoped.

 Bean A is used in page1.xhtml. If page1
 is called
   from page1 the
 state of the bean is preserved (as
 expected).

 Then I

Re: all-in-one dist package

[Mark Struberg]

Hi!

This is due to a bug in the maven-shade-plugin. We will work on that but it's 
low prio atm. Please refer to the to the single package JavaDocs instead.

And of course, if you have further questions, then just ping us back on this 
mailing list. We are happy about every feedback!

LieGrue,
strub

--- On Mon, 5/16/11, Gernot gern...@nurfuerspam.de wrote:

 From: Gernot gern...@nurfuerspam.de
 Subject: Re: all-in-one dist package
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Monday, May 16, 2011, 5:59 PM
 Thanks - now I've found it, but the
 javadoc file
 (myfaces-extcdi-dist-jsf20-0.9.5-javadoc.jar) only contains
 META-INF
 directory - no javadoc htmls
 
 2011/5/16 Robert Maier robert.m.ma...@gmail.com:
  Have a look at the end of the wiki page. I guess this
 is what you are
  looking for:
 
  *OPTIONAL all-in-one dependency for JSF 1.2 projects*
 
  dependency
   
  groupIdorg.apache.myfaces.extensions.cdi/groupId
   
  artifactIdmyfaces-extcdi-dist-jsf12/artifactId
     version${codi.version}/version
     scopecompile/scope
  /dependency
 
  or
 
  *OPTIONAL all-in-one dependency for JSF 2.0 projects*
 
  dependency
   
  groupIdorg.apache.myfaces.extensions.cdi/groupId
   
  artifactIdmyfaces-extcdi-dist-jsf20/artifactId
     version${codi.version}/version
     scopecompile/scope
  /dependency
 
 
 
  On 05/16/2011 06:31 PM, Gernot wrote:
 
  At https://cwiki.apache.org/confluence/display/EXTCDI/Module+Overview
  I found following statement:
  For some JEE6 application servers it's suggested
 to use the
  all-in-one dist package instead of the fine
 grained modules (due to
  server related issues).
 
  I cannot find the all-in-one dist package at the
 download page nor
  in any of the downloaded zip and tar.gz
  Where can I find it?
 
 

Re: Problem with @PageBean

[Mark Struberg]

Hi Robert!

First, welcome to the myfaces list!

Have you already tried to replace your weld-osgi-bundle in your glassfish with 
the on from the weld-1.1.1.Final distribution [1]?

LieGrue,
strub

[1] 
https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/weld-osgi-bundle/1.1.1.Final/

--- On Wed, 4/27/11, Robert Maier robert.m.ma...@gmail.com wrote:

 From: Robert Maier robert.m.ma...@gmail.com
 Subject: Problem with @PageBean
 To: users@myfaces.apache.org
 Date: Wednesday, April 27, 2011, 12:57 PM
 Hello everybody,
 
 I have a problem in a simple test-application whhich uses
 CODI with JSF2.0,
 Glassfish 3.1 and Weld.
 
 I posted a detailed problem-description to stackoverflow:
 http://stackoverflow.com/questions/5803492/apache-myfaces-codi-pagebean-argument-bean-must-not-be-null/5803922#5803922
 
 Thank you all in advance for any help!
 
 Best regards,
 Robert
 

Re: JSF application very slow with HTTPS

[Mark Struberg]

I'm using jetty-6.1.22 for such things.

LieGrue,
strub

--- On Mon, 4/11/11, Michael Heinen mhn4...@googlemail.com wrote:

 From: Michael Heinen mhn4...@googlemail.com
 Subject: Re: JSF application very slow with HTTPS
 To: MyFaces Discussion users@myfaces.apache.org
 Date: Monday, April 11, 2011, 1:53 PM
   Yes, compression is enabled,
 at least on the real systems.
 
 It was turned off in this local test.
 However, turning on compression results in 43KB instead of
 512 KB and 
 the response time is locally a little bit slower (17.5
 sec).
 So the problem with HTTPS is independent of the
 compression.
 
 I just tried to measure the times with jetty without
 success.
 Which jetty version do I have to use for myfaces 1.2?
 I tried several ones (7.3.x, 7.2.x, 7.1.X) but I get always
 EL errors 
 with nested expressions which I do not get with Tomcat
 6.0.X.
 I never used Jetty so far, can I put Tomcat's EL impl into
 jetty?
 
 Michael
 
 
 Am 11.04.2011 15:28, schrieb Adrian Mitev:
  Have you turned on the page compression of your app
 server?
 
  2011/4/11 Walter Mourãowalter.mou...@gmail.com
 
  As far as I know, the JSF does not know anything
 about https... it is
  handled by the servlet container (Tomcat,
 Jetty...).
 
  Walter Mourão
  http://waltermourao.com.br
  http://arcadian.com.br
  http://oriens.com.br
 
 
 
  On Mon, Apr 11, 2011 at 8:49 AM, Michael
 Heinenmhn4...@googlemail.com
  wrote:
    Hi,
 
  My JSF application is very slow via HTTPS.
  Some parts are 15 times slower compared to
 HTTP
 
  I measured the response times of the xhtml
 requests with Fiddler (locally
  and over network)
 
  Result for a very large page (512 KB) with a
 big datatable without ajax
  usage:
  --  local access with HTTP:  1 sec
  --  local access with HTTPS: 15-16 sec
 
  Other pages are factor 2-4 slower, with or
 without ajax.
  The time is spent in
 htmlTableRenderer.encodeInnerHtml. Data is of course
  available, there is no additional backend
 access.
 
  The simple download of xhtml files or other
 files is NOT (noticeable)
  slower.
  Other non JSF applications running on the same
 servers are also not
  slower
  with HTTPS.
 
  Before I start profiling:
  - Does anybody have an idea where I should
 look at?
  - Are there any known JSF or webApp settings
 that influence https
  performance?
 
  Environment:
    Facelets
    myFaces 1.2.9
    tomahawk12_1.1.10
    richfaces 3.3.3
    tomcat 6.0.29
    jdk 1.6.0_23
 
  Regards,
  Michael
 
 
 
 

Re: JSF application very slow with HTTPS

[Mark Struberg]

Btw another question: 1s local response time? How fat is this page?

We have a really big page in production with 1400 lines in a dataTable - and it 
renders in 450 ms...

How many back-and-forth requests do you see if you open firebug?
Do you have some EL involved which isn't hitting the backing bean but directly 
goes into the database? Something in this direction... 

LieGrue,
strub

--- On Mon, 4/11/11, Mike Kienenberger mkien...@gmail.com wrote:

 From: Mike Kienenberger mkien...@gmail.com
 Subject: Re: JSF application very slow with HTTPS
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: Michael Heinen mhn4...@googlemail.com
 Date: Monday, April 11, 2011, 2:20 PM
 I also use
 jetty-6.1.22.   My environment is almost
 identical to
 yours, give or take a minor version number.
 
 On Mon, Apr 11, 2011 at 7:49 AM, Michael Heinen mhn4...@googlemail.com
 wrote:
   Hi,
 
  My JSF application is very slow via HTTPS.
  Some parts are 15 times slower compared to HTTP
 
  I measured the response times of the xhtml requests
 with Fiddler (locally
  and over network)
 
  Result for a very large page (512 KB) with a big
 datatable without ajax
  usage:
  --  local access with HTTP:  1 sec
  --  local access with HTTPS: 15-16 sec
 
  Other pages are factor 2-4 slower, with or without
 ajax.
  The time is spent in
 htmlTableRenderer.encodeInnerHtml. Data is of course
  available, there is no additional backend access.
 
  The simple download of xhtml files or other files is
 NOT (noticeable)
  slower.
  Other non JSF applications running on the same servers
 are also not slower
  with HTTPS.
 
  Before I start profiling:
  - Does anybody have an idea where I should look at?
  - Are there any known JSF or webApp settings that
 influence https
  performance?
 
  Environment:
   Facelets
   myFaces 1.2.9
   tomahawk12_1.1.10
   richfaces 3.3.3
   tomcat 6.0.29
   jdk 1.6.0_23
 
  Regards,
  Michael
 

Re: JSF application very slow with HTTPS

[Mark Struberg]

Oh yes, another probably useful info: whenever https is involved via http doing 
lots of subsequent resource requests, then make sure that SSL session wont get 
closed! This really drastically drops the performance if the SSL handshaking 
always needs to re-negotiated over and over again...

LieGrue,
strub

--- On Mon, 4/11/11, Mike Kienenberger mkien...@gmail.com wrote:

 From: Mike Kienenberger mkien...@gmail.com
 Subject: Re: JSF application very slow with HTTPS
 To: MyFaces Discussion users@myfaces.apache.org
 Cc: Michael Heinen mhn4...@googlemail.com
 Date: Monday, April 11, 2011, 2:20 PM
 I also use
 jetty-6.1.22.   My environment is almost
 identical to
 yours, give or take a minor version number.
 
 On Mon, Apr 11, 2011 at 7:49 AM, Michael Heinen mhn4...@googlemail.com
 wrote:
   Hi,
 
  My JSF application is very slow via HTTPS.
  Some parts are 15 times slower compared to HTTP
 
  I measured the response times of the xhtml requests
 with Fiddler (locally
  and over network)
 
  Result for a very large page (512 KB) with a big
 datatable without ajax
  usage:
  --  local access with HTTP:  1 sec
  --  local access with HTTPS: 15-16 sec
 
  Other pages are factor 2-4 slower, with or without
 ajax.
  The time is spent in
 htmlTableRenderer.encodeInnerHtml. Data is of course
  available, there is no additional backend access.
 
  The simple download of xhtml files or other files is
 NOT (noticeable)
  slower.
  Other non JSF applications running on the same servers
 are also not slower
  with HTTPS.
 
  Before I start profiling:
  - Does anybody have an idea where I should look at?
  - Are there any known JSF or webApp settings that
 influence https
  performance?
 
  Environment:
   Facelets
   myFaces 1.2.9
   tomahawk12_1.1.10
   richfaces 3.3.3
   tomcat 6.0.29
   jdk 1.6.0_23
 
  Regards,
  Michael