Will we still run certain "tools" outside the web context? If so, will
this approach handle that scenario too? For example importing and
exporting objects, initializing the database.
Susan
Eric Dalquist wrote:
I ended up following the static locater pattern which is similar to
Spring's WebApplicationContextUtils class but does not require a
ServletContext to get at the WebApplicationContext. These changes are in
SVN so now there is a single loaded WebApplicationContext that follows
the web-application's life-cycle correctly. All .xml files in the
properties/contexts/ directory are loaded into the
WebApplicationContext. With this change reloading the uPortal context
seems to work correctly which is another step forward.
On to the next task!
-Eric
Eric Dalquist wrote:
Thats a good approach too, I might look into creating a utility bean to
do that injection that also inject a null when the context is shutting
down. Making sure the solution works nicely with spring context and
servlet context reloads which cause problems right now. I'm thinking the
injecting a null would work with this model to fit the reloads requirement.
-Eric
Drew Wills wrote:
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
--
It's no use trying to be clever--we are all clever here; just try to be kind--a
little kind.
-- F.J. Foakes Jackson
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
