users@javaserverfaces.java.net

RE: Re: Initial page loading: the managed bean doesn't inject the EJB when called in the constructor.

From: Todd Patrick <Todd.Patrick_at_dtn.com>
Date: Wed, 5 Sep 2007 15:35:58 -0500

Ryan:

OK, I read Jacob's blog entry, thanks - that was very informative.

I guess I'm looking for a clear understanding of how those steps relate
to the JSF Lifecycle?

Thanks again,

--Todd
 

-----Original Message-----
From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
Sent: Wednesday, September 05, 2007 3:30 PM
To: users_at_javaserverfaces.dev.java.net
Subject: Re: Initial page loading: the managed bean doesn't inject the
EJB when called in the constructor.

Todd Patrick wrote:
> Ryan:
>
> Thank you, that post just saved me a lot of time.
>
> I've been scanning the Java EE Tutorial looking for similar
information.
>

http://weblogs.java.net/blog/jhook/archive/2007/05/jsf_12_ri_backi.html

Here is a full blog on resource injection with the RI (I cut and paste
the steps from there).


> Thanks,
>
> --Todd
>
> -----Original Message-----
> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
> Sent: Wednesday, September 05, 2007 3:12 PM
> To: users_at_javaserverfaces.dev.java.net
> Subject: Re: Initial page loading: the managed bean doesn't inject the
> EJB when called in the constructor.
>
> Todd Patrick wrote:
>
>> Ryan:
>>
>> OK, with that said, I had always believed that a method annotated
with
>>
>
>
>> @PostConstruct would only execute after the injection of an EJB or a
>> resource?
>>
>> Or does a method annotated with @PostConstruct - once - run directly
>> after the Constructor call when the managed bean is initially
created?
>>
>>
> Here is the order:
>
> 1. New the bean declared using the default constructor
> 2. Inject any |_at_Resource| declarations
> 3. Assign any managed-properties declared, cascading this process
if
> new beans are referenced
> 4. Call |_at_PostConstruct| on the bean if declared
> 5. Store the bean in the correct scope and return
>
>
>
>
>> Thanks,
>>
>> --Todd
>>
>> -----Original Message-----
>> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
>> Sent: Wednesday, September 05, 2007 2:33 PM
>> To: users_at_javaserverfaces.dev.java.net
>> Subject: Re: Initial page loading: the managed bean doesn't inject
the
>>
>
>
>> EJB when called in the constructor.
>>
>> Todd Patrick wrote:
>>
>>
>>> Sun Java System Application Server Platform Edition 9.0_01 (build
>>> b02-p01)
>>> Sun's JavaServer Faces implementation (1.2_04-b10-p01) NetBeans
5.5.1
>>>
>>> When a page loads for the first time, the managed bean doesn't know
>>> about the injected EJB inside the constructor:
>>>
>>> public class RoutingRuleBean extends DeviceBasicBean implements
>>> Serializable { @EJB private RouteRuleSessionLocal
>>> routeRuleSessionLocal; ....
>>> public RoutingRuleBean() {
>>> ...
>>> if(!ObjectUtils.equals(this.selectedRouteDevcRowDetails, null)) {
>>> DeviceDetail selectedDeviceDetail =
>>>
routeRuleSessionLocal.getRouteDevcDetail(this.selectedRouteDevcRowDet
>>> a
>>> il
>>> s.getDeviceKey());
>>> this.device.setValue(selectedDeviceDetail);
>>> }
>>>
>>>
>>> In the snippet above, the field "routeRuleSessionLocal" holding the
>>> injected EJB is null inside the RoutingRuleBean constructor.
>>>
>>> So, the JSF Lifecycle is probably looking like - when a page loads
>>> for
>>>
>>>
>>
>>
>>> the first time:
>>>
>>> RESTORE_VIEW
>>>
>>> [constructor]
>>>
>>> RENDER_RESPONSE
>>>
>>>
>>> Thus, the injected EJB isn't called until the managed bean is
>>> completely initialized and pass the RENDER_RESPONSE phase.
>>>
>>> Looking at the Java EE API, I know of the PostConstruct annotation,
>>> but is there something that I could use before the constructor is
>>>
>>>
>> called?
>>
>>
>>>
>>>
>>>
>> Not in this case. The injection occurs on the actual instance, so
the
>>
>
>
>> ctor is always called first.
>> @PostConstuct is your best bet.
>>
>>
>>> Thanks,
>>>
>>> --Todd
>>>
>>>
>>> -----------------------------------------
>>> NOTICE: This email message is for the sole use of the intended
>>> recipient(s) and may contain confidential and privileged
information.
>>>
>
>
>>> Any unauthorized use, disclosure or distribution is prohibited. If
>>> you
>>>
>>>
>>
>>
>>> are not the intended recipient, please contact the sender by reply
>>> email and destroy all copies of the original message.
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail:
>>> users-help_at_javaserverfaces.dev.java.net
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
users-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail:
>> users-help_at_javaserverfaces.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
users-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail:
>> users-help_at_javaserverfaces.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail:
users-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail:
users-help_at_javaserverfaces.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net