Re: [uportal-dev] Spring context consolidation
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 -- 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
Re: [uportal-dev] Spring context consolidation
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
Re: [uportal-dev] Spring context consolidation
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
Re: [uportal-dev] Spring context consolidation
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
Re: [uportal-dev] Spring context consolidation
Drew Wills wrote: ++ BeansML: bean id=personDirectoryService factory-method=setPersonAttributeDao constructor-arg ref bean=personAttributeDao/ constructor-arg /bean Sorry, should be more like: bean id=personDirectoryService class=org.jasig.portal.services.PersonDirectory factory-method=setPersonAttributeDao constructor-arg ref bean=personAttributeDao/ /constructor-arg /bean drew -- Andrew Wills UNICON, Inc. Office: (480) 558-2476 http://code.google.com/p/cernunnos/ -- 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