It was primarily exporting and importing channel definitions that caused
me problems. Those processes required PersonDirectory - maybe only
because we use PAGS. PersonDirectory was configured to use jndi to get
datasource so I had to temporarily define the connection inside
PersonDirectory.xml.
Susan
Eric Dalquist wrote:
In the default checkout all of the tools still works. What your email
made me think of is doing chanpub work with PAGs configured since PAGs
will need PersonDirectory which is configured in the application
context. I'll give that a try later this week and see what solutions
other applications have used for this problem.
As more bits of the framework get moved into a Spring context this
problem starts to go away since any command line tool will need to
bootstrap the application context to access the instance of the tool to run.
Can you think of other tools/configurations that should get a more
in-depth look to make sure they work ok?
-Eric
Susan Bramhall wrote:
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 [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
