Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 1264 invoked from network); 8 May 2007 08:14:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 May 2007 08:14:44 -0000 Received: (qmail 22585 invoked by uid 500); 8 May 2007 08:14:45 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 22551 invoked by uid 500); 8 May 2007 08:14:45 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 22539 invoked by uid 99); 8 May 2007 08:14:45 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 01:14:45 -0700 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=HTML_MESSAGE,INFO_TLD X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [155.91.38.2] (HELO uscttw1111.merck.com) (155.91.38.2) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 01:14:37 -0700 Received: from 54.62.195.231 by uscttw1111.merck.com with ESMTP (SMTP Relay); Tue, 08 May 2007 04:14:04 -0400 X-Server-Uuid: 21ED2443-EC2E-4990-AE40-34011731D2AC Received: from 54.50.132.126 by uscttw1103.merck.com with ESMTP ( Tumbleweed Email Firewall SMTP Relay (Email Firewall v6.2.1)); Tue, 08 May 2007 04:13:47 -0400 X-Server-Uuid: BE34D300-0A51-47CF-B7B0-43119D2E8061 Received: from uswsgw1100.merck.com ([54.16.24.114]) by usctgw1103.merck.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 04:13:47 -0400 Received: from bebrgw1101.merck.com ([54.101.54.86]) by uswsgw1100.merck.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 04:13:46 -0400 Received: from bebrmx1104.merck.com ([54.101.54.172]) by bebrgw1101.merck.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 10:13:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Initializing Beans - Two problems Date: Tue, 8 May 2007 10:13:49 +0200 Message-ID: In-Reply-To: <254acf980705071106h5688f120pd39beb624fe3bc72@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initializing Beans - Two problems Thread-Index: AceQ0qYLtiixbuZeSsuyFUb+PpQ4/QAclGJg References: <254acf980705071106h5688f120pd39beb624fe3bc72@mail.gmail.com> From: "Beelen, Marco" To: "MyFaces Discussion" X-OriginalArrivalTime: 08 May 2007 08:13:45.0569 (UTC) FILETIME=[CC5D5510:01C79148] X-WSS-ID: 6A5EEEB10RG29199528-01-01 X-WSS-ID: 6A5EEEB22BC16039111-04-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79148.CC4F8E40" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C79148.CC4F8E40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello Francisco, =20 There are some possible alternatives: =20 1) A JSF implementation should call the setters for the managed-properties of your bean in the order in which they are specified in the jsf-config.xml. Your could add an addional property 'startInitialization' as the last managed-property and perform the initialization in the setter for that property. =20 2) Make your classes implement the interface InitializingBean and use JSF-Spring ( http://jsf-spring.sourceforge.net/ ) to make sure that the initializing method will be called.. ( There have been reports about classloader issues with JSF-spring, but I didn't ran into them yet and am using this to my satisfaction. ) =20 3) When you are using Spring 2.0.x, you can move the definition of your managed-bean entirely to a spring applicationContext.xml and use org.springframework.beans.factory.InitializingBean without JSF-spring, although I don't fancy this approach I heard of some whom favour this. =20 4) Start using a JSF1.2 implementation and using the @PostConstruct annotation to mark the method to be called after the bean has been created and it's managed-properties are set. =20 =20 =20 With kind regards, Marco Beelen =20 =20 =20 =20 =20 ________________________________ =46rom: Simon Lessard [mailto:simon.lessard.3@gmail.com]=20 Sent: maandag 7 mei 2007 20:07 To: MyFaces Discussion Subject: Re: Initializing Beans - Two problems Hello Francisco, You could implement your own VariableResolver using decorator pattern delegating to the original resolver then initializing the bean if your condition is true. The code would look as follow: public Object resolveVariable(FacesContext context, String name) { Object o =3D delegate.resolveVariable(context, name); if (o !=3D null && (o instanceof GenericBean)) { GenericBean bean =3D (GenericBean)o;=20 if (!bean.isPostback()) { logger.info("Initializing bean: " + bean); bean.initialize(); } } } Regards, ~ Simon On 5/7/07, Francisco Passos wrote:=20 Hello there. =09 Please bear with me in this description. =09 I'm trying to get my request-scoped beans to be initialized (fetch stuff from database, etc.) whenever they do not originate from a postback (and keeping the state during postbacks using t:saveState). I've implemented a PhaseListener which checks for the proper conditions I want to initialize my beans in and invokes a method from the bean interface my beans implement.=20 =09 This is my implementation of said PhaseListener: =09 public void beforePhase(PhaseEvent event) { =09 if (event.getPhaseId().equals(PhaseId.APPLY_REQUEST_VALUES) || event.getPhaseId().equals(PhaseId.RENDER_RESPONSE )) { =20 GenericBean bean =3D (GenericBean) =46acesContext.getCurrentInstance().getApplication().getVariableResolver() .resolveVariable(FacesContext.getCurrentInstance(), "pesquisaFichaBean"); if (bean !=3D null && !bean.isPostback()) {=20 logger.info("Initializing bean: " + bean); bean.initialize(); } } } =09 =09 However I have two problems with this approach. =09 The first problem has to do with having to use the bean names explicitly ("pesquisaFichaBean" in this example). Is there any way I can know the names of the registered beans=3F Or is there another alternative I'm not seeing=3F=20 =09 =09 The second problem is as follows. By now I have a couple of beans that I use in my application. So, for this to work, I have to repeat what I've shown above for the various beans. The problem is that the resolveVariable method never returns null - even if I have not yet instantiated any bean with that particular name. It seems to me that, since no bean yet exists, it is instantiated (as it would be if it were referenced in a xhtml page).=20 =09 Which means that everytime I enter a new page (no postback), all my instantiated beans are initialized and the remaining are instantiated on the spot and initialized as well!!! This obviously brings me back to the problem of accessing the database for nothing.=20 =09 I hope I explained the situation well, here's an example: suppose some pages require "beanA", others "beanB". When I enter a page which references "beanA" but does not reference "beanB", both will be initialized! The difference is beanA will be used and beanB will.=20 =09 What solutions are there for this=3F Is there any way I can look into the variables without triggering their instantiation=3F =09 ---------------------------------------------------------------------------= --- Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is=20 available at http://www.merck.com/contact/contacts.html) that may be=20 confidential, proprietary copyrighted and/or legally privileged. It is=20 intended solely for the use of the individual or entity named on this=20 message. If you are not the intended recipient, and have received this=20 message in error, please notify us immediately by reply e-mail and then=20 delete it from your system. ---------------------------------------------------------------------------= --- ------_=_NextPart_001_01C79148.CC4F8E40 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hello Francisco,
 
There are some possible alternatives:
 
1) A JSF implementation should call the setters for the=20 managed-properties of your bean in the order in which they are specified in= = the=20 jsf-config.xml.
Your could add an addional property 'startInitialization' as the = last=20 managed-property and perform the initialization in the setter for that=20 property.
 
2) Make your classes implement the interface InitializingBean and = use=20 JSF-Spring (  http://jsf-spring.sourceforge.net/ )=20 to make sure that the initializing method will be called.. ( There hav= e= =20 been reports about classloader issues with JSF-spring, but I didn't ran int= o= =20 them yet and am using this to my satisfaction. )
 
3) When you are using Spring 2.0.x, you can move the definition of= = your=20 managed-bean entirely to a spring applicationContext.xml and use = org.springframework.beans.factory.InitializingBean= = without=20 JSF-spring, although I don't fancy this approach I heard of some whom favou= r= =20 this.
 
4) Start using a JSF1.2 implementation and using the @PostConstruc= t= =20 annotation to mark the method to be called after the bean has been created = and=20 it's managed-properties are set.
 
 
 
With kind regards,
  Marco Beelen
 
 
 
 
 
From: Simon Lessard=20 [mailto:simon.lessard.3@gmail.com]
Sent: maandag 7 mei 2007=20 20:07
To: MyFaces Discussion
Subject: Re: Initializing = Beans=20 - Two problems

Hello Francisco,

You could implement your own = VariableResolver=20 using decorator pattern delegating to the original resolver then = initializing=20 the bean if your condition is true. The code would look as = =66ollow:

public=20 Object resolveVariable(FacesContext context, String name) {
  Objec= t= o =3D=20 delegate.resolveVariable(context, name);
  if (o !=3D null = && (o=20 instanceof GenericBean)) {
    GenericBean bean =3D=20 (GenericBean)o;
    if (!bean.isPostback())=20 {
      logger.info("Initializing bean: " +=20 bean);
     =20 bean.initialize();
    }
 =20 }
}

Regards,

~ Simon

On 5/7/07, Francisco=20 Passos <francisco.passos@gmail.com&g= t;= =20 wrote:
Hello=20 there.

Please bear with me in this description.

I'm trying = to=20 get my request-scoped beans to be initialized (fetch stuff from database,= =20 etc.) whenever they do not originate from a postback (and keeping the = state=20 during postbacks using t:saveState). I've implemented a PhaseListener = which=20 checks for the proper conditions I want to initialize my beans in and = invokes=20 a method from the bean interface my beans implement.

This is my=20 implementation of said PhaseListener:

public void=20 beforePhase(PhaseEvent event) {

    if=20 (event.getPhaseId().equals(PhaseId.APPLY_REQUEST_VALUES) ||=20 event.getPhaseId().equals(PhaseId.RENDER_RESPONSE )) = {
   =20
        GenericBean bean =3D = (GenericBean)=20 = =46acesContext.getCurrentInstance().getApplication().getVariableResolver().= resolveVariable(FacesContext.getCurrentInstance(),= =20 "pesquisaFichaBean");
        if (bean = !=3D=20 null && !bean.isPostback()) {
   =20         logger.info("Initializing bean: " += =20 bean);
           =20 bean.initialize();
       =20 }
    }
}


However I have two problems wit= h= =20 this approach.

The first problem has to do with having to use the = bean=20 names explicitly ("pesquisaFichaBean" in this example). Is there any way = I= can=20 know the names of the registered beans=3F Or is there another alternative= = I'm=20 not seeing=3F


The second problem is as follows. By now I have= = a=20 couple of beans that I use in my application. So, for this to work, I hav= e= to=20 repeat what I've shown above for the various beans. The problem is that = the=20 resolveVariable method never returns null - even if I have not yet=20 instantiated any bean with that particular name. It seems to me that, = since no=20 bean yet exists, it is instantiated (as it would be if it were referenced= = in a=20 xhtml page).

Which means that everytime I enter a new page (no=20 postback), all my instantiated beans are initialized and the remaining ar= e= =20 instantiated on the spot and initialized as well!!! This obviously brings= = me=20 back to the problem of accessing the database for nothing.

I hope= = I=20 explained the situation well, here's an example: suppose some pages = require=20 "beanA", others "beanB". When I enter a page which references "beanA" but= = does=20 not reference "beanB", both will be initialized! The difference is beanA = will=20 be used and beanB will.

What solutions are there for this=3F Is = there=20 any way I can look into the variables without triggering their=20 instantiation=3F

------------------------------------------------------------------------= ------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.

---------------------------------------------------------------------------= ---

------_=_NextPart_001_01C79148.CC4F8E40--