Re: [uportal-dev] Spring context consolidation
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 > > > smime.p7s Description: S/MIME Cryptographic Signature
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
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:
factory-method="setPersonAttributeDao">
*
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
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:
>>> factory-method="setPersonAttributeDao">
*
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
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:
*
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
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:
>>
>>
>>
>>
>>
>>
>>
>> *
>>
>> 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
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:
>
>
>
>
>
>
>
> *
>
> 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: Sorry, should be more like: class="org.jasig.portal.services.PersonDirectory" factory-method="setPersonAttributeDao"> 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
Re: [uportal-dev] Spring context consolidation
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:
*
This should cause the bean container to inject the normal
'personAttributeDao' into the staticly-accessed PersonDirectory service
to support legacy code.
drew wills
--
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
[uportal-dev] Spring context consolidation
I'm starting work on consolidating the Spring configuration files and switching to standard ways of loading and accessing the context XML. My plan is to create a properties/contexts/ folder that all Spring context XML files reside in. The context files will be loaded by a ContextLoaderListener into a single WebApplicationContext. The WebApplicationContext is then accessible via the WebApplicationContextUtils class which requires a reference to the ServletContext object for loading. The ContextLoaderListener and WebApplicationContextUtils classes are replacing a custom PortalApplicationContextFacade class which loads /properties/beanRefFactory.xml and provides static method accessors to the loaded BeanFactory. 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. My one idea right now is to add a custom ServletContextListener that listens for start/stop events and holds a static reference to the ServletContext and internally uses WebApplicationContextUtils to service static request for the WebApplicationContext. This should still deal with the Spring context getting reloaded and the Servlet context getting reloaded. I would also like to make it deprecated from the get-go to discourage usage of this pattern. -Eric smime.p7s Description: S/MIME Cryptographic Signature
