You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wes Wannemacher <we...@wantii.com> on 2011/02/10 17:43:19 UTC
getting the container (or Configuration/ConfigurationManager) in a
non-container-instantiated object
Guys,
I am in a non-struts environment (spring class, loaded by a customer
ServletContextListener), and I am trying to get my hands on the Struts
2 configuration. I first tried to do -
Dispatcher.getInstance().getContainer()
But, the dispatcher instance is a threadlocal. I don't really care
about the dispatcher, I'd just like to get a ref to the container.
Any ideas?
-Wes
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: getting the container (or Configuration/ConfigurationManager)
in a non-container-instantiated object
Posted by Martin Gainty <mg...@hotmail.com>.
register ConfigurableListableBeanFactory, ServletContext and ServletConfig objects with
org.springframework.web.context.support.WebApplicationContextUtils.registerEnvironmentBeans(bf,sc,config)
once inside registerEnvironmentBeans method bith the servletContext and servletConfig parameters will register as Singletons:
if (sc != null && !bf.containsBean(WebApplicationContext.SERVLET_CONTEXT_BEAN_NAME)) {
bf.registerSingleton(WebApplicationContext.SERVLET_CONTEXT_BEAN_NAME, sc);
}
if (config != null && !bf.containsBean(ConfigurableWebApplicationContext.SERVLET_CONFIG_BEAN_NAME)) {
bf.registerSingleton(ConfigurableWebApplicationContext.SERVLET_CONFIG_BEAN_NAME, config);
}
implemented in org.springframework.web.context.support.GenericWebApplicationContext here:
public class GenericWebApplicationContext extends GenericApplicationContext implements WebApplicationContext, ThemeSource {
/**
* Register ServletContextAwareProcessor.
* @see ServletContextAwareProcessor
*called after setBeanFactory()
*called before afterPropertiesSet()
http://www.javabeat.net/articles/49-life-cycle-management-of-a-spring-bean-1.html
*/
@Override
protected void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
beanFactory.addBeanPostProcessor(new ServletContextAwareProcessor(this.servletContext));
beanFactory.ignoreDependencyInterface(ServletContextAware.class);
WebApplicationContextUtils.registerWebApplicationScopes(beanFactory, this.servletContext);
WebApplicationContextUtils.registerEnvironmentBeans(beanFactory, this.servletContext);
}
does this help?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Thu, 10 Feb 2011 11:43:19 -0500
> Subject: getting the container (or Configuration/ConfigurationManager) in a non-container-instantiated object
> From: wesw@wantii.com
> To: dev@struts.apache.org
>
> Guys,
>
> I am in a non-struts environment (spring class, loaded by a customer
> ServletContextListener), and I am trying to get my hands on the Struts
> 2 configuration. I first tried to do -
>
> Dispatcher.getInstance().getContainer()
>
> But, the dispatcher instance is a threadlocal. I don't really care
> about the dispatcher, I'd just like to get a ref to the container.
>
> Any ideas?
>
> -Wes
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
Chris,
That is exactly what I see.
Does anyone have a problem with changing the declaration of the
Dispatcher instance, and providing some visibility of the Dispatcher
instance (such as shoving it into the ApplicationContext)?
-Wes
On Tue, Feb 15, 2011 at 8:48 AM, musomesa <mu...@aol.com> wrote:
> Hi Wes,
> Here is what I see:
>
> StrutsPrepareFilter init method:
> creates InitOperations init
> calls init.initDispatcher
> initDispatcher calls createDispatcher
> which returns a new Dispatcher
> The new Dispatcher is given to PrepareOperations's constructor which store
> is in its Dispatcher field
> =====
>
> StrutsPrepareFilter doFilter method:
> calls prepare.assignDispatcherToThread()
> which calls Dispatcher.setInstance(dispatcher)
> here dispatcher is the field created as StrutsPrepareFilter's init
> method ran
> It (the dispatcher) is stored in the ThreadLocal field of Dispatcher
>
> =====
>
> In the private Dispatcher field of PrepareOperations is the same as the
> ThreadLocal<Dispatcher>
> in the Dispatcher. I think the intent was visibility so the that the client
> thread can access it
> but then there can't be any thread safety issues as it is already shared so
> it could as well
> be static (?)
>
> Cheers
> Chris
>
> On 2/14/2011 4:34 PM, Wes Wannemacher wrote:
>>
>> Sorry to keep coming back to this guys, but I'm still mulling over this...
>>
>> If any of you get the chance, can you look over StrutsPrepareFilter,
>> InitOperations, PrepareOperations and StrutsExecuteFilter and tell me
>> that a single Dispatcher instance isn't simply shared across all of a
>> web-app's lifecycle? If I'm right, and the ThreadLocal<Dispatcher>
>> declaration is pointless, then that will make it pretty easy for me to
>> subclass one of the filters to make the Dispatcher visible.
>>
>> Thanks!
>>
>> -Wes
>>
>> On Fri, Feb 11, 2011 at 5:30 PM, Wes Wannemacher<we...@wantii.com> wrote:
>>>
>>> Rene,
>>>
>>> Thanks for the pointer...
>>>
>>> I guess i still have a few concerns about some of this. I am starting
>>> to feel like the king of having things that I want to do to struts,
>>> but never finding the time to do them. If only I could make some money
>>> w/o being expected to fulfill customer demands ;-)
>>>
>>> I know Don set out a while ago to refactor the Dispatcher and the
>>> FilterDispatcher and we have Prepare/Execute filters and
>>> Prepare/Execute operations. Which I think is pretty cool, but one
>>> thing I still can't seem to find is what the scope of the Dispatcher
>>> and of some of the objects that the Dispatcher uses. So, it is pretty
>>> clear that the Dispatcher instance is a Threadlocal, but it looks like
>>> the Dispatcher is instantiated in the InitOperations. What is unclear
>>> to me is that it looks like this happens in (looking at the filters,
>>> not the listener or servlet) in the public void init(FilterConfig) of
>>> StrutsPrepareFilter, which is run once (right?). So, is a Dispatcher
>>> singleton simply passed around?
>>>
>>> Looking at InitOperations, it would seem like if this were run for
>>> each request (which I am pretty sure it is not), then it would
>>> reinitialize the framework with each request.
>>>
>>> So, my questions are as follows -
>>>
>>> 1. Is this optimal? I could be wrong, but I thought a Dispatcher
>>> instance was created per-thread... I think I thought so because
>>> Dispatcher.instance is a threadlocal. None of the other properties in
>>> the dispatcher are declared static (they are all instance properties).
>>> I've never really read up much on threadlocals, so if my understanding
>>> is completely flawed (and showing right now) then I apologize.
>>>
>>> 2. Should we consider refactoring some of this again? I like the
>>> design, but I feel like we broke out the stuff that should happen
>>> before execution, then execution itself, but it doesn't feel very
>>> IoC-ish. *Operations could maybe be servicified so that we could maybe
>>> make some of this stuff happen as a matter of wiring/configuration
>>> rather than simply just being broken up.
>>>
>>> 3. If I am right that Dispatcher is a singleton, then my original
>>> problem is really just a matter of visibility. Am I the only one that
>>> has ever wanted a reference to the container outside of the framework?
>>> If the Dispatcher is a singleton, would anyone object to having it in
>>> the ServletContext as an attribute? I suppose I could create an
>>> alternate Prepare or Execute filter that inherits from one of the
>>> originals and make the stuff I want visible.
>>>
>>> I don't know if any of this needs any action right now, but one thing
>>> that kind of bugs me about struts right now is that in Don's absence,
>>> I'd like to feel like we, as a team, have a good understanding of how
>>> the Dispatcher does its magic... I don't want to speak for everyone,
>>> but right now i feel like I do *not* have a good understanding.
>>>
>>> Thoughts?
>>>
>>> -Wes
>>>
>>> On Fri, Feb 11, 2011 at 5:21 AM, Rene Gielen<gi...@it-neering.net>
>>> wrote:
>>>>
>>>> You need to get hands on the Dispatcher, it hold the correct (even after
>>>> reloading ...) reference to the Container.
>>>> While StrutsPrepareFilter initializes the Dispatcher, it does not expose
>>>> it
>>>> the the ServletContext. Actually, if you look into
>>>> StrutsListener.contextInitialized(), you find what you are looking for.
>>>> Nevertheless, from a short glance it does not look like they play nice
>>>> together. AFAICS StrutsPrepareFilter should be modified the following
>>>> way:
>>>> in the init method, look if ServletContext contains a Dispatcher for
>>>> attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
>>>> configured). If found - use it. If not, create it and expose it under
>>>> the
>>>> said attribute key
>>>>
>>>> We should review if configuring Listener and Filter together do make
>>>> sense,
>>>> and if yes, if they need better interaction - especially for
>>>> prepareOperations.
>>>>
>>>> - René
>>>>
>>>
>>>
>>> --
>>> Wes Wannemacher
>>>
>>> Head Engineer, WanTii, Inc.
>>> Need Training? Struts, Spring, Maven, Tomcat...
>>> Ask me for a quote!
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager)
in a non-container-instantiated object
Posted by musomesa <mu...@aol.com>.
Hi Wes,
Here is what I see:
StrutsPrepareFilter init method:
creates InitOperations init
calls init.initDispatcher
initDispatcher calls createDispatcher
which returns a new Dispatcher
The new Dispatcher is given to PrepareOperations's constructor which
store is in its Dispatcher field
=====
StrutsPrepareFilter doFilter method:
calls prepare.assignDispatcherToThread()
which calls Dispatcher.setInstance(dispatcher)
here dispatcher is the field created as StrutsPrepareFilter's
init method ran
It (the dispatcher) is stored in the ThreadLocal field of Dispatcher
=====
In the private Dispatcher field of PrepareOperations is the same as the
ThreadLocal<Dispatcher>
in the Dispatcher. I think the intent was visibility so the that the
client thread can access it
but then there can't be any thread safety issues as it is already shared
so it could as well
be static (?)
Cheers
Chris
On 2/14/2011 4:34 PM, Wes Wannemacher wrote:
> Sorry to keep coming back to this guys, but I'm still mulling over this...
>
> If any of you get the chance, can you look over StrutsPrepareFilter,
> InitOperations, PrepareOperations and StrutsExecuteFilter and tell me
> that a single Dispatcher instance isn't simply shared across all of a
> web-app's lifecycle? If I'm right, and the ThreadLocal<Dispatcher>
> declaration is pointless, then that will make it pretty easy for me to
> subclass one of the filters to make the Dispatcher visible.
>
> Thanks!
>
> -Wes
>
> On Fri, Feb 11, 2011 at 5:30 PM, Wes Wannemacher<we...@wantii.com> wrote:
>> Rene,
>>
>> Thanks for the pointer...
>>
>> I guess i still have a few concerns about some of this. I am starting
>> to feel like the king of having things that I want to do to struts,
>> but never finding the time to do them. If only I could make some money
>> w/o being expected to fulfill customer demands ;-)
>>
>> I know Don set out a while ago to refactor the Dispatcher and the
>> FilterDispatcher and we have Prepare/Execute filters and
>> Prepare/Execute operations. Which I think is pretty cool, but one
>> thing I still can't seem to find is what the scope of the Dispatcher
>> and of some of the objects that the Dispatcher uses. So, it is pretty
>> clear that the Dispatcher instance is a Threadlocal, but it looks like
>> the Dispatcher is instantiated in the InitOperations. What is unclear
>> to me is that it looks like this happens in (looking at the filters,
>> not the listener or servlet) in the public void init(FilterConfig) of
>> StrutsPrepareFilter, which is run once (right?). So, is a Dispatcher
>> singleton simply passed around?
>>
>> Looking at InitOperations, it would seem like if this were run for
>> each request (which I am pretty sure it is not), then it would
>> reinitialize the framework with each request.
>>
>> So, my questions are as follows -
>>
>> 1. Is this optimal? I could be wrong, but I thought a Dispatcher
>> instance was created per-thread... I think I thought so because
>> Dispatcher.instance is a threadlocal. None of the other properties in
>> the dispatcher are declared static (they are all instance properties).
>> I've never really read up much on threadlocals, so if my understanding
>> is completely flawed (and showing right now) then I apologize.
>>
>> 2. Should we consider refactoring some of this again? I like the
>> design, but I feel like we broke out the stuff that should happen
>> before execution, then execution itself, but it doesn't feel very
>> IoC-ish. *Operations could maybe be servicified so that we could maybe
>> make some of this stuff happen as a matter of wiring/configuration
>> rather than simply just being broken up.
>>
>> 3. If I am right that Dispatcher is a singleton, then my original
>> problem is really just a matter of visibility. Am I the only one that
>> has ever wanted a reference to the container outside of the framework?
>> If the Dispatcher is a singleton, would anyone object to having it in
>> the ServletContext as an attribute? I suppose I could create an
>> alternate Prepare or Execute filter that inherits from one of the
>> originals and make the stuff I want visible.
>>
>> I don't know if any of this needs any action right now, but one thing
>> that kind of bugs me about struts right now is that in Don's absence,
>> I'd like to feel like we, as a team, have a good understanding of how
>> the Dispatcher does its magic... I don't want to speak for everyone,
>> but right now i feel like I do *not* have a good understanding.
>>
>> Thoughts?
>>
>> -Wes
>>
>> On Fri, Feb 11, 2011 at 5:21 AM, Rene Gielen<gi...@it-neering.net> wrote:
>>> You need to get hands on the Dispatcher, it hold the correct (even after
>>> reloading ...) reference to the Container.
>>> While StrutsPrepareFilter initializes the Dispatcher, it does not expose it
>>> the the ServletContext. Actually, if you look into
>>> StrutsListener.contextInitialized(), you find what you are looking for.
>>> Nevertheless, from a short glance it does not look like they play nice
>>> together. AFAICS StrutsPrepareFilter should be modified the following way:
>>> in the init method, look if ServletContext contains a Dispatcher for
>>> attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
>>> configured). If found - use it. If not, create it and expose it under the
>>> said attribute key
>>>
>>> We should review if configuring Listener and Filter together do make sense,
>>> and if yes, if they need better interaction - especially for
>>> prepareOperations.
>>>
>>> - René
>>>
>>
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
Sorry to keep coming back to this guys, but I'm still mulling over this...
If any of you get the chance, can you look over StrutsPrepareFilter,
InitOperations, PrepareOperations and StrutsExecuteFilter and tell me
that a single Dispatcher instance isn't simply shared across all of a
web-app's lifecycle? If I'm right, and the ThreadLocal<Dispatcher>
declaration is pointless, then that will make it pretty easy for me to
subclass one of the filters to make the Dispatcher visible.
Thanks!
-Wes
On Fri, Feb 11, 2011 at 5:30 PM, Wes Wannemacher <we...@wantii.com> wrote:
> Rene,
>
> Thanks for the pointer...
>
> I guess i still have a few concerns about some of this. I am starting
> to feel like the king of having things that I want to do to struts,
> but never finding the time to do them. If only I could make some money
> w/o being expected to fulfill customer demands ;-)
>
> I know Don set out a while ago to refactor the Dispatcher and the
> FilterDispatcher and we have Prepare/Execute filters and
> Prepare/Execute operations. Which I think is pretty cool, but one
> thing I still can't seem to find is what the scope of the Dispatcher
> and of some of the objects that the Dispatcher uses. So, it is pretty
> clear that the Dispatcher instance is a Threadlocal, but it looks like
> the Dispatcher is instantiated in the InitOperations. What is unclear
> to me is that it looks like this happens in (looking at the filters,
> not the listener or servlet) in the public void init(FilterConfig) of
> StrutsPrepareFilter, which is run once (right?). So, is a Dispatcher
> singleton simply passed around?
>
> Looking at InitOperations, it would seem like if this were run for
> each request (which I am pretty sure it is not), then it would
> reinitialize the framework with each request.
>
> So, my questions are as follows -
>
> 1. Is this optimal? I could be wrong, but I thought a Dispatcher
> instance was created per-thread... I think I thought so because
> Dispatcher.instance is a threadlocal. None of the other properties in
> the dispatcher are declared static (they are all instance properties).
> I've never really read up much on threadlocals, so if my understanding
> is completely flawed (and showing right now) then I apologize.
>
> 2. Should we consider refactoring some of this again? I like the
> design, but I feel like we broke out the stuff that should happen
> before execution, then execution itself, but it doesn't feel very
> IoC-ish. *Operations could maybe be servicified so that we could maybe
> make some of this stuff happen as a matter of wiring/configuration
> rather than simply just being broken up.
>
> 3. If I am right that Dispatcher is a singleton, then my original
> problem is really just a matter of visibility. Am I the only one that
> has ever wanted a reference to the container outside of the framework?
> If the Dispatcher is a singleton, would anyone object to having it in
> the ServletContext as an attribute? I suppose I could create an
> alternate Prepare or Execute filter that inherits from one of the
> originals and make the stuff I want visible.
>
> I don't know if any of this needs any action right now, but one thing
> that kind of bugs me about struts right now is that in Don's absence,
> I'd like to feel like we, as a team, have a good understanding of how
> the Dispatcher does its magic... I don't want to speak for everyone,
> but right now i feel like I do *not* have a good understanding.
>
> Thoughts?
>
> -Wes
>
> On Fri, Feb 11, 2011 at 5:21 AM, Rene Gielen <gi...@it-neering.net> wrote:
>> You need to get hands on the Dispatcher, it hold the correct (even after
>> reloading ...) reference to the Container.
>> While StrutsPrepareFilter initializes the Dispatcher, it does not expose it
>> the the ServletContext. Actually, if you look into
>> StrutsListener.contextInitialized(), you find what you are looking for.
>> Nevertheless, from a short glance it does not look like they play nice
>> together. AFAICS StrutsPrepareFilter should be modified the following way:
>> in the init method, look if ServletContext contains a Dispatcher for
>> attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
>> configured). If found - use it. If not, create it and expose it under the
>> said attribute key
>>
>> We should review if configuring Listener and Filter together do make sense,
>> and if yes, if they need better interaction - especially for
>> prepareOperations.
>>
>> - René
>>
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
Rene,
Thanks for the pointer...
I guess i still have a few concerns about some of this. I am starting
to feel like the king of having things that I want to do to struts,
but never finding the time to do them. If only I could make some money
w/o being expected to fulfill customer demands ;-)
I know Don set out a while ago to refactor the Dispatcher and the
FilterDispatcher and we have Prepare/Execute filters and
Prepare/Execute operations. Which I think is pretty cool, but one
thing I still can't seem to find is what the scope of the Dispatcher
and of some of the objects that the Dispatcher uses. So, it is pretty
clear that the Dispatcher instance is a Threadlocal, but it looks like
the Dispatcher is instantiated in the InitOperations. What is unclear
to me is that it looks like this happens in (looking at the filters,
not the listener or servlet) in the public void init(FilterConfig) of
StrutsPrepareFilter, which is run once (right?). So, is a Dispatcher
singleton simply passed around?
Looking at InitOperations, it would seem like if this were run for
each request (which I am pretty sure it is not), then it would
reinitialize the framework with each request.
So, my questions are as follows -
1. Is this optimal? I could be wrong, but I thought a Dispatcher
instance was created per-thread... I think I thought so because
Dispatcher.instance is a threadlocal. None of the other properties in
the dispatcher are declared static (they are all instance properties).
I've never really read up much on threadlocals, so if my understanding
is completely flawed (and showing right now) then I apologize.
2. Should we consider refactoring some of this again? I like the
design, but I feel like we broke out the stuff that should happen
before execution, then execution itself, but it doesn't feel very
IoC-ish. *Operations could maybe be servicified so that we could maybe
make some of this stuff happen as a matter of wiring/configuration
rather than simply just being broken up.
3. If I am right that Dispatcher is a singleton, then my original
problem is really just a matter of visibility. Am I the only one that
has ever wanted a reference to the container outside of the framework?
If the Dispatcher is a singleton, would anyone object to having it in
the ServletContext as an attribute? I suppose I could create an
alternate Prepare or Execute filter that inherits from one of the
originals and make the stuff I want visible.
I don't know if any of this needs any action right now, but one thing
that kind of bugs me about struts right now is that in Don's absence,
I'd like to feel like we, as a team, have a good understanding of how
the Dispatcher does its magic... I don't want to speak for everyone,
but right now i feel like I do *not* have a good understanding.
Thoughts?
-Wes
On Fri, Feb 11, 2011 at 5:21 AM, Rene Gielen <gi...@it-neering.net> wrote:
> You need to get hands on the Dispatcher, it hold the correct (even after
> reloading ...) reference to the Container.
> While StrutsPrepareFilter initializes the Dispatcher, it does not expose it
> the the ServletContext. Actually, if you look into
> StrutsListener.contextInitialized(), you find what you are looking for.
> Nevertheless, from a short glance it does not look like they play nice
> together. AFAICS StrutsPrepareFilter should be modified the following way:
> in the init method, look if ServletContext contains a Dispatcher for
> attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
> configured). If found - use it. If not, create it and expose it under the
> said attribute key
>
> We should review if configuring Listener and Filter together do make sense,
> and if yes, if they need better interaction - especially for
> prepareOperations.
>
> - René
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in a
non-container-instantiated object
Posted by Rene Gielen <gi...@it-neering.net>.
You need to get hands on the Dispatcher, it hold the correct (even after
reloading ...) reference to the Container.
While StrutsPrepareFilter initializes the Dispatcher, it does not expose it
the the ServletContext. Actually, if you look into
StrutsListener.contextInitialized(), you find what you are looking for.
Nevertheless, from a short glance it does not look like they play nice
together. AFAICS StrutsPrepareFilter should be modified the following way:
in the init method, look if ServletContext contains a Dispatcher for
attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
configured). If found - use it. If not, create it and expose it under the
said attribute key
We should review if configuring Listener and Filter together do make sense,
and if yes, if they need better interaction - especially for
prepareOperations.
- René
On Thu, 10 Feb 2011 15:57:06 -0500, Wes Wannemacher <we...@wantii.com>
wrote:
> Let me put the whole thing a bit differently...
>
> Does anyone know of a way to get a reference to the Container (or
> ConfigurationManager or Configuration) from within -
>
> ServletContextListener.contextInitialized(ServletContextEvent sce)
>
> Or, maybe I could refactor some stuff and do it within -
>
> Servlet.init(ServletConfig config)
>
> I was hoping for some way to grab a hold of one of the filters
> (Prepare or Execute) and yanking the Container out of there, but I
> can't seem to find a good way to get at it, outside of Struts but
> within a web-app.
>
> -Wes
>
> On Thu, Feb 10, 2011 at 3:15 PM, Wes Wannemacher <we...@wantii.com> wrote:
>> This isn't a request thread... It is spawned from a
>> ServletContextListener.
>>
>> I am still playing around, I have a ServletContext object right now
>> (in the debugger) and I'm seeing if I can get the container from
>> there.
>>
>> I'll check out Ben's solution and see if that helps.
>>
>> -Wes
>>
>> On Thu, Feb 10, 2011 at 2:43 PM, John Lindal <li...@yahoo-inc.com>
>> wrote:
>>> The simplest solution - if it's possible - is to make the spawned
thread
>>> a parent of the request thread, and then grab what you need from the
>>> parent thread as soon as the child thread starts.
>>>
>>> Does Struts2 use InheritableThreadLocal? If it did, this would be
even
>>> easier.
>>>
>>> John
>>>
>>>
>>> On 2/10/11 11:02 AM, "Wes Wannemacher" <we...@wantii.com> wrote:
>>>
>>> Because, I'm not in a request-processing thread...
>>>
>>> In this app, I have a ServletContextListener that launches threads for
>>> managing some housekeeping stuff (in this case, looking for specific
>>> xml files in jars). I need the configured packages (PackageConfigs)
>>> within one of these threads.
>>>
>>> I did try to get the Dispatcher instance, but it kept coming back
>>> null, which led me to dig a bit and then I realized that I am not in a
>>> request processing thread (neither is the ServletContextListener that
>>> launched the thread). I am going to try to poke around the
>>> ServletContext to see if I can get the container that way.
>>>
>>> -Wes
>>>
>>> On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
>>> <ma...@gmail.com> wrote:
>>>> Wes,
>>>> to be frankly I didn't get what you said.
>>>>
>>>> Dispatcher.getInstance().getContainer() should be yield a container
>>>> reference (among the other things it's the better way a know in order
>>>> to do that).
>>>>
>>>> What's the problem with the threadlocal stuff?
>>>>
>>>> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
>>>>> Guys,
>>>>>
>>>>> I am in a non-struts environment (spring class, loaded by a customer
>>>>> ServletContextListener), and I am trying to get my hands on the
Struts
>>>>> 2 configuration. I first tried to do -
>>>>>
>>>>> Dispatcher.getInstance().getContainer()
>>>>>
>>>>> But, the dispatcher instance is a threadlocal. I don't really care
>>>>> about the dispatcher, I'd just like to get a ref to the container.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> -Wes
>>>>>
>>>>> --
>>>>> Wes Wannemacher
>>>>>
>>>>> Head Engineer, WanTii, Inc.
>>>>> Need Training? Struts, Spring, Maven, Tomcat...
>>>>> Ask me for a quote!
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Maurizio Cucchiara
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Wes Wannemacher
>>>
>>> Head Engineer, WanTii, Inc.
>>> Need Training? Struts, Spring, Maven, Tomcat...
>>> Ask me for a quote!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Ben McCann <bm...@google.com>.
Actually, after taking a closer look, that file's not going to help you at
all. I'd forgotten what we did exactly. I asked the same question awhile
back and now I'm remembering that I never found a solution and gave up on
it, so I'd love to know if you figure it out.
On Thu, Feb 10, 2011 at 12:57 PM, Wes Wannemacher <we...@wantii.com> wrote:
> Let me put the whole thing a bit differently...
>
> Does anyone know of a way to get a reference to the Container (or
> ConfigurationManager or Configuration) from within -
>
> ServletContextListener.contextInitialized(ServletContextEvent sce)
>
> Or, maybe I could refactor some stuff and do it within -
>
> Servlet.init(ServletConfig config)
>
> I was hoping for some way to grab a hold of one of the filters
> (Prepare or Execute) and yanking the Container out of there, but I
> can't seem to find a good way to get at it, outside of Struts but
> within a web-app.
>
> -Wes
>
> On Thu, Feb 10, 2011 at 3:15 PM, Wes Wannemacher <we...@wantii.com> wrote:
> > This isn't a request thread... It is spawned from a
> ServletContextListener.
> >
> > I am still playing around, I have a ServletContext object right now
> > (in the debugger) and I'm seeing if I can get the container from
> > there.
> >
> > I'll check out Ben's solution and see if that helps.
> >
> > -Wes
> >
> > On Thu, Feb 10, 2011 at 2:43 PM, John Lindal <li...@yahoo-inc.com>
> wrote:
> >> The simplest solution - if it's possible - is to make the spawned thread
> a parent of the request thread, and then grab what you need from the parent
> thread as soon as the child thread starts.
> >>
> >> Does Struts2 use InheritableThreadLocal? If it did, this would be even
> easier.
> >>
> >> John
> >>
> >>
> >> On 2/10/11 11:02 AM, "Wes Wannemacher" <we...@wantii.com> wrote:
> >>
> >> Because, I'm not in a request-processing thread...
> >>
> >> In this app, I have a ServletContextListener that launches threads for
> >> managing some housekeeping stuff (in this case, looking for specific
> >> xml files in jars). I need the configured packages (PackageConfigs)
> >> within one of these threads.
> >>
> >> I did try to get the Dispatcher instance, but it kept coming back
> >> null, which led me to dig a bit and then I realized that I am not in a
> >> request processing thread (neither is the ServletContextListener that
> >> launched the thread). I am going to try to poke around the
> >> ServletContext to see if I can get the container that way.
> >>
> >> -Wes
> >>
> >> On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
> >> <ma...@gmail.com> wrote:
> >>> Wes,
> >>> to be frankly I didn't get what you said.
> >>>
> >>> Dispatcher.getInstance().getContainer() should be yield a container
> >>> reference (among the other things it's the better way a know in order
> >>> to do that).
> >>>
> >>> What's the problem with the threadlocal stuff?
> >>>
> >>> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
> >>>> Guys,
> >>>>
> >>>> I am in a non-struts environment (spring class, loaded by a customer
> >>>> ServletContextListener), and I am trying to get my hands on the Struts
> >>>> 2 configuration. I first tried to do -
> >>>>
> >>>> Dispatcher.getInstance().getContainer()
> >>>>
> >>>> But, the dispatcher instance is a threadlocal. I don't really care
> >>>> about the dispatcher, I'd just like to get a ref to the container.
> >>>>
> >>>> Any ideas?
> >>>>
> >>>> -Wes
> >>>>
> >>>> --
> >>>> Wes Wannemacher
> >>>>
> >>>> Head Engineer, WanTii, Inc.
> >>>> Need Training? Struts, Spring, Maven, Tomcat...
> >>>> Ask me for a quote!
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Maurizio Cucchiara
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Wes Wannemacher
> >>
> >> Head Engineer, WanTii, Inc.
> >> Need Training? Struts, Spring, Maven, Tomcat...
> >> Ask me for a quote!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
> >
> > --
> > Wes Wannemacher
> >
> > Head Engineer, WanTii, Inc.
> > Need Training? Struts, Spring, Maven, Tomcat...
> > Ask me for a quote!
> >
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
Let me put the whole thing a bit differently...
Does anyone know of a way to get a reference to the Container (or
ConfigurationManager or Configuration) from within -
ServletContextListener.contextInitialized(ServletContextEvent sce)
Or, maybe I could refactor some stuff and do it within -
Servlet.init(ServletConfig config)
I was hoping for some way to grab a hold of one of the filters
(Prepare or Execute) and yanking the Container out of there, but I
can't seem to find a good way to get at it, outside of Struts but
within a web-app.
-Wes
On Thu, Feb 10, 2011 at 3:15 PM, Wes Wannemacher <we...@wantii.com> wrote:
> This isn't a request thread... It is spawned from a ServletContextListener.
>
> I am still playing around, I have a ServletContext object right now
> (in the debugger) and I'm seeing if I can get the container from
> there.
>
> I'll check out Ben's solution and see if that helps.
>
> -Wes
>
> On Thu, Feb 10, 2011 at 2:43 PM, John Lindal <li...@yahoo-inc.com> wrote:
>> The simplest solution - if it's possible - is to make the spawned thread a parent of the request thread, and then grab what you need from the parent thread as soon as the child thread starts.
>>
>> Does Struts2 use InheritableThreadLocal? If it did, this would be even easier.
>>
>> John
>>
>>
>> On 2/10/11 11:02 AM, "Wes Wannemacher" <we...@wantii.com> wrote:
>>
>> Because, I'm not in a request-processing thread...
>>
>> In this app, I have a ServletContextListener that launches threads for
>> managing some housekeeping stuff (in this case, looking for specific
>> xml files in jars). I need the configured packages (PackageConfigs)
>> within one of these threads.
>>
>> I did try to get the Dispatcher instance, but it kept coming back
>> null, which led me to dig a bit and then I realized that I am not in a
>> request processing thread (neither is the ServletContextListener that
>> launched the thread). I am going to try to poke around the
>> ServletContext to see if I can get the container that way.
>>
>> -Wes
>>
>> On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
>> <ma...@gmail.com> wrote:
>>> Wes,
>>> to be frankly I didn't get what you said.
>>>
>>> Dispatcher.getInstance().getContainer() should be yield a container
>>> reference (among the other things it's the better way a know in order
>>> to do that).
>>>
>>> What's the problem with the threadlocal stuff?
>>>
>>> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
>>>> Guys,
>>>>
>>>> I am in a non-struts environment (spring class, loaded by a customer
>>>> ServletContextListener), and I am trying to get my hands on the Struts
>>>> 2 configuration. I first tried to do -
>>>>
>>>> Dispatcher.getInstance().getContainer()
>>>>
>>>> But, the dispatcher instance is a threadlocal. I don't really care
>>>> about the dispatcher, I'd just like to get a ref to the container.
>>>>
>>>> Any ideas?
>>>>
>>>> -Wes
>>>>
>>>> --
>>>> Wes Wannemacher
>>>>
>>>> Head Engineer, WanTii, Inc.
>>>> Need Training? Struts, Spring, Maven, Tomcat...
>>>> Ask me for a quote!
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Maurizio Cucchiara
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
This isn't a request thread... It is spawned from a ServletContextListener.
I am still playing around, I have a ServletContext object right now
(in the debugger) and I'm seeing if I can get the container from
there.
I'll check out Ben's solution and see if that helps.
-Wes
On Thu, Feb 10, 2011 at 2:43 PM, John Lindal <li...@yahoo-inc.com> wrote:
> The simplest solution - if it's possible - is to make the spawned thread a parent of the request thread, and then grab what you need from the parent thread as soon as the child thread starts.
>
> Does Struts2 use InheritableThreadLocal? If it did, this would be even easier.
>
> John
>
>
> On 2/10/11 11:02 AM, "Wes Wannemacher" <we...@wantii.com> wrote:
>
> Because, I'm not in a request-processing thread...
>
> In this app, I have a ServletContextListener that launches threads for
> managing some housekeeping stuff (in this case, looking for specific
> xml files in jars). I need the configured packages (PackageConfigs)
> within one of these threads.
>
> I did try to get the Dispatcher instance, but it kept coming back
> null, which led me to dig a bit and then I realized that I am not in a
> request processing thread (neither is the ServletContextListener that
> launched the thread). I am going to try to poke around the
> ServletContext to see if I can get the container that way.
>
> -Wes
>
> On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
> <ma...@gmail.com> wrote:
>> Wes,
>> to be frankly I didn't get what you said.
>>
>> Dispatcher.getInstance().getContainer() should be yield a container
>> reference (among the other things it's the better way a know in order
>> to do that).
>>
>> What's the problem with the threadlocal stuff?
>>
>> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
>>> Guys,
>>>
>>> I am in a non-struts environment (spring class, loaded by a customer
>>> ServletContextListener), and I am trying to get my hands on the Struts
>>> 2 configuration. I first tried to do -
>>>
>>> Dispatcher.getInstance().getContainer()
>>>
>>> But, the dispatcher instance is a threadlocal. I don't really care
>>> about the dispatcher, I'd just like to get a ref to the container.
>>>
>>> Any ideas?
>>>
>>> -Wes
>>>
>>> --
>>> Wes Wannemacher
>>>
>>> Head Engineer, WanTii, Inc.
>>> Need Training? Struts, Spring, Maven, Tomcat...
>>> Ask me for a quote!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Maurizio Cucchiara
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Ben McCann <bm...@google.com>.
If I'm understanding correctly, I had the same problem writing the Guice
plugin. Our solution was probably a bit ugly, but it was the only way I
could find of making it work, so maybe it will help you:
http://code.google.com/p/google-guice/source/browse/trunk/extensions/struts2/src/com/google/inject/struts2/Struts2Factory.java
On Thu, Feb 10, 2011 at 11:02 AM, Wes Wannemacher <we...@wantii.com> wrote:
> Because, I'm not in a request-processing thread...
>
> In this app, I have a ServletContextListener that launches threads for
> managing some housekeeping stuff (in this case, looking for specific
> xml files in jars). I need the configured packages (PackageConfigs)
> within one of these threads.
>
> I did try to get the Dispatcher instance, but it kept coming back
> null, which led me to dig a bit and then I realized that I am not in a
> request processing thread (neither is the ServletContextListener that
> launched the thread). I am going to try to poke around the
> ServletContext to see if I can get the container that way.
>
> -Wes
>
> On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
> <ma...@gmail.com> wrote:
> > Wes,
> > to be frankly I didn't get what you said.
> >
> > Dispatcher.getInstance().getContainer() should be yield a container
> > reference (among the other things it's the better way a know in order
> > to do that).
> >
> > What's the problem with the threadlocal stuff?
> >
> > On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
> >> Guys,
> >>
> >> I am in a non-struts environment (spring class, loaded by a customer
> >> ServletContextListener), and I am trying to get my hands on the Struts
> >> 2 configuration. I first tried to do -
> >>
> >> Dispatcher.getInstance().getContainer()
> >>
> >> But, the dispatcher instance is a threadlocal. I don't really care
> >> about the dispatcher, I'd just like to get a ref to the container.
> >>
> >> Any ideas?
> >>
> >> -Wes
> >>
> >> --
> >> Wes Wannemacher
> >>
> >> Head Engineer, WanTii, Inc.
> >> Need Training? Struts, Spring, Maven, Tomcat...
> >> Ask me for a quote!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Maurizio Cucchiara
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: getting the container (or Configuration/ConfigurationManager)
in a non-container-instantiated object
Posted by John Lindal <li...@yahoo-inc.com>.
The simplest solution - if it's possible - is to make the spawned thread a parent of the request thread, and then grab what you need from the parent thread as soon as the child thread starts.
Does Struts2 use InheritableThreadLocal? If it did, this would be even easier.
John
On 2/10/11 11:02 AM, "Wes Wannemacher" <we...@wantii.com> wrote:
Because, I'm not in a request-processing thread...
In this app, I have a ServletContextListener that launches threads for
managing some housekeeping stuff (in this case, looking for specific
xml files in jars). I need the configured packages (PackageConfigs)
within one of these threads.
I did try to get the Dispatcher instance, but it kept coming back
null, which led me to dig a bit and then I realized that I am not in a
request processing thread (neither is the ServletContextListener that
launched the thread). I am going to try to poke around the
ServletContext to see if I can get the container that way.
-Wes
On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
<ma...@gmail.com> wrote:
> Wes,
> to be frankly I didn't get what you said.
>
> Dispatcher.getInstance().getContainer() should be yield a container
> reference (among the other things it's the better way a know in order
> to do that).
>
> What's the problem with the threadlocal stuff?
>
> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
>> Guys,
>>
>> I am in a non-struts environment (spring class, loaded by a customer
>> ServletContextListener), and I am trying to get my hands on the Struts
>> 2 configuration. I first tried to do -
>>
>> Dispatcher.getInstance().getContainer()
>>
>> But, the dispatcher instance is a threadlocal. I don't really care
>> about the dispatcher, I'd just like to get a ref to the container.
>>
>> Any ideas?
>>
>> -Wes
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> Maurizio Cucchiara
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Wes Wannemacher <we...@wantii.com>.
Because, I'm not in a request-processing thread...
In this app, I have a ServletContextListener that launches threads for
managing some housekeeping stuff (in this case, looking for specific
xml files in jars). I need the configured packages (PackageConfigs)
within one of these threads.
I did try to get the Dispatcher instance, but it kept coming back
null, which led me to dig a bit and then I realized that I am not in a
request processing thread (neither is the ServletContextListener that
launched the thread). I am going to try to poke around the
ServletContext to see if I can get the container that way.
-Wes
On Thu, Feb 10, 2011 at 1:29 PM, Maurizio Cucchiara
<ma...@gmail.com> wrote:
> Wes,
> to be frankly I didn't get what you said.
>
> Dispatcher.getInstance().getContainer() should be yield a container
> reference (among the other things it's the better way a know in order
> to do that).
>
> What's the problem with the threadlocal stuff?
>
> On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
>> Guys,
>>
>> I am in a non-struts environment (spring class, loaded by a customer
>> ServletContextListener), and I am trying to get my hands on the Struts
>> 2 configuration. I first tried to do -
>>
>> Dispatcher.getInstance().getContainer()
>>
>> But, the dispatcher instance is a threadlocal. I don't really care
>> about the dispatcher, I'd just like to get a ref to the container.
>>
>> Any ideas?
>>
>> -Wes
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> Maurizio Cucchiara
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: getting the container (or Configuration/ConfigurationManager) in
a non-container-instantiated object
Posted by Maurizio Cucchiara <ma...@gmail.com>.
Wes,
to be frankly I didn't get what you said.
Dispatcher.getInstance().getContainer() should be yield a container
reference (among the other things it's the better way a know in order
to do that).
What's the problem with the threadlocal stuff?
On 10 February 2011 17:43, Wes Wannemacher <we...@wantii.com> wrote:
> Guys,
>
> I am in a non-struts environment (spring class, loaded by a customer
> ServletContextListener), and I am trying to get my hands on the Struts
> 2 configuration. I first tried to do -
>
> Dispatcher.getInstance().getContainer()
>
> But, the dispatcher instance is a threadlocal. I don't really care
> about the dispatcher, I'd just like to get a ref to the container.
>
> Any ideas?
>
> -Wes
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Maurizio Cucchiara
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org