RES: [struts] Re: Dynamically adding an ActionMapping

[Paulo Alvim]

Hi!

I'm a Struts user since dez/2001 and we've been used this approach bellow in
order to pre-populating DynaActionForms for a long time in our company...

...But now I need to do it based on my own customized ActionMapping
properties. For example, we use this kind of extension to declare a DTO/VO
and many others Use Case "declarative tags":

 



(others...)


 

I couldn't find any array or map in the ActionConfig class...so how could I
get my specialized ActionMapping properties inside a Struts plugin?

Thanks in advance!

Paulo Alvim
Powerlogic - Brazil

-Mensagem original-
De: Craig McClanahan [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 25 de novembro de 2004 15:18
Para: Struts Users Mailing List; [EMAIL PROTECTED]
Assunto: [struts] Re: Dynamically adding an ActionMapping


You will not be able to do this in a ServletContextListener, because
that gets executed before the Struts servlet has initialized the data
structures representing the configuration information.  However, if
you write to the Struts PlugIn API, the init() method of this class is
called after the configuration file has been loaded, but before the
configuration is frozen -- so you can add your own configuration
objects at that time.

Craig



On Thu, 25 Nov 2004 00:04:00 -0800, Tony Li <[EMAIL PROTECTED]> wrote:
> Hi all -
>
> I haven't been able to locate much information about dynamically adding an
> ActionMapping.  I would like to do this at application startup through my
> StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
> interested in adding a few simple ForwardActions.
>
> Any ideas?
>
> Thanks,
>
> Tony
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamically adding an ActionMapping

[David Suarez]

One benefit of allowing this flexibility may be the ability to re-use
your IoC container so that more configuration information is in one
place.

I haven't kept up with jdk1.5 but I am guessing the problem mentioned
below on double-locking has been resolved for that release.  I'm not
sure what performance hit the solution would cause but I would guess it
would be minor to force a shared memory area check for all threads.

I have seen features that basically read:  "Don't do this unless you
know what you're doing".  If the framework were to allow for one of
those rules in this case, then some people that know what they're doing
can put their own solution around the framework to start struts from
Spring for example.  I'm sure there are other thoughts that I wouldn't
even be able to guess right now.

This leads me to believe that documentation is the way to go for these
types of things to allow maximum flexibility.  To "code" in the
restriction removes the ability altogether.  If jdk1.5 does have the
volatility keyword doing the shared check you can even code it in now
and know that it will work whenever the user is in the environment that
supports it and have that in the documentation ("Only guaranteed with
1.5 forward", for example).

Since the project is open-source I would hope the most flexible approach
is adopted to allow others to add their own ingenuity.  If all config is
accessible for all projects it would be easier to embed the different
open source projects within one another.

Just my 2 cents...

Regards...djsuarez

-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED] 
Sent: Sunday, December 19, 2004 3:01 PM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: Re: Dynamically adding an ActionMapping

On Sun, 19 Dec 2004 09:53:55 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> While I agree completely with your point about maintainability and
> testability (I can't think of a single situation where I would ever
> consider dynamic configuration modification), I'm interested in how
this
> might be allowed anyway...
> 
> Wouldn't it be possible to create a thread-safe modification method
that
> locks the underlying structures during modification?  I don't think
you
> need to ensure thread safety on the read operation, just the
> modification operation...

This is *exactly* where the problem lies.  If one looks inside the
implementation of HashMap, one sees that there are times when the
internal data structures are being modified, and are in a potentially
inconsistent state that would corrupt a read operation happening on a
simultaneously executing thread.  If you are accessing a HashMap with
read and write operations on multiple threads, the only safe thing to
do is lock all the reads, as well as all the writes.

There was actually an attempt at dealing with this issue -- the
FastHashMap class that was originally in Struts 1.0, and ended up in
Commons Collections.  The basic idea was that this map operated in one
of two modes:

* "Fast" mode lets you do reads without locks, while simultaneous
  writes make a copy of the entire Map, perform the update, and then
  replace the ponter to the internal data structure with a (hopefully)
  atomic operation.

* "Slow" mode locks all accesses for you.

However, enough people raised thread safety concerns about this class
that we chose not to use it in Struts 1.1.

A second approach you might look at is the "double checked locking"
idiom, where your read method would try to detect (via a flag or
something) that a write operation is in progress, and only lock if
that's the case.  However, nobody has been able to come up with a
reliable mechanism to enforce this, due to some of the intricate
details about how threading is done in a JVM (especially on
multiprocessor machines where the threads really *are* running
simultaneously) -- basically, it just doesn't work.  Google for
"Double Checked Locking is Broken" for more info on this.

> 
> You yourself said no locks are needed during read time when you know
the
> configuration won't change, and I assume that's the mechanism by which
> you assure the performance aspects, by simply not synchronizing during
> read... If that's the case, I would think simply synchronizing in the
> modification method would allow you to still have the performance
while
> introducing the ability to safely modify the configuration.

The "freeze" operation that is performed after the configuration data
is read prohibits any future operations that might change the
underlying maps -- that's what guarantees that we can safely read from
the maps without locking anything.

> 
> Granted, that introduces a bottleneck because every request would have
> to wait until any modificatio

Re: Dynamically adding an ActionMapping

[Kris Schneider]

Along those lines, you might want to check out the backport of JSR 166 
(java.util.concurrent):

http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/
And perhaps specifically ConcurrentHashMap:
http://tinyurl.com/6c98r
Craig McClanahan wrote:
Cool ... this looks like a much better solution to the problem that
FastHashMap tried to solve.  And I trust the implementors of this
library a *heck* of a lot more than I trust myself (I wrote
FastHashMap originally) to get all the nitpicky details right.
Craig 

On Mon, 20 Dec 2004 10:17:11 +1300, Jason Lea <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:

This is *exactly* where the problem lies.  If one looks inside the
implementation of HashMap, one sees that there are times when the
internal data structures are being modified, and are in a potentially
inconsistent state that would corrupt a read operation happening on a
simultaneously executing thread.  If you are accessing a HashMap with
read and write operations on multiple threads, the only safe thing to
do is lock all the reads, as well as all the writes.

If someone were to attempt a change,  I imagine using something like
(http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.html)
ConcurrentReaderHashMap or ConcurrentHashMap would be good starting
point to avoid these locking problems.  One problem would be dependency
(either using java.util.concurrent for J2SE 5.0 or
EDU.oswego.cs.dl.util.concurrent for earlier Java versions)
--
Jason Lea
--
Kris Schneider 
D.O.Tech   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamically adding an ActionMapping

[Craig McClanahan]

Cool ... this looks like a much better solution to the problem that
FastHashMap tried to solve.  And I trust the implementors of this
library a *heck* of a lot more than I trust myself (I wrote
FastHashMap originally) to get all the nitpicky details right.

Craig 


On Mon, 20 Dec 2004 10:17:11 +1300, Jason Lea <[EMAIL PROTECTED]> wrote:
> 
> Craig McClanahan wrote:
> 
> >This is *exactly* where the problem lies.  If one looks inside the
> >implementation of HashMap, one sees that there are times when the
> >internal data structures are being modified, and are in a potentially
> >inconsistent state that would corrupt a read operation happening on a
> >simultaneously executing thread.  If you are accessing a HashMap with
> >read and write operations on multiple threads, the only safe thing to
> >do is lock all the reads, as well as all the writes.
> >
> >
> If someone were to attempt a change,  I imagine using something like
> (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.html)
> ConcurrentReaderHashMap or ConcurrentHashMap would be good starting
> point to avoid these locking problems.  One problem would be dependency
> (either using java.util.concurrent for J2SE 5.0 or
> EDU.oswego.cs.dl.util.concurrent for earlier Java versions)
> 
> --
> Jason Lea
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004-12-17
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004.12.17
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamically adding an ActionMapping

[Frank W. Zammetti]

Just for a laugh, I'll post this... I had just typed up the following 
response, when it dawned on me exactly why the problem is on the read 
side.  I think I was subconsciously thinking that locking the HashMap 
during the write would prevent any read from occurring, this is 
obviously not the case, and hence the read IS the problem.  That's what 
you were getting at with the "double check locking" later on too because 
what you really need is a mechanism by which an object can be locked 
from being touched IN ANY WAY when a critical section grabs it.  That 
would avoid the problem, but as you say doesn't seem to be possible (I 
would think it would have to be implemented at the JVM level in some 
way, and I'm sure has plenty of problems to overcome there as well).

So, ignore the rest of this message, except to see what I ALMOST posted 
(and would have been embaressed later by!)

--
Now I'm going to feel like a nudge, because you've clearly looked into 
this a heck of a lot more than I have and I run the risk of just being 
plain annoying by continuing, but...

class StrutsConfig {
  private HashMap config = new HashMap();
  public void getConfig(String key) {
return config.get(key);
  }
  synchronized public addConfigItem(String key, Object val) {
config.put(key, val);
  }
}
How is that not thread-safe on both read and write operations?  Granted 
I'm simplifying things beyond what they'd have to be for the situation 
we're discussing, but I think the theory is the same.  Or are you 
telling me that even AFTER the addConfigItem() method exits that the 
internal structure of the HashMap isn't guaranted to be consistent? 
That's the only catch I can see, and if THAT'S what your saying, then I 
concede the point completely :)

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Craig McClanahan wrote:
On Sun, 19 Dec 2004 09:53:55 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
While I agree completely with your point about maintainability and
testability (I can't think of a single situation where I would ever
consider dynamic configuration modification), I'm interested in how this
might be allowed anyway...
Wouldn't it be possible to create a thread-safe modification method that
locks the underlying structures during modification?  I don't think you
need to ensure thread safety on the read operation, just the
modification operation...

This is *exactly* where the problem lies.  If one looks inside the
implementation of HashMap, one sees that there are times when the
internal data structures are being modified, and are in a potentially
inconsistent state that would corrupt a read operation happening on a
simultaneously executing thread.  If you are accessing a HashMap with
read and write operations on multiple threads, the only safe thing to
do is lock all the reads, as well as all the writes.
There was actually an attempt at dealing with this issue -- the
FastHashMap class that was originally in Struts 1.0, and ended up in
Commons Collections.  The basic idea was that this map operated in one
of two modes:
* "Fast" mode lets you do reads without locks, while simultaneous
  writes make a copy of the entire Map, perform the update, and then
  replace the ponter to the internal data structure with a (hopefully)
  atomic operation.
* "Slow" mode locks all accesses for you.
However, enough people raised thread safety concerns about this class
that we chose not to use it in Struts 1.1.
A second approach you might look at is the "double checked locking"
idiom, where your read method would try to detect (via a flag or
something) that a write operation is in progress, and only lock if
that's the case.  However, nobody has been able to come up with a
reliable mechanism to enforce this, due to some of the intricate
details about how threading is done in a JVM (especially on
multiprocessor machines where the threads really *are* running
simultaneously) -- basically, it just doesn't work.  Google for
"Double Checked Locking is Broken" for more info on this.

You yourself said no locks are needed during read time when you know the
configuration won't change, and I assume that's the mechanism by which
you assure the performance aspects, by simply not synchronizing during
read... If that's the case, I would think simply synchronizing in the
modification method would allow you to still have the performance while
introducing the ability to safely modify the configuration.

The "freeze" operation that is performed after the configuration data
is read prohibits any future operations that might change the
underlying maps -- that's what guarantees that we can safely read from
the maps without locking anything.

Granted, that introduces a bottleneck because every request would have
to wait until any modification is complete, but I would consider it the
pervue of the app developer to decide if that's a problem or not (and
make sure it isn't through reasonabl

Re: Dynamically adding an ActionMapping

[Jason Lea]

Craig McClanahan wrote:
This is *exactly* where the problem lies.  If one looks inside the
implementation of HashMap, one sees that there are times when the
internal data structures are being modified, and are in a potentially
inconsistent state that would corrupt a read operation happening on a
simultaneously executing thread.  If you are accessing a HashMap with
read and write operations on multiple threads, the only safe thing to
do is lock all the reads, as well as all the writes.
 

If someone were to attempt a change,  I imagine using something like 
(http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.html) 
ConcurrentReaderHashMap or ConcurrentHashMap would be good starting 
point to avoid these locking problems.  One problem would be dependency 
(either using java.util.concurrent for J2SE 5.0 or 
EDU.oswego.cs.dl.util.concurrent for earlier Java versions)

--
Jason Lea

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004-12-17

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004.12.17
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamically adding an ActionMapping

[Craig McClanahan]

On Sun, 19 Dec 2004 09:53:55 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> While I agree completely with your point about maintainability and
> testability (I can't think of a single situation where I would ever
> consider dynamic configuration modification), I'm interested in how this
> might be allowed anyway...
> 
> Wouldn't it be possible to create a thread-safe modification method that
> locks the underlying structures during modification?  I don't think you
> need to ensure thread safety on the read operation, just the
> modification operation...

This is *exactly* where the problem lies.  If one looks inside the
implementation of HashMap, one sees that there are times when the
internal data structures are being modified, and are in a potentially
inconsistent state that would corrupt a read operation happening on a
simultaneously executing thread.  If you are accessing a HashMap with
read and write operations on multiple threads, the only safe thing to
do is lock all the reads, as well as all the writes.

There was actually an attempt at dealing with this issue -- the
FastHashMap class that was originally in Struts 1.0, and ended up in
Commons Collections.  The basic idea was that this map operated in one
of two modes:

* "Fast" mode lets you do reads without locks, while simultaneous
  writes make a copy of the entire Map, perform the update, and then
  replace the ponter to the internal data structure with a (hopefully)
  atomic operation.

* "Slow" mode locks all accesses for you.

However, enough people raised thread safety concerns about this class
that we chose not to use it in Struts 1.1.

A second approach you might look at is the "double checked locking"
idiom, where your read method would try to detect (via a flag or
something) that a write operation is in progress, and only lock if
that's the case.  However, nobody has been able to come up with a
reliable mechanism to enforce this, due to some of the intricate
details about how threading is done in a JVM (especially on
multiprocessor machines where the threads really *are* running
simultaneously) -- basically, it just doesn't work.  Google for
"Double Checked Locking is Broken" for more info on this.

> 
> You yourself said no locks are needed during read time when you know the
> configuration won't change, and I assume that's the mechanism by which
> you assure the performance aspects, by simply not synchronizing during
> read... If that's the case, I would think simply synchronizing in the
> modification method would allow you to still have the performance while
> introducing the ability to safely modify the configuration.

The "freeze" operation that is performed after the configuration data
is read prohibits any future operations that might change the
underlying maps -- that's what guarantees that we can safely read from
the maps without locking anything.

> 
> Granted, that introduces a bottleneck because every request would have
> to wait until any modification is complete, but I would consider it the
> pervue of the app developer to decide if that's a problem or not (and
> make sure it isn't through reasonable usage of the ability and proper
> app architecture around it).

Per above, locking only the writes is not good enough.

> 
> I guess the question I should ask is when you say the configuration "is
> frozen", is anything really done to make it read-only?  Or is it simply
> the case that one COULD right now modify the configuration if they are
> willing to forgo thread safety?

Take a look at org.apache.struts.config.FormBeanConfig for an example
of how the protection guarantee is implemented (the other cases are
done in a similar way):

* The "formProperties" HashMap (containing the definitions
  of your properties for a DynaActionForm) is a protected variable,
  with no public way to access it.

* The only mutation mechanisms for this map are other methods
  in this class (addFormPropertyConfig() and removeFormPropertyConfig())
  that both check for the frozen state before allowing the modification,
  and throw an exception if it is frozen.

Thus, there is no mechanism in the standard implementation to bypass
the protection, as long as freeze() is called after all the
configuration has been done and requests haven't started yet.  Because
the configuration is done during the init() method of ActionServlet --
which the container guarantees to run to completion before any
requests are accepted -- that guarantee is completed as well.

Your only escape hatch is that you can subclass FormBeanConfig and use
your own copy instead -- but at that point you are on your own. 
Struts makes zero guarantees about thread safe access to the maps at
that point.

And if you do that to allow dynamic modifications, but don't lock on
the reads as well, I think you're walking across a very thin
tightrope, high above the floor, with no net.

Craig

-
To unsubscribe, e-mail: [

Re: Dynamically adding an ActionMapping

[Frank W. Zammetti]

While I agree completely with your point about maintainability and 
testability (I can't think of a single situation where I would ever 
consider dynamic configuration modification), I'm interested in how this 
might be allowed anyway...

Wouldn't it be possible to create a thread-safe modification method that 
locks the underlying structures during modification?  I don't think you 
need to ensure thread safety on the read operation, just the 
modification operation...

You yourself said no locks are needed during read time when you know the 
configuration won't change, and I assume that's the mechanism by which 
you assure the performance aspects, by simply not synchronizing during 
read... If that's the case, I would think simply synchronizing in the 
modification method would allow you to still have the performance while 
introducing the ability to safely modify the configuration.

Granted, that introduces a bottleneck because every request would have 
to wait until any modification is complete, but I would consider it the 
pervue of the app developer to decide if that's a problem or not (and 
make sure it isn't through reasonable usage of the ability and proper 
app architecture around it).

I guess the question I should ask is when you say the configuration "is 
frozen", is anything really done to make it read-only?  Or is it simply 
the case that one COULD right now modify the configuration if they are 
willing to forgo thread safety?

Just a thought anyway (and completely uninformed I admit because I 
haven't taken the time to look at any source to see what's currently 
done)...

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Craig McClanahan wrote:
On Thu, 16 Dec 2004 11:21:01 -0500, Chaikin, Yaakov Y.
<[EMAIL PROTECTED]> wrote:
Craig,
What is the reason the configuration gets "frozen"? I don't mean to ask
about the mechanics of how it's frozen. I am just curious as to why freeze
it and not let it be dynamically updated during application lifetime?

The primary reason for this approach is a performance-related optimization.
Underlying most of the collections of configuration objects in Struts
are uses of HashMap, which is explicitly declared to be
non-thread-safe for methods that modify the structure, but thread-safe
for read-only use.  If one *knows* that the collection will never be
modified during its lifetime, then one can also know that no locks are
needed at read time -- and that happens a *lot* during the lifetime of
a Struts-based application.
On the other hand, if the configuration data structures were allowed
to change dynamically during the lifetime of the application, we'd
have to lock on read accesses as well.  That doesn't matter in an app
with, say, 10-20 users who play with it occasionally -- it is
critically important in apps that are supposed to be Internet scale.
A completely separate discussion could be had about the
maintainability and testability of an application that allows dynamic
updates to its configuration.  I'm very much in the conservative camp
on this issue -- if you haven't been able to thoroughly test the exact
application environment of your updated code (and this is basically
impossible when you allow dynamic updates to the runtime
configuration), then you have *zero* guarantees about the quality of
the implementation of your app at any given time.
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamically adding an ActionMapping

[Craig McClanahan]

On Thu, 16 Dec 2004 11:21:01 -0500, Chaikin, Yaakov Y.
<[EMAIL PROTECTED]> wrote:
> Craig,
> 
> What is the reason the configuration gets "frozen"? I don't mean to ask
> about the mechanics of how it's frozen. I am just curious as to why freeze
> it and not let it be dynamically updated during application lifetime?

The primary reason for this approach is a performance-related optimization.

Underlying most of the collections of configuration objects in Struts
are uses of HashMap, which is explicitly declared to be
non-thread-safe for methods that modify the structure, but thread-safe
for read-only use.  If one *knows* that the collection will never be
modified during its lifetime, then one can also know that no locks are
needed at read time -- and that happens a *lot* during the lifetime of
a Struts-based application.

On the other hand, if the configuration data structures were allowed
to change dynamically during the lifetime of the application, we'd
have to lock on read accesses as well.  That doesn't matter in an app
with, say, 10-20 users who play with it occasionally -- it is
critically important in apps that are supposed to be Internet scale.

A completely separate discussion could be had about the
maintainability and testability of an application that allows dynamic
updates to its configuration.  I'm very much in the conservative camp
on this issue -- if you haven't been able to thoroughly test the exact
application environment of your updated code (and this is basically
impossible when you allow dynamic updates to the runtime
configuration), then you have *zero* guarantees about the quality of
the implementation of your app at any given time.

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamically adding an ActionMapping

[David G. Friedman]

Craig, I am also curious for the reasons for a frozen configuration.  I
skimmed the ModuleConfig impl and see how every component seems to have a
'freeze'able state.  But, sadly, I didn't see an 'unfreeze.'  I'm guessing
components are passed around via the RequestProcessor and this ensure
nothing 'hokey' happens.  Since we're on the topic of 'freezing', do you
know if Struts-Chains can be modified at run-time to add/remove components
or add chains for new action paths?

Regards,
David the EVER CURIOUS! :)

-Original Message-
From: Chaikin, Yaakov Y. [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 11:21 AM
To: 'Struts Users Mailing List'
Subject: RE: Dynamically adding an ActionMapping


Craig,

What is the reason the configuration gets "frozen"? I don't mean to ask
about the mechanics of how it's frozen. I am just curious as to why freeze
it and not let it be dynamically updated during application lifetime?

Thanks,
Yaakov.

-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 25, 2004 1:18 PM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: Re: Dynamically adding an ActionMapping

You will not be able to do this in a ServletContextListener, because
that gets executed before the Struts servlet has initialized the data
structures representing the configuration information.  However, if
you write to the Struts PlugIn API, the init() method of this class is
called after the configuration file has been loaded, but before the
configuration is frozen -- so you can add your own configuration
objects at that time.

Craig



On Thu, 25 Nov 2004 00:04:00 -0800, Tony Li <[EMAIL PROTECTED]> wrote:
> Hi all -
>
> I haven't been able to locate much information about dynamically adding an
> ActionMapping.  I would like to do this at application startup through my
> StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
> interested in adding a few simple ForwardActions.
>
> Any ideas?
>
> Thanks,
>
> Tony
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamically adding an ActionMapping

[Chaikin, Yaakov Y.]

Craig,

What is the reason the configuration gets "frozen"? I don't mean to ask
about the mechanics of how it's frozen. I am just curious as to why freeze
it and not let it be dynamically updated during application lifetime?

Thanks,
Yaakov.

-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 25, 2004 1:18 PM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: Re: Dynamically adding an ActionMapping

You will not be able to do this in a ServletContextListener, because
that gets executed before the Struts servlet has initialized the data
structures representing the configuration information.  However, if
you write to the Struts PlugIn API, the init() method of this class is
called after the configuration file has been loaded, but before the
configuration is frozen -- so you can add your own configuration
objects at that time.

Craig



On Thu, 25 Nov 2004 00:04:00 -0800, Tony Li <[EMAIL PROTECTED]> wrote:
> Hi all -
>
> I haven't been able to locate much information about dynamically adding an
> ActionMapping.  I would like to do this at application startup through my
> StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
> interested in adding a few simple ForwardActions.
>
> Any ideas?
>
> Thanks,
>
> Tony
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamically adding an ActionMapping

[Craig McClanahan]

You will not be able to do this in a ServletContextListener, because
that gets executed before the Struts servlet has initialized the data
structures representing the configuration information.  However, if
you write to the Struts PlugIn API, the init() method of this class is
called after the configuration file has been loaded, but before the
configuration is frozen -- so you can add your own configuration
objects at that time.

Craig



On Thu, 25 Nov 2004 00:04:00 -0800, Tony Li <[EMAIL PROTECTED]> wrote:
> Hi all -
> 
> I haven't been able to locate much information about dynamically adding an
> ActionMapping.  I would like to do this at application startup through my
> StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
> interested in adding a few simple ForwardActions.
> 
> Any ideas?
> 
> Thanks,
> 
> Tony
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dynamically adding an ActionMapping

[Tony Li]

Hi all -

 

I haven't been able to locate much information about dynamically adding an
ActionMapping.  I would like to do this at application startup through my
StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
interested in adding a few simple ForwardActions.

 

Any ideas?

 

Thanks,

Tony

 

Dynamically adding an ActionMapping

[Tony Li]

Hi all -

 

I haven't been able to locate much information about dynamically adding an
ActionMapping.  I would like to do this at application startup through my
StartupListener (courtesy of Matt Raible's AppFuse).  I'm really only
interested in adding a few simple ForwardActions.

 

Any ideas?

 

Thanks,

Tony