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
>>>>
>>>>
>
smime.p7s
Description: S/MIME Cryptographic Signature
