You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Guy Katz <gk...@allot.com> on 2005/08/28 13:23:16 UTC
managed beans creation facility question
hi;
i have many applicataion scope managed beans that act as a cache.
up until now, creating them lazily through the managed bean creation facility was fine.
as my application grew bigger i noticed it was better to have these beans populated on startup.
the problem began when i noticed the managed bean creation facility only supports lazy creation.
i had to leave the managed bean creation facility (which i love) and go with a servlet context listener instead.
can someone please explain the rational of not providing an 'application scope beans creation on startup' functionality build into the managed bean creation facility of JSF?
thanks.
Re: managed beans creation facility question
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
thx, Craig!
On 29 Aug 2005, at 0:02, Craig McClanahan wrote:
> On 8/28/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>> Good point, I think, and no, I can't think of a rationale.
>>
>
> The key issue is that expression evaluation occurs with respect to a
> context ... specifically, the FacesContext for the current request,
> which contains internal references to (in a webapp) a ServletContext,
> a ServletRequest, and a ServletResponse. There can't be such a "real"
> object at application startup time, because there is no request in
> place.
>
>> You could work around the limitation by initializing the objects you
>> need in a servlet context listener though, and store them in
>> application scope yourself. You are not using the managed bean (~ IoC)
>> mechanism then though.
>>
>> If, however, you just access the VariableResolver in your context
>> listener, the beans get initialized and get stored in the scope they
>> are defined for.
>>
>
> That won't necessarily be sufficient if your managed bean declaration
> has managed properties that are also initialized via value binding
> expressions. The JSF framework will be applying its usual expression
> evaluation facilities to that kind of an expression.
>
> An alternative that might work, though, is to construct a mock
> ExternalContext with only the ServletContext object, and no request
> and response, and then construct a mock FacesContext wrapping that.
> You should be able to evaluate expressions that don't attempt to
> access things from request or session scope.
>
> Craig
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: managed beans creation facility question
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/28/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> Good point, I think, and no, I can't think of a rationale.
>
The key issue is that expression evaluation occurs with respect to a
context ... specifically, the FacesContext for the current request,
which contains internal references to (in a webapp) a ServletContext,
a ServletRequest, and a ServletResponse. There can't be such a "real"
object at application startup time, because there is no request in
place.
> You could work around the limitation by initializing the objects you
> need in a servlet context listener though, and store them in
> application scope yourself. You are not using the managed bean (~ IoC)
> mechanism then though.
>
> If, however, you just access the VariableResolver in your context
> listener, the beans get initialized and get stored in the scope they
> are defined for.
>
That won't necessarily be sufficient if your managed bean declaration
has managed properties that are also initialized via value binding
expressions. The JSF framework will be applying its usual expression
evaluation facilities to that kind of an expression.
An alternative that might work, though, is to construct a mock
ExternalContext with only the ServletContext object, and no request
and response, and then construct a mock FacesContext wrapping that.
You should be able to evaluate expressions that don't attempt to
access things from request or session scope.
Craig
Re: managed beans creation facility question
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
Good point, I think, and no, I can't think of a rationale.
You could work around the limitation by initializing the objects you
need in a servlet context listener though, and store them in
application scope yourself. You are not using the managed bean (~ IoC)
mechanism then though.
If, however, you just access the VariableResolver in your context
listener, the beans get initialized and get stored in the scope they
are defined for.
Here is code we use for that:
/**
* The current {@link FacesContext}. Exception if <code>null</code>.
*
* @returns FacesContext.getCurrentInstance();
* @result FacesContext.getCurrentInstance() != null;
* @throws FatalFacesException
* FacesContext.getCurrentInstance() == null;
*/
public static FacesContext facesContext() throws FatalFacesException {
FacesContext result = FacesContext.getCurrentInstance();
if (result == null) {
fatalProblem("no faces context found");
}
return result;
}
/**
* The current {@link Application}. Exception if <code>null</code>.
*
* @returns facesContext().getApplication();
* @result facesContext().getApplication() != null;
* @except facesContext();
* @throws FatalFacesException
* facesContext().getApplication() == null;
*/
public static Application application() throws FatalFacesException {
Application result = facesContext().getApplication();
if (result == null) {
fatalProblem("no faces application instance found");
}
return result;
}
/**
* The current {@link VariableResolver}
* This cannot be <code>null</code>.
*
* @return application().getVariableResolver();
* @except application();
*/
public static VariableResolver variableResolver() throws
FatalFacesException {
VariableResolver result = application().getVariableResolver();
assert result != null;
return result;
}
/**
* Retrieve the variable with name <code>variableName</code>.
* This will create managed beans if needed. If the name cannot be
resolved,
* <code>null</code> is returned.
*
* @return application().getVariableResolver();
* @except application();
* @throws FatalFacesException
* An exception occured when resolving
<code>variableName</code>.
*/
public static Object resolve(String variableName) throws
FatalFacesException {
Object result = null;
try {
result = variableResolver().resolveVariable(facesContext(),
variableName);
}
catch (EvaluationException eExc) {
fatalProblem("Exception resolving variable with name \"" +
variableName + "\"", eExc);
}
return result;
}
On 28 Aug 2005, at 13:23, Guy Katz wrote:
> hi;
> i have many applicataion scope managed beans that act as a cache.
> up until now, creating them lazily through the managed bean creation
> facility was fine.
> as my application grew bigger i noticed it was better to have these
> beans populated on startup.
> the problem began when i noticed the managed bean creation facility
> only supports lazy creation.
> i had to leave the managed bean creation facility (which i love) and
> go with a servlet context listener instead.
>
> can someone please explain the rational of not providing an
> 'application scope beans creation on startup' functionality build into
> the managed bean creation facility of JSF?
> thanks.
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/