I did look at that and it is a similar hack to what this specific 
ServletContextListener is doing, keeping a static reference to 
ServiceContext. I think sticking with the custom listener is better in 
this case because it has a specific purpose which is documented along 
with the correct way for new code.

-Eric

Jason Shao wrote:
>
> On Sep 25, 2007, at 1:44 PM, 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
>
> PortalSessionManager has a getInstance() method which lets you 
> statically access the GenericServlet's getServletContext() which is a 
> little cleaner from the perspective of not requiring anything more 
> than Spring's WebApplicationContextUtils.
>
> Having said that, I'm not sure that we want to introduce new 
> dependencies on PortalSessionManger and the whole infrastructure that 
> might make say reimplementing in WebMVC more difficult.
>
> Jason
>
> -- 
>
> Jason Shao
> Application Developer
> Rutgers University, Office of Instructional & Research Technology
> v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | 
> http://jay.shao.org
>
>
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to