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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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;<x-tad-smaller>Met vriendelijke groeten,
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.
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
smime.p7s
Description: S/MIME cryptographic signature
