Eric Dalquist wrote:
...
The problem is in some places that the PortalApplicationContextFacade is
used to access the BeanFactory there is no access to a ServletContext
which the WebApplicationContextUtils needs to access the replacement
WebApplicationContext.
The affected areas are:
CError - constructor, loads a IThrowableToElement implementation which
defines ways to render certain exceptions
PersonDirectory - getPersonAttributeDao, loads the root
IPersonAttributeDao for use by other parts of the framework. This method
is called from: Authentication, PersonAttributeGroupStore,
CPersonAttributes, and PersonDirNameFinder
I'm not sure what the best solution for this is. I'd like to avoid as
much custom Spring related code as possible but we may still need a
static accessor that doesn't require the ServletContext to access the
WebApplicationContext object.
Eric,
What about an approach like this (example from PersonDirectory)...
*****
++ Java:
public class PersonDirectory {
private static IPersonAttributeDao impl;
public static Object setPersonAttributeDao(IPersonAttributeDao dao) {
impl = dao;
return PersonDirectory.class; // shouldn't matter what's returned
}
...
}
++ BeansML:
<bean id="personDirectoryService" factory-method="setPersonAttributeDao">
<constructor-arg>
<ref bean="personAttributeDao"/>
<constructor-arg>
</bean>
*****
This should cause the bean container to inject the normal
'personAttributeDao' into the staticly-accessed PersonDirectory service
to support legacy code.
drew wills
--
Andrew Wills
UNICON, Inc.
Office: (480) 558-2476
http://code.google.com/p/cernunnos/
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
