You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2004/11/23 18:26:16 UTC
Chain enhancement idea
How would plugins work with the chain configuration?
I've written ActionServlet/RequestProcessor extensions and plugins in
the past. Often, the reason is to inject custom pre-, actual, or
post-processing at specific steps. An example would Tiles, which IIRC
intercepts the forward processing to see if the destination is a
configured tile, otherwise lets the default forward processing
continue.
It would be nice if plugins can inject chain elements at specific
points in the chain at startup, programatically. This way, plugins
can be programmed to modify specific portions of the chain that it is
concerned with, without affecting other portions of the chain or
modifications of other plugins.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 23 Nov 2004 11:26:16 -0600, Hubert Rabago <hr...@gmail.com> wrote:
> How would plugins work with the chain configuration?
>
> I've written ActionServlet/RequestProcessor extensions and plugins in
> the past. Often, the reason is to inject custom pre-, actual, or
> post-processing at specific steps. An example would Tiles, which IIRC
> intercepts the forward processing to see if the destination is a
> configured tile, otherwise lets the default forward processing
> continue.
>
> It would be nice if plugins can inject chain elements at specific
> points in the chain at startup, programatically. This way, plugins
> can be programmed to modify specific portions of the chain that it is
> concerned with, without affecting other portions of the chain or
> modifications of other plugins.
>
You can actually accomplish this kind of thing today (and an example
of it is in the chain-config.xml file for Struts-Chain), but it's a
little indirect.
In your standard processing chain, do something like this:
<command className="org.apache.commons.chain.generic.LookupCommand
catalogName="foo"
name="bar"
optional="true"/>
What this does, in English, is:
* Look up a command named "bar" in a catalog named "foo".
* If such a command exists, delegate control to it
(and do all the right stuff about filters if this is a chain)
* If such a command does not exist, silently continue
Therefore, it's very easy for your standard chain to provide extension
points. If you want to require that the named command exist, set
optional to "false" instead.
> Hubert
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:58 AM -0600 11/23/04, Hubert Rabago wrote:
>Specific apps would be able to do this, but I was trying to think from
>the perspective of a plugin developer. I haven't looked at an example
>yet, but would the use of tiles require both a struts-config change to
>activate the plugin, as well as a chain-config change to modify the
>chain? What if an app were to use multiple plugins that inject their
>own commands at different points? Do we leave the changes to the
>end-user/app-developer?
Yes, right now you must configure the TilesPlugIn and you must also
uncomment the TilesPreProcessor command in the chain. It would be
easy enough to leave the TilesPreProcessor command "on" by default,
since it doesn't complain if it can't find a tile -- but that doesn't
really address your larger question.
Still, I think it would probably be better to wait for some plugins
to materialize before guessing at exactly how to serve their needs.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
Re: Chain enhancement idea
Posted by Dakota Jack <da...@gmail.com>.
Well put, Sir. I think this about "does it". I would advocate not
only the CoR coding now being done but also an eventual IoC using all
three types of injection for the major components in Struts. This
would be, I think, the "cat's meow", or the "tree's bark". /// ;-)
Jack
On Wed, 24 Nov 2004 11:08:46 -0800, Don Brown <mr...@twdata.org> wrote:
> I look at technology as solutions to problems. IoC solves the problem
> of how can I define and configure a component external to the component
> and calling code, and CoR tackles the problem of a how can I define a
> process or sequence of processes in a pluggable manner.
>
> True, both patterns have a "pluggable" property, but both a HashMap and
> a SQL database have a "lookup" property. I think what you are getting
> at is, in Struts, we need a way to allow the framework to be easily
> customized by both framework extension projects and users. Both IoC and
> CoR help us meet that goal, but by solving two different problems that
> work against "pluggability". In Struts, I see the need for allowing the
> user to have more control over the process of events, as well as what
> components are used by that process. So yes, one goal perhaps, but two
> different problems being solved in two different ways.
>
> Don
>
>
>
> Dakota Jack wrote:
>
> >Without disagreeing with anything you have said, Don, I think the
> >confusion is caused in part by the fact that CoR is anticipated in
> >part for its pluggable nature. In this respect, there is a real
> >connection in functionality between CoR and IoC that is not as
> >attenuated as the one between HashMap and a SQL database but more like
> >a properties file and a SQL database? You think?
> >
> >Jack
> >
> >
> >On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <mr...@twdata.org> wrote:
> >
> >
> >>Not you personally BaTien, I don't understand why some people seem to
> >>confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
> >>and worse, think they are somehow solving the same problem. IoC helps
> >>us create components by managing their lifecycle and providing their
> >>dependencies. CoR defines a process that let's us flexibly specify what
> >>code to execute in what order.
> >>
> >>Sure, commons-chain does provide the default capability to create
> >>commands and configure them with simple properties, but that isn't its
> >>purpose and would certainly be replaced in any moderately complex usage,
> >>most likely by some sort of IoC. It's like saying a HashMap conflicts
> >>with a SQL database as they both store data. They are two very
> >>different things with very different problems they are trying to solve.
> >>
> >>Don
> >>
> >>
> >>
> >>BaTien Duong wrote:
> >>
> >>
> >>
> >>>Craig McClanahan wrote:
> >>>
> >>>
> >>>
> >>>>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
> >>>>wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>>I need to have a hook into processValidate() on validation failure.
> >>>>>>
> >>>>>>Currently that can only be done by copy-and-pasting the
> >>>>>>processValidate()
> >>>>>>method from RequestProcessor into a subclass and sticking a hook
> >>>>>>into the
> >>>>>>middle of the code.
> >>>>>>
> >>>>>>When I asked about this on the dev list long ago, it was confirmed
> >>>>>>that
> >>>>>>there was no other way to do this, but that chain would eventually
> >>>>>>provide
> >>>>>>this flexibility.
> >>>>>>
> >>>>>>If the chain isn't configured at a fine-grain level, then it's not
> >>>>>>all that
> >>>>>>much more functional than the existing RequestProcessor.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>The chain is configured at as fine-grained a level as you like, in
> >>>>>XML. Hubert is talking about configuring the chain programatically
> >>>>>as well, or at least in some way independent of the configuration of
> >>>>>the primary processing chain.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Programmatic configuration is certainly feasible ... there's no
> >>>>requirement in [chain] that you use the XML format at all. It's just
> >>>>one option.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Greetings and request expert advice:
> >>>
> >>>Commons-chain invented by Craig proves to be very flexible and work in
> >>>conjuction with other great technonologies. What i am trying to figure
> >>>out is a proper and practical places for using CoR and IoC (such as
> >>>Spring framework) in the construction and configuration of software
> >>>objects. I put out some of my preliminary thinking and hope some
> >>>experts care to add more arguments to enlighten us.
> >>>
> >>>1) Both CoR and IoC (and also Jsf setter injection) enable the
> >>>configuration and linking objects via XML metadata. But IoC allows the
> >>>object configuration at a finer level of object attributes and take
> >>>care of the objects declared as singleton. In this sense, IoC is finer
> >>>grain than CoR in object creation, configuration and management.
> >>>
> >>>2) CoR is very light weight and appropriate for programmatically
> >>>created processes. It does not not have the complexity and the depth
> >>>of plug-in features as Spring IoC.
> >>>
> >>>3) CoR is finer grain than IoC in the construction and rounting of
> >>>services within and between software layers, while IoC is aprropriate
> >>>at the application level.
> >>>
> >>>4) If we want to combine Jsf as view controller, Spring IoC and
> >>>commons-chain CoR, a practical infrastructure may be something like
> >>>followings:
> >>> a) Jsf as a view controller takes care of objects directly related
> >>>to User Interface (UI)
> >>> b) Spring IoC takes the responsibility of object creation,
> >>>especially singletons and fine grain configurations of objects not
> >>>directly related to UI. This is a proper choice of configuration if
> >>>other features of Spring framework such as application level event and
> >>>aop are used.
> >>> c) CoR is used to construct Front Controller a la pattern of Struts
> >>>of each software module, the rounting of services among modules, and
> >>>action commands (or chain) of specialized services in each service
> >>>module. It programmatically links created components from IoC to a
> >>>finer grain at each software module, which holds the module Catalog of
> >>>commands.
> >>> d) User session is a proper place for programmatically interactions
> >>>of Jsf, IoC and CoR objects. For example user generated events from
> >>>Jsf is linked through a CoR adapter to dispatch action command as a
> >>>request to appropriate software module (such as
> >>>authentication/authorization, portlet, service, etc) whose responses
> >>>are rendered through Jsf view controller.
> >>>
> >>>BaTien
> >>>DBGROUPS
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>>As long as you're willing to copy the base chain-config.xml file and
> >>>>>make a few modifications, then you could simply add your own command
> >>>>>which retrieves a value from the context under a well-known key and
> >>>>>inspects the value to see if validation passed or not. This exact
> >>>>>logic is the first thing executed in the CreateAction's execute
> >>>>>method, which doesn't lookup or create an action unless the form
> >>>>>validated.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>There's actually quite a few different ways to approach this,
> >>>>including the "optionally invoke some other command at this point"
> >>>>mentioned earlier in the thread, so you don't even *have* to
> >>>>cut-n-paste the standard version of the chain.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>You can start experimenting with commons-chain and struts-chain from
> >>>>>CVS Head if you want to see what's going on. You don't have to wait
> >>>>>for Struts 1.3.
> >>>>>
> >>>>>
> >>>>>
> >>>>Indeed, Struts-Chain directly illustrates the fine-grained approach to
> >>>>defining the standard request processing chain that Joe describes.
> >>>>Nightly builds are available at:
> >>>>
> >>>>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Craig
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
I'm putting a cap on my work here for the moment. I would be
interested if anyone has some ideas, directions, etc. they could offer
on the Registry issues. I would like to thank everyone, even Paul
;-), for their assistance on this thread. I need to do some homework
and then will be back on this. Imagine me fading out with one of
those background dreamy voices on the tube as in the Brady Bunch
talking like a bubble in a cartoon, saying "What a great bunch of guys
and gals; I will return soon to this place." LOL
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Thanks again. More useful information, Craig. I am trying to figure
out a good way to do a Registry.java class without messing up garbage
collection. I was hoping to use finalize() to keep track outside of
the garbage collection loop of live classes, but have discovered, I
think, that only classes with "new" in their creation have their
finalize() method called during garbage collection.
Do you have any ideas on a good hook for a registry on garbage
collection and live classes which does not inhibit garbage collection?
Callback?
Anyone else with an idea on that?
Jack
On Tue, 30 Nov 2004 00:21:42 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> Restarting the application works (for this particular scenario) ...
> but it makes any attempt to pretend to do "hot deploy" pretty
> pointless - the newly restarted app will already pick up the new
> version of your implementation class, without any special attention on
> the part of the app itself. There is no need, if you're willing to
> restart the app, to do anything like this.
While the "hot deploy" part of the hot deploy would not be utilized in
this case, the dependency injection equivalent would, and without the
xml configuration being required. So, there seems to be some, if not
a considerable, gain. Yes?
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 29 Nov 2004 22:29:35 -0800, Dakota Jack <da...@gmail.com> wrote:
> Thanks, Craig. I think there might be a misunderstanding. See within.
>
>
>
>
> On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <da...@gmail.com> wrote:
> >
> > > I am not sure what you mean by "transparently swap". IoC requires
> > > fairly extensive configuration for this "transparency". I don't see
> > > what is transparent about the IoC setting of an implementation at all.
> > > Am I missing something?
> >
> > If I use "create at startup", I'm going to get my instance of a
> > service class configured with its own dependencies. For example, if
> > I'm using constructor injection:
> >
> > public class Foo {
> > public Foo(Bar bar) {
> > this.bar = bar;
> > }
> > ... code that uses "bar" ...
> > }
> >
>
> So far the comparison is this: IoC creates the implementation of the
> Bar class with configuration and so on at startup. There has to be a
> class somewhere, of course, which is the implementation that IoC plugs
> into the app. HaD just starts with this class sitting where the
> implementation class is supposed to be. Your class might be called
> "BarTypeXImpl". My class is always called "BarImpl" merely.
>
> So far, all HaD requires none of the considerable coding overhead
> required by dependancy injection. (I hope I don't sound negative
> about lightweight, IoC containers, because I am not. Just looking
> around here.)
>
> Now, if you want to change the implementation class to, say,
> "BarTypeYImpl", you have to change the configuration and restart the
> application. I just drop call this new implementation by the same
> name ("BarImpl") and drop it in place of the old implementation.
> Then, I call BarHotFactory.loadBarImpl(). The result is that the Bar
> class reference and the Bar classloader class reference are changed to
> the new BarImpl. There will be no straggler references to cause
> garbage collection problems, I now see.
>
>
> > Now, in your scheme you upgrade the Bar class (of course, setting up a
> > new class loader to contain it).
>
> This only happens when there is a change. The IoC has also to do something.
>
> > But what you haven't done is
> > notified my Foo instance that you should somehow update the private
> > "bar" variable to point at a new instance based on the new class
> > (possibly having to do some sort of state transfer as well) ... it
> > continues to use the old one -- with the side effect that the old one
> > will not get garbage collected either.
>
> This is, I think, mistaken. Isn't it? The class reference content
> has changed. The reference Bar has to a classloader and the reference
> Bar has to a class remains the same but points to a different entity.
> Right?
Only partly. The renference to the old version of "Bar" remains in
existence fo the lifetime of the "Foo" instance that contains it,
until the "Foo" instance is told to release the old reference.
So, when Foo no longer uses Bar, Bar will be garbage
> collected. The sole result that is of significance is that Bar has
> been updated but the Bar in Foo is using the old version. Right? All
> new Bars created in Foo will be the new version. All new Foos will
> create new Bars. Right?
Yes, but so what? It's the existing Foos that will be broken by your change.
Updating the bytecodes that your factory method returns for a
getInstance() method for a Bar class has nothing to do with any
existing object that uses a Bar object as a service, and maintains a
reference to that instance.
You could get away with what you're after if Java supported
ClassLoader.unloacClass() -- but it doesn't for valid technical
reasons.
>
> If we want all client Foos to use the newest and greatest Bars, we can
> do so by restarting the application. This is the same thing we have
> to do with IoC, or we can get a solution for HaD that wil mirror any
> solution for IoC. So, the sole problem is that HaD can do things that
> IoC cannot do. You don't have to do that. Correct?
>
Restarting the application works (for this particular scenario) ...
but it makes any attempt to pretend to do "hot deploy" pretty
pointless - the newly restarted app will already pick up the new
version of your implementation class, without any special attention on
the part of the app itself. There is no need, if you're willing to
restart the app, to do anything like this.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Hi, Paul,
Sorry to disappoint you, but thanks for stopping in to say you are not
interested. LOL Seriously, this is a "think tank" thread not a
completed idea which is being ballyhooed thread. If you know a better
way than is being presented, please step up. I have not seen this
conversation and am learning a lot and still pretty convinced there is
some ore to be mined in these hills.
What I am interested in is whether or not from the perspective of the
developer of applications or the user of a container a hot deploy
container might provide the best and easiest environment. Being
interesting, first, or anything like that is not important to me. It
does seem as if you have some knowledge which I would encourage you to
share. But, I am not here to be "deep". Just to be practical.
Jack
> From my perspective, I kept hoping it was something deeper, but (no
> insult intended at all) it just kept seeming like someone figured out
> how to marry the factory pattern with a classloader. Much more
> interesting classloader magic has been done in the Eclipse internals,
> for example.
>
> -Paul Speed
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was
Re: Chain enhancement idea]
Posted by Paul Speed <ps...@progeeks.com>.
Just a lurker; I'm trying to follow along but I still don't get it.
Dakota Jack wrote:
>
>>You can tell me to use "create on demand" instead, but then I don't
>>need anything fancier than an IoC framework that lets me reconfigure
>>on the fly.
>>
>>And, current IoC approaches provide me other important benefits:
>>
>>* Multiple implementations can be used without the user having
>> to know the implementation class name.
>
>
> This is shared by IoC and HaD.
Not really. If you only have BarHotDeploy then you can only create one
type of Bar, yes? I could have a different versions of Bar used in
different contexts. BarDatabaseImpl, BarXmlImpl, whatever. A config
file could match these up as needed.
>
>
>>* Don't need the artificial confusion of multiple instances of the
>> same class name.
>
>
> I am not sure what this is referring to, Craig. You can do this or
> not do it. It is not necessary.
Except now I'm confused. So far the only benefits you seem to tout are
hot-deploy and lack of configuration. But hot deploy will necessarily
leave multiple version of BarImpl hanging around. Any old Foo objects
will still be holding their old Bar reference. So if you don't restart
the app you could have (n) versions of BarImpl hanging around logging
what they log and doing what they do. Kind of confusing.
With the use of dynamic proxies you could mitigate this since you could
create a proxy that would forward calls on to whatever real current
object exists. Then all Foo has is a Bar dynamic proxy implementation.
I'm still not sure that hot-deploy on a single class basis has any
lasting value, though.
>
>
>>For those reasons alone, I'm satisfied sticking with current IoC
>>approaches, and have sort of lost interest in pursuing this any
>>further.
>
>
> I just thought I would address these and leave it up to you whether or
> not your interest was rekindled by these considerations, given
> especially that you said "sort of". ;-)
>
> Thanks again for the conversation. Interesting.
>
From my perspective, I kept hoping it was something deeper, but (no
insult intended at all) it just kept seeming like someone figured out
how to marry the factory pattern with a classloader. Much more
interesting classloader magic has been done in the Eclipse internals,
for example.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Thanks, Craig. I think there might be a misunderstanding. See within.
On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <da...@gmail.com> wrote:
>
> > I am not sure what you mean by "transparently swap". IoC requires
> > fairly extensive configuration for this "transparency". I don't see
> > what is transparent about the IoC setting of an implementation at all.
> > Am I missing something?
>
> If I use "create at startup", I'm going to get my instance of a
> service class configured with its own dependencies. For example, if
> I'm using constructor injection:
>
> public class Foo {
> public Foo(Bar bar) {
> this.bar = bar;
> }
> ... code that uses "bar" ...
> }
>
So far the comparison is this: IoC creates the implementation of the
Bar class with configuration and so on at startup. There has to be a
class somewhere, of course, which is the implementation that IoC plugs
into the app. HaD just starts with this class sitting where the
implementation class is supposed to be. Your class might be called
"BarTypeXImpl". My class is always called "BarImpl" merely.
So far, all HaD requires none of the considerable coding overhead
required by dependancy injection. (I hope I don't sound negative
about lightweight, IoC containers, because I am not. Just looking
around here.)
Now, if you want to change the implementation class to, say,
"BarTypeYImpl", you have to change the configuration and restart the
application. I just drop call this new implementation by the same
name ("BarImpl") and drop it in place of the old implementation.
Then, I call BarHotFactory.loadBarImpl(). The result is that the Bar
class reference and the Bar classloader class reference are changed to
the new BarImpl. There will be no straggler references to cause
garbage collection problems, I now see.
> Now, in your scheme you upgrade the Bar class (of course, setting up a
> new class loader to contain it).
This only happens when there is a change. The IoC has also to do something.
> But what you haven't done is
> notified my Foo instance that you should somehow update the private
> "bar" variable to point at a new instance based on the new class
> (possibly having to do some sort of state transfer as well) ... it
> continues to use the old one -- with the side effect that the old one
> will not get garbage collected either.
This is, I think, mistaken. Isn't it? The class reference content
has changed. The reference Bar has to a classloader and the reference
Bar has to a class remains the same but points to a different entity.
Right? So, when Foo no longer uses Bar, Bar will be garbage
collected. The sole result that is of significance is that Bar has
been updated but the Bar in Foo is using the old version. Right? All
new Bars created in Foo will be the new version. All new Foos will
create new Bars. Right?
If we want all client Foos to use the newest and greatest Bars, we can
do so by restarting the application. This is the same thing we have
to do with IoC, or we can get a solution for HaD that wil mirror any
solution for IoC. So, the sole problem is that HaD can do things that
IoC cannot do. You don't have to do that. Correct?
>
> You can tell me to use "create on demand" instead, but then I don't
> need anything fancier than an IoC framework that lets me reconfigure
> on the fly.
>
> And, current IoC approaches provide me other important benefits:
>
> * Multiple implementations can be used without the user having
> to know the implementation class name.
This is shared by IoC and HaD.
>
> * Don't need the artificial confusion of multiple instances of the
> same class name.
I am not sure what this is referring to, Craig. You can do this or
not do it. It is not necessary.
>
> For those reasons alone, I'm satisfied sticking with current IoC
> approaches, and have sort of lost interest in pursuing this any
> further.
I just thought I would address these and leave it up to you whether or
not your interest was rekindled by these considerations, given
especially that you said "sort of". ;-)
Thanks again for the conversation. Interesting.
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <da...@gmail.com> wrote:
> I am not sure what you mean by "transparently swap". IoC requires
> fairly extensive configuration for this "transparency". I don't see
> what is transparent about the IoC setting of an implementation at all.
> Am I missing something?
If I use "create at startup", I'm going to get my instance of a
service class configured with its own dependencies. For example, if
I'm using constructor injection:
public class Foo {
public Foo(Bar bar) {
this.bar = bar;
}
... code that uses "bar" ...
}
Now, in your scheme you upgrade the Bar class (of course, setting up a
new class loader to contain it). But what you haven't done is
notified my Foo instance that you should somehow update the private
"bar" variable to point at a new instance based on the new class
(possibly having to do some sort of state transfer as well) ... it
continues to use the old one -- with the side effect that the old one
will not get garbage collected either.
You can tell me to use "create on demand" instead, but then I don't
need anything fancier than an IoC framework that lets me reconfigure
on the fly.
And, current IoC approaches provide me other important benefits:
* Multiple implementations can be used without the user having
to know the implementation class name.
* Don't need the artificial confusion of multiple instances of the
same class name.
For those reasons alone, I'm satisfied sticking with current IoC
approaches, and have sort of lost interest in pursuing this any
further.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Just a few notes and more later after some thought:
On Mon, 29 Nov 2004 17:01:43 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack <da...@gmail.com> wrote:
>
>
> > Yup! Dang! LOL Nothing is free, is it? I have changed the factory
> > transfer state code to
> >
> > newApp.setState(existingApp.getState());
> >
> > The people changing the implementation will know what state they want
> > to keep, to alter, or whatever, and this allows them to do it. In the
> > actual example of the AppImpl, I do with with a StateContainer. I
> > have made these changes in the
> >
> > http://131.191.32.112:8080/classes.zip
> >
>
> That's better, but still requires me to be able to produce this
> artificial "state" object. It's not obvious to me what happens if
> that state information is modified (on another thread) while
> getState() is executing, if it includes live references to other "hot
> deploy" instances, and a few goodies like that.
No StateContainer needs to be created. I just did in this case. In
fact, we need not even update the state at all. This is an extra
which neither Dependancy Injection nor Service Locator provide.
>
> From a simplistic viewpoint, I see IoC type frameworks being used in a
> couple of different ways:
>
> * "create on demand" -- every time I need an instance
> of a service object, I call the appropriate factory method,
> use this resource, and then throw away my reference to
> it. (Using JNDI resources normally also follows this model).
>
> * "create at startup" -- leverage the IoC architecture to
> configure the actual implementation class separately,
> and call the factory (or whatever) only once, at application
> startup; caching the object reference I get back. Convenienty,
> this object is also set up with whatever dependencies it needs
> (using constructor injection, setter injection, or whatever).
>
> My concern with your "hot deploy" strategy is that it works fine for
> the first case, but not at all for the second ... and people who just
> read the name are going to feel misled when they find that they can't
> transparently swap *existing* instances of the service object being
> used. They can only change the implementation class for *new*
> instances -- and that isn't any different from what an IoC container
> that allows configuration changes can do.
I am not sure what you mean by "transparently swap". IoC requires
fairly extensive configuration for this "transparency". I don't see
what is transparent about the IoC setting of an implementation at all.
Am I missing something?
The difference is that an IoC container requires configuration changes
and a class. This requires only the class. I don't think that IoC
containers generally use different classes of the sort we are
discussing without other changes. RIght? This is so, for example,
when we switch from one database to another. We don't just change the
configuration. We also have to provide the database. That is what I
am doing except without the configuration change.
> From JDK 1.3 onwards, you can create a class that *appears* to
> implement one or more particular interfaces, but doesn't really. This
> is an easy way to decorate existing objects to customize their
> behavior. The technique could be used to accomplish your idea of
> changing behavior on the fly -- but, of course, if you use "create on
> demand" and are using an IoC container that allows its configuration
> to be changed on the fly, then you don't even need dynamic proxies to
> change behavior at runtime.
>
> See "java.lang.reflect.Proxy" for more info.
I am familiar with Proxy, though no expert, and have coded them in
conjunction with the code I am showing you. I won't send that along
yet to keep things simple. But, I am not seeing what you are
thinking. Presently, I am convinced, there is something to what I am
looking at if I can create a registry without crashing the garbage
collection mechanism in Java.
Thanks again. I am enjoying the converstation.
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack <da...@gmail.com> wrote:
> Thanks for this thoughtful response, Craig. Very helpful. Notes are within:
>
>
> On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > If I'm reading the code right, your "factory" for any given class has
> > to know a bunch of nitty gritty details in order to implement the
> > transferState() method, right? So, whenever I add new state
> > information to the application class, I have to update transferState()
> > as well?
>
> Yup! Dang! LOL Nothing is free, is it? I have changed the factory
> transfer state code to
>
> newApp.setState(existingApp.getState());
>
> The people changing the implementation will know what state they want
> to keep, to alter, or whatever, and this allows them to do it. In the
> actual example of the AppImpl, I do with with a StateContainer. I
> have made these changes in the
>
> http://131.191.32.112:8080/classes.zip
>
That's better, but still requires me to be able to produce this
artificial "state" object. It's not obvious to me what happens if
that state information is modified (on another thread) while
getState() is executing, if it includes live references to other "hot
deploy" instances, and a few goodies like that.
> file.
>
> >
> > I don't see any mechanism to replace references to previous instances
> > of a newly loaded implementation class -- without that, "hot" deploy
> > doesn't seem particularly useful. Or, for that matter, any mechanism
> > to suspend access to the "old" instance while the state is being
> > transferred.
>
> The previous instance, when loaded, is replaced with the new version.
> Or, do you mean generally? If you are talking about something like a
> registry, then that is what my question on the previous email was
> about. I am concerned that I be able to keep track of instances of an
> implementation but not stop garbage collection. My head is not coming
> up with interesting ideas on that one. I am sure that must exist. Do
> you have a suggestion on that? Or, if I am not reading you right,
> please elaborate.
>From a simplistic viewpoint, I see IoC type frameworks being used in a
couple of different ways:
* "create on demand" -- every time I need an instance
of a service object, I call the appropriate factory method,
use this resource, and then throw away my reference to
it. (Using JNDI resources normally also follows this model).
* "create at startup" -- leverage the IoC architecture to
configure the actual implementation class separately,
and call the factory (or whatever) only once, at application
startup; caching the object reference I get back. Convenienty,
this object is also set up with whatever dependencies it needs
(using constructor injection, setter injection, or whatever).
My concern with your "hot deploy" strategy is that it works fine for
the first case, but not at all for the second ... and people who just
read the name are going to feel misled when they find that they can't
transparently swap *existing* instances of the service object being
used. They can only change the implementation class for *new*
instances -- and that isn't any different from what an IoC container
that allows configuration changes can do.
>
>
> >
> > I definitely don't like the notion of having more than one class with
> > the same name floating around ... that's just asking for confusion and
> > problems in debugging.
>
> Yah. I have to agree on that one. That was just an extra which I
> thought was neat but which might be too confusing.
>
> >
> > Overall, it seems like an interesting attempt to do the kinds of
> > things that implementation inheritance (using more typical service
> > locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you
> > deal with in ways that are more to my personal taste.
>
> Explain, if you would, on the dynamic proxies. I think I know what
> you mean but do not want to muddy the waters and would rather have you
> elaborate a bit. Okay? "Eschew obfuscation and avoid metaphors 'til
> the cows come home!"
>
>From JDK 1.3 onwards, you can create a class that *appears* to
implement one or more particular interfaces, but doesn't really. This
is an easy way to decorate existing objects to customize their
behavior. The technique could be used to accomplish your idea of
changing behavior on the fly -- but, of course, if you use "create on
demand" and are using an IoC container that allows its configuration
to be changed on the fly, then you don't even need dynamic proxies to
change behavior at runtime.
See "java.lang.reflect.Proxy" for more info.
> Thanks, again,
>
> Jack
>
Craig
>
>
>
> >
> > Craig
> >
> >
> >
> >
> > On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack <da...@gmail.com> wrote:
> > > Here is code, as opposed to "pretty pictures" -- LOL ;-)
> > >
> > > This is intended to demonstrate how simple Had is in contrast to
> > > normal Service Locator or Inversion of Control (Dependency Injection)
> > > frameworks. Remember, THIS IS ALL THE CODE. There are no
> > > NanoContainers. Not XML. No Config classes, etc. Where you want to
> > > have a single class with potential changes in implementations, you
> > > simply do not change the name of the class, e.g. provide new
> > > implementations under the same name. Where you want implementations
> > > that are different, e.g. if the Action class were an interface, you
> > > simply use different names for the different implementations and then
> > > you can hot deploy variations on the code in classes with those names.
> > > This allows you to change an existing implementation radically either
> > > by hot deploy or by name. Which you want to do depends on the
> > > situation. ActionServlet would want to be, for example, an interface
> > > that allowed differing implementations under "ActionServlet" without
> > > having different named implemenations, like you have with IoC and
> > > Service Locator solutions. On the other hand, you also would get hot
> > > deploy of various Action implementations under different names, e.g.
> > > LogonAction, PublishAction, etc.
> > >
> > > A working application with the App interface and client tester is
> > > available in a zip file, classes.zip, at
> > >
> > > http://131.191.32.112:8080/classes.zip
> > >
> > > This code has some additions that allow us to see whether or not a
> > > particular object has the last loaded implementation of AppImpl. The
> > > code includes:
> > >
> > > App.java
> > > AppImpl.java
> > > AppHotFactory.java
> > > TestAppClientTester.java
> > > SiteConstant.java
> > > Classpath.java.java
> > >
> > > To use a new AppImpl, all you have to do is to drop the AppImpl.class
> > > into the classes/deploy/com/crackwillow/app directory and call
> > > AppHotFactory.loadAppImpl().
> > >
> > > To see the "name" command work with the client, start the client with
> > > java com.crackwillow.testing.TestAppClientTester NEW_NAME
> > >
> > >
> > > Jack
> > >
> > >
> > >
> > >
> > > --
> > >
> > > "You can't wake a person who is pretending to be asleep."
> > >
> > > ~Native Proverb~
> > >
> > > "Each man is good in His sight. It is not necessary for eagles to be crows."
> > >
> > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> > >
> >
>
>
> --
>
>
>
>
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for eagles to be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Thanks for this thoughtful response, Craig. Very helpful. Notes are within:
On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> If I'm reading the code right, your "factory" for any given class has
> to know a bunch of nitty gritty details in order to implement the
> transferState() method, right? So, whenever I add new state
> information to the application class, I have to update transferState()
> as well?
Yup! Dang! LOL Nothing is free, is it? I have changed the factory
transfer state code to
newApp.setState(existingApp.getState());
The people changing the implementation will know what state they want
to keep, to alter, or whatever, and this allows them to do it. In the
actual example of the AppImpl, I do with with a StateContainer. I
have made these changes in the
http://131.191.32.112:8080/classes.zip
file.
>
> I don't see any mechanism to replace references to previous instances
> of a newly loaded implementation class -- without that, "hot" deploy
> doesn't seem particularly useful. Or, for that matter, any mechanism
> to suspend access to the "old" instance while the state is being
> transferred.
The previous instance, when loaded, is replaced with the new version.
Or, do you mean generally? If you are talking about something like a
registry, then that is what my question on the previous email was
about. I am concerned that I be able to keep track of instances of an
implementation but not stop garbage collection. My head is not coming
up with interesting ideas on that one. I am sure that must exist. Do
you have a suggestion on that? Or, if I am not reading you right,
please elaborate.
>
> I definitely don't like the notion of having more than one class with
> the same name floating around ... that's just asking for confusion and
> problems in debugging.
Yah. I have to agree on that one. That was just an extra which I
thought was neat but which might be too confusing.
>
> Overall, it seems like an interesting attempt to do the kinds of
> things that implementation inheritance (using more typical service
> locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you
> deal with in ways that are more to my personal taste.
Explain, if you would, on the dynamic proxies. I think I know what
you mean but do not want to muddy the waters and would rather have you
elaborate a bit. Okay? "Eschew obfuscation and avoid metaphors 'til
the cows come home!"
Thanks, again,
Jack
>
> Craig
>
>
>
>
> On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack <da...@gmail.com> wrote:
> > Here is code, as opposed to "pretty pictures" -- LOL ;-)
> >
> > This is intended to demonstrate how simple Had is in contrast to
> > normal Service Locator or Inversion of Control (Dependency Injection)
> > frameworks. Remember, THIS IS ALL THE CODE. There are no
> > NanoContainers. Not XML. No Config classes, etc. Where you want to
> > have a single class with potential changes in implementations, you
> > simply do not change the name of the class, e.g. provide new
> > implementations under the same name. Where you want implementations
> > that are different, e.g. if the Action class were an interface, you
> > simply use different names for the different implementations and then
> > you can hot deploy variations on the code in classes with those names.
> > This allows you to change an existing implementation radically either
> > by hot deploy or by name. Which you want to do depends on the
> > situation. ActionServlet would want to be, for example, an interface
> > that allowed differing implementations under "ActionServlet" without
> > having different named implemenations, like you have with IoC and
> > Service Locator solutions. On the other hand, you also would get hot
> > deploy of various Action implementations under different names, e.g.
> > LogonAction, PublishAction, etc.
> >
> > A working application with the App interface and client tester is
> > available in a zip file, classes.zip, at
> >
> > http://131.191.32.112:8080/classes.zip
> >
> > This code has some additions that allow us to see whether or not a
> > particular object has the last loaded implementation of AppImpl. The
> > code includes:
> >
> > App.java
> > AppImpl.java
> > AppHotFactory.java
> > TestAppClientTester.java
> > SiteConstant.java
> > Classpath.java.java
> >
> > To use a new AppImpl, all you have to do is to drop the AppImpl.class
> > into the classes/deploy/com/crackwillow/app directory and call
> > AppHotFactory.loadAppImpl().
> >
> > To see the "name" command work with the client, start the client with
> > java com.crackwillow.testing.TestAppClientTester NEW_NAME
> >
> >
> > Jack
> >
> >
> >
> >
> > --
> >
> > "You can't wake a person who is pretending to be asleep."
> >
> > ~Native Proverb~
> >
> > "Each man is good in His sight. It is not necessary for eagles to be crows."
> >
> > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> >
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Craig McClanahan <cr...@gmail.com>.
If I'm reading the code right, your "factory" for any given class has
to know a bunch of nitty gritty details in order to implement the
transferState() method, right? So, whenever I add new state
information to the application class, I have to update transferState()
as well?
I don't see any mechanism to replace references to previous instances
of a newly loaded implementation class -- without that, "hot" deploy
doesn't seem particularly useful. Or, for that matter, any mechanism
to suspend access to the "old" instance while the state is being
transferred.
I definitely don't like the notion of having more than one class with
the same name floating around ... that's just asking for confusion and
problems in debugging.
Overall, it seems like an interesting attempt to do the kinds of
things that implementation inheritance (using more typical service
locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you
deal with in ways that are more to my personal taste.
Craig
On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack <da...@gmail.com> wrote:
> Here is code, as opposed to "pretty pictures" -- LOL ;-)
>
> This is intended to demonstrate how simple Had is in contrast to
> normal Service Locator or Inversion of Control (Dependency Injection)
> frameworks. Remember, THIS IS ALL THE CODE. There are no
> NanoContainers. Not XML. No Config classes, etc. Where you want to
> have a single class with potential changes in implementations, you
> simply do not change the name of the class, e.g. provide new
> implementations under the same name. Where you want implementations
> that are different, e.g. if the Action class were an interface, you
> simply use different names for the different implementations and then
> you can hot deploy variations on the code in classes with those names.
> This allows you to change an existing implementation radically either
> by hot deploy or by name. Which you want to do depends on the
> situation. ActionServlet would want to be, for example, an interface
> that allowed differing implementations under "ActionServlet" without
> having different named implemenations, like you have with IoC and
> Service Locator solutions. On the other hand, you also would get hot
> deploy of various Action implementations under different names, e.g.
> LogonAction, PublishAction, etc.
>
> A working application with the App interface and client tester is
> available in a zip file, classes.zip, at
>
> http://131.191.32.112:8080/classes.zip
>
> This code has some additions that allow us to see whether or not a
> particular object has the last loaded implementation of AppImpl. The
> code includes:
>
> App.java
> AppImpl.java
> AppHotFactory.java
> TestAppClientTester.java
> SiteConstant.java
> Classpath.java.java
>
> To use a new AppImpl, all you have to do is to drop the AppImpl.class
> into the classes/deploy/com/crackwillow/app directory and call
> AppHotFactory.loadAppImpl().
>
> To see the "name" command work with the client, start the client with
> java com.crackwillow.testing.TestAppClientTester NEW_NAME
>
>
> Jack
>
>
>
>
> --
>
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for eagles to be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Here is code, as opposed to "pretty pictures" -- LOL ;-)
This is intended to demonstrate how simple Had is in contrast to
normal Service Locator or Inversion of Control (Dependency Injection)
frameworks. Remember, THIS IS ALL THE CODE. There are no
NanoContainers. Not XML. No Config classes, etc. Where you want to
have a single class with potential changes in implementations, you
simply do not change the name of the class, e.g. provide new
implementations under the same name. Where you want implementations
that are different, e.g. if the Action class were an interface, you
simply use different names for the different implementations and then
you can hot deploy variations on the code in classes with those names.
This allows you to change an existing implementation radically either
by hot deploy or by name. Which you want to do depends on the
situation. ActionServlet would want to be, for example, an interface
that allowed differing implementations under "ActionServlet" without
having different named implemenations, like you have with IoC and
Service Locator solutions. On the other hand, you also would get hot
deploy of various Action implementations under different names, e.g.
LogonAction, PublishAction, etc.
A working application with the App interface and client tester is
available in a zip file, classes.zip, at
http://131.191.32.112:8080/classes.zip
This code has some additions that allow us to see whether or not a
particular object has the last loaded implementation of AppImpl. The
code includes:
App.java
AppImpl.java
AppHotFactory.java
TestAppClientTester.java
SiteConstant.java
Classpath.java.java
To use a new AppImpl, all you have to do is to drop the AppImpl.class
into the classes/deploy/com/crackwillow/app directory and call
AppHotFactory.loadAppImpl().
To see the "name" command work with the client, start the client with
java com.crackwillow.testing.TestAppClientTester NEW_NAME
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
All the things you mention, of course, are real problems that need to
be solved. They are, however, I think, not formidable or even
particularly challenging and have known solutions which are
provisionally good enough for discussion. When you think that the one
HaD class stands in for the entire IoC framework, this option, to my
way of thinking, has serious merit. Anyway, an example that I am
using is the following interface App with an implementation AppImpl
and an AppHotFactory as indicated. When creating an AppImpl object,
the code is
App app = AppHotFactory.getInstance(null);
When updating an AppImpl to new solution, the code is
AppHotFactory.loadAppImpl();
When updating an existing AppImpl object to the new AppImpl.class, the code is
app = AppHotFactory.logAppImpl(app);
The interface is:
public interface App
extends Serializable {
public String getName();
public Set getPermissionNames();
public Map getPermissionTypes();
public void setName(String name);
public void setPermissionNames(Set permissionNames);
public void setPermissionTypes(Map permissionTypes);
public String toString();
}
The implementation is whatever you want it to be. And, the AppHotFacotry is:
public class AppHotFactory {
private static ClassLoader appClassLoader;
private static Class appClass;
public static synchronized App getInstance(App existingApp) {
// Startup implementation
if (appClass == null) { loadAppImpl(); }
// Factory
App newApp = null;
try {
newApp = (App)appClass.newInstance();
} catch (InstantiationException ie) {
System.out.println(ie.getMessage());
ie.printStackTrace();
} catch (IllegalAccessException iae) {
System.out.println(iae.getMessage());
iae.printStackTrace();
}
// Copy state when going to a new implementation.
if (existingApp != null) {
transferState(existingApp,newApp);
}
return existingApp = newApp;
}
public static synchronized void loadAppImpl() {
try {
appClass = new URLClassLoader(new URL[]{new
URL(SiteConstant.DEPLOY)}).loadClass("com.crackwillow.app.AppImpl");
appClass.newInstance();
} catch (MalformedURLException mue) {
System.out.println(mue.getMessage());
mue.printStackTrace();
} catch (ClassNotFoundException cnfe) {
System.out.println(cnfe.getMessage());
cnfe.printStackTrace();
} catch (InstantiationException ie) {
System.out.println(ie.getMessage());
ie.printStackTrace();
} catch (IllegalAccessException iae) {
System.out.println(iae.getMessage());
iae.printStackTrace();
}
}
private static synchronized void transferState(App existingApp, App newApp) {
newApp.setName(existingApp.getName());
newApp.setPermissionNames(existingApp.getPermissionNames());
newApp.setPermissionTypes(existingApp.getPermissionTypes());
}
}
Works like a charm. More later.
On Sun, 28 Nov 2004 17:54:30 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack <da...@gmail.com> wrote:
> [snip]
>
>
> > With hot deploy, instead of switching the implementation and the name
> > of the implementation class, e.g. ColonSeparatedMovieFinder for
> > DatabaseMovieFinder, you just have an implementation called
> > MovieFinderImplementation (or whatever you want, e.g. X) and a
> > MovieFinderImplementationHotFactory for getting object instance
> > implementations of the MovieFinder interfaces. Conceivably, in fact,
> > you can give people differing implementations with the same name by
> > simply putting them in different directories: no problem. This means
> > that the code can be dynamic and alterable at will and that there need
> > be no changes anywhere if you don't want there to be other than
> > dumping the new MovieFinderImplemenation.class in some directory
> > somewhere.
>
> Within a single JVM (such as a servlet container), the only way to
> have different versions of the same fully qualified class name is to
> use different class loaders, which loads the different versions from
> lots of different places. That sounds like a pretty significant code
> management issue that any hot deploy strategy like what you describe
> would need to deal with.
>
> On the other hand, you're going to need individual class loaders to
> solve a different aspect of "hot deploy" as well ... recompiling an
> existing implementation class to modify its behavior (instead of
> trying to switch to a new one). There is no ClassLoader.unloadClass()
> method in Java, so the only way to "throw away" an old class is to
> throw away the class loader that contained it (and hope that the rest
> of the application doesn't have any pointers to the old class or any
> instances created by it, which would cause a big memory leak).
>
> That's what a servlet container does, for instance, when you reload an
> app -- it throws away the old context class loader and creates a new
> one. It's not a perfect solution, but it's not an easy problem,
> either.
>
> Craig
>
>
> Craig
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack <da...@gmail.com> wrote:
[snip]
> With hot deploy, instead of switching the implementation and the name
> of the implementation class, e.g. ColonSeparatedMovieFinder for
> DatabaseMovieFinder, you just have an implementation called
> MovieFinderImplementation (or whatever you want, e.g. X) and a
> MovieFinderImplementationHotFactory for getting object instance
> implementations of the MovieFinder interfaces. Conceivably, in fact,
> you can give people differing implementations with the same name by
> simply putting them in different directories: no problem. This means
> that the code can be dynamic and alterable at will and that there need
> be no changes anywhere if you don't want there to be other than
> dumping the new MovieFinderImplemenation.class in some directory
> somewhere.
Within a single JVM (such as a servlet container), the only way to
have different versions of the same fully qualified class name is to
use different class loaders, which loads the different versions from
lots of different places. That sounds like a pretty significant code
management issue that any hot deploy strategy like what you describe
would need to deal with.
On the other hand, you're going to need individual class loaders to
solve a different aspect of "hot deploy" as well ... recompiling an
existing implementation class to modify its behavior (instead of
trying to switch to a new one). There is no ClassLoader.unloadClass()
method in Java, so the only way to "throw away" an old class is to
throw away the class loader that contained it (and hope that the rest
of the application doesn't have any pointers to the old class or any
instances created by it, which would cause a big memory leak).
That's what a servlet container does, for instance, when you reload an
app -- it throws away the old context class loader and creates a new
one. It's not a perfect solution, but it's not an easy problem,
either.
Craig
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]
Posted by Dakota Jack <da...@gmail.com>.
Hi, Don,
I'm thinking out loud here.
I have been chewing on this because I am in a mode where I have to
think about where to put my energies the next few years. So, I might
as well jump in here and see what people think. At least I know
enough to listen.
I like what Vic was saying about CoR and IoC, by the way.
Inversion of control is merely that: inversion of control. You pass
control of some choice or process over to the framework. As such, IoC
is really so general as to be less than really helpful on any
particulars, even where the term "IoC" is an accurate description of
what is going on. That is why Martin Fowler uses Dependency Injection
instead of IoC in his well-known piece on the same.
When you have a "helper" interface, e.g. Fowler's MovieFinder
interface, and you want to be able to use different implementations in
a framework, Fowler calls that Dependency Injection. Essentially,
this allows you to use the same code internally while passing the name
or type of the object which implements the interface to some assembly
mechanism in the container.
Sometimes you want to do this, viz. have the choice of using multiple
implementations and having the container assembled with your choice,
usually using configuration xml and some equivalent of Pico's
NanoContainer to manage the xml assembly. Or, you can use a Service
Locator to do the same thing. Where you just want to use one
implementation, I prefer using or at least am considering prefering
using hot deploy. This means that you don't have to use IoC or
Service Locator or anything else to have differing implementations in
the same framework. What is more, not only are there, as Craig
McClanahan says, "fewer moving parts", but also you can choose to
employ differing implementations of the same interface with different
names (think Action subclasses) and each of these can then be hot
deployed as well. Lastly, if you are using CoR you can also use hot
deploy to allow varying implementations.
As a result, I am starting to think that hot deploy is a better
solution than either service locator or dependency injection to the
problem of allowing differing implementations of interfaces in an
interface. Anyone that has further thoughts on this, I would be more
than interested.
With hot deploy, instead of switching the implementation and the name
of the implementation class, e.g. ColonSeparatedMovieFinder for
DatabaseMovieFinder, you just have an implementation called
MovieFinderImplementation (or whatever you want, e.g. X) and a
MovieFinderImplementationHotFactory for getting object instance
implementations of the MovieFinder interfaces. Conceivably, in fact,
you can give people differing implementations with the same name by
simply putting them in different directories: no problem. This means
that the code can be dynamic and alterable at will and that there need
be no changes anywhere if you don't want there to be other than
dumping the new MovieFinderImplemenation.class in some directory
somewhere.
Anyway, I am starting to fall in love with this idea for the moment.
LOL Any experience on this out there? I would like a way to update
objects in this sort of design without killing garbage collection by
maintaining references. Any ideas on that?
Jack
On Wed, 24 Nov 2004 11:08:46 -0800, Don Brown <mr...@twdata.org> wrote:
> I look at technology as solutions to problems. IoC solves the problem
> of how can I define and configure a component external to the component
> and calling code, and CoR tackles the problem of a how can I define a
> process or sequence of processes in a pluggable manner.
>
> True, both patterns have a "pluggable" property, but both a HashMap and
> a SQL database have a "lookup" property. I think what you are getting
> at is, in Struts, we need a way to allow the framework to be easily
> customized by both framework extension projects and users. Both IoC and
> CoR help us meet that goal, but by solving two different problems that
> work against "pluggability". In Struts, I see the need for allowing the
> user to have more control over the process of events, as well as what
> components are used by that process. So yes, one goal perhaps, but two
> different problems being solved in two different ways.
>
> Don
>
>
>
> Dakota Jack wrote:
>
> >Without disagreeing with anything you have said, Don, I think the
> >confusion is caused in part by the fact that CoR is anticipated in
> >part for its pluggable nature. In this respect, there is a real
> >connection in functionality between CoR and IoC that is not as
> >attenuated as the one between HashMap and a SQL database but more like
> >a properties file and a SQL database? You think?
> >
> >Jack
> >
> >
> >On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <mr...@twdata.org> wrote:
> >
> >
> >>Not you personally BaTien, I don't understand why some people seem to
> >>confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
> >>and worse, think they are somehow solving the same problem. IoC helps
> >>us create components by managing their lifecycle and providing their
> >>dependencies. CoR defines a process that let's us flexibly specify what
> >>code to execute in what order.
> >>
> >>Sure, commons-chain does provide the default capability to create
> >>commands and configure them with simple properties, but that isn't its
> >>purpose and would certainly be replaced in any moderately complex usage,
> >>most likely by some sort of IoC. It's like saying a HashMap conflicts
> >>with a SQL database as they both store data. They are two very
> >>different things with very different problems they are trying to solve.
> >>
> >>Don
> >>
> >>
> >>
> >>BaTien Duong wrote:
> >>
> >>
> >>
> >>>Craig McClanahan wrote:
> >>>
> >>>
> >>>
> >>>>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
> >>>>wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>>I need to have a hook into processValidate() on validation failure.
> >>>>>>
> >>>>>>Currently that can only be done by copy-and-pasting the
> >>>>>>processValidate()
> >>>>>>method from RequestProcessor into a subclass and sticking a hook
> >>>>>>into the
> >>>>>>middle of the code.
> >>>>>>
> >>>>>>When I asked about this on the dev list long ago, it was confirmed
> >>>>>>that
> >>>>>>there was no other way to do this, but that chain would eventually
> >>>>>>provide
> >>>>>>this flexibility.
> >>>>>>
> >>>>>>If the chain isn't configured at a fine-grain level, then it's not
> >>>>>>all that
> >>>>>>much more functional than the existing RequestProcessor.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>The chain is configured at as fine-grained a level as you like, in
> >>>>>XML. Hubert is talking about configuring the chain programatically
> >>>>>as well, or at least in some way independent of the configuration of
> >>>>>the primary processing chain.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Programmatic configuration is certainly feasible ... there's no
> >>>>requirement in [chain] that you use the XML format at all. It's just
> >>>>one option.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Greetings and request expert advice:
> >>>
> >>>Commons-chain invented by Craig proves to be very flexible and work in
> >>>conjuction with other great technonologies. What i am trying to figure
> >>>out is a proper and practical places for using CoR and IoC (such as
> >>>Spring framework) in the construction and configuration of software
> >>>objects. I put out some of my preliminary thinking and hope some
> >>>experts care to add more arguments to enlighten us.
> >>>
> >>>1) Both CoR and IoC (and also Jsf setter injection) enable the
> >>>configuration and linking objects via XML metadata. But IoC allows the
> >>>object configuration at a finer level of object attributes and take
> >>>care of the objects declared as singleton. In this sense, IoC is finer
> >>>grain than CoR in object creation, configuration and management.
> >>>
> >>>2) CoR is very light weight and appropriate for programmatically
> >>>created processes. It does not not have the complexity and the depth
> >>>of plug-in features as Spring IoC.
> >>>
> >>>3) CoR is finer grain than IoC in the construction and rounting of
> >>>services within and between software layers, while IoC is aprropriate
> >>>at the application level.
> >>>
> >>>4) If we want to combine Jsf as view controller, Spring IoC and
> >>>commons-chain CoR, a practical infrastructure may be something like
> >>>followings:
> >>> a) Jsf as a view controller takes care of objects directly related
> >>>to User Interface (UI)
> >>> b) Spring IoC takes the responsibility of object creation,
> >>>especially singletons and fine grain configurations of objects not
> >>>directly related to UI. This is a proper choice of configuration if
> >>>other features of Spring framework such as application level event and
> >>>aop are used.
> >>> c) CoR is used to construct Front Controller a la pattern of Struts
> >>>of each software module, the rounting of services among modules, and
> >>>action commands (or chain) of specialized services in each service
> >>>module. It programmatically links created components from IoC to a
> >>>finer grain at each software module, which holds the module Catalog of
> >>>commands.
> >>> d) User session is a proper place for programmatically interactions
> >>>of Jsf, IoC and CoR objects. For example user generated events from
> >>>Jsf is linked through a CoR adapter to dispatch action command as a
> >>>request to appropriate software module (such as
> >>>authentication/authorization, portlet, service, etc) whose responses
> >>>are rendered through Jsf view controller.
> >>>
> >>>BaTien
> >>>DBGROUPS
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>>As long as you're willing to copy the base chain-config.xml file and
> >>>>>make a few modifications, then you could simply add your own command
> >>>>>which retrieves a value from the context under a well-known key and
> >>>>>inspects the value to see if validation passed or not. This exact
> >>>>>logic is the first thing executed in the CreateAction's execute
> >>>>>method, which doesn't lookup or create an action unless the form
> >>>>>validated.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>There's actually quite a few different ways to approach this,
> >>>>including the "optionally invoke some other command at this point"
> >>>>mentioned earlier in the thread, so you don't even *have* to
> >>>>cut-n-paste the standard version of the chain.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>You can start experimenting with commons-chain and struts-chain from
> >>>>>CVS Head if you want to see what's going on. You don't have to wait
> >>>>>for Struts 1.3.
> >>>>>
> >>>>>
> >>>>>
> >>>>Indeed, Struts-Chain directly illustrates the fine-grained approach to
> >>>>defining the standard request processing chain that Joe describes.
> >>>>Nightly builds are available at:
> >>>>
> >>>>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Craig
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by BaTien Duong <ba...@dbgroups.com>.
Don Brown wrote:
> I look at technology as solutions to problems. IoC solves the problem
> of how can I define and configure a component external to the
> component and calling code, and CoR tackles the problem of a how can I
> define a process or sequence of processes in a pluggable manner.
>
> True, both patterns have a "pluggable" property, but both a HashMap
> and a SQL database have a "lookup" property. I think what you are
> getting at is, in Struts, we need a way to allow the framework to be
> easily customized by both framework extension projects and users.
> Both IoC and CoR help us meet that goal, but by solving two different
> problems that work against "pluggability". In Struts, I see the need
> for allowing the user to have more control over the process of events,
> as well as what components are used by that process. So yes, one goal
> perhaps, but two different problems being solved in two different ways.
>
> Don
I agree. Thanks for your voice.
BaTien
DBGROUPS
>
> Dakota Jack wrote:
>
>> Without disagreeing with anything you have said, Don, I think the
>> confusion is caused in part by the fact that CoR is anticipated in
>> part for its pluggable nature. In this respect, there is a real
>> connection in functionality between CoR and IoC that is not as
>> attenuated as the one between HashMap and a SQL database but more like
>> a properties file and a SQL database? You think?
>>
>> Jack
>>
>>
>> On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <mr...@twdata.org> wrote:
>>
>>
>>> Not you personally BaTien, I don't understand why some people seem to
>>> confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
>>> and worse, think they are somehow solving the same problem. IoC helps
>>> us create components by managing their lifecycle and providing their
>>> dependencies. CoR defines a process that let's us flexibly specify
>>> what
>>> code to execute in what order.
>>>
>>> Sure, commons-chain does provide the default capability to create
>>> commands and configure them with simple properties, but that isn't its
>>> purpose and would certainly be replaced in any moderately complex
>>> usage,
>>> most likely by some sort of IoC. It's like saying a HashMap conflicts
>>> with a SQL database as they both store data. They are two very
>>> different things with very different problems they are trying to solve.
>>>
>>> Don
>>>
>>>
>>>
>>> BaTien Duong wrote:
>>>
>>>
>>>
>>>> Craig McClanahan wrote:
>>>>
>>>>
>>>>
>>>>> On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> I need to have a hook into processValidate() on validation failure.
>>>>>>>
>>>>>>> Currently that can only be done by copy-and-pasting the
>>>>>>> processValidate()
>>>>>>> method from RequestProcessor into a subclass and sticking a hook
>>>>>>> into the
>>>>>>> middle of the code.
>>>>>>>
>>>>>>> When I asked about this on the dev list long ago, it was confirmed
>>>>>>> that
>>>>>>> there was no other way to do this, but that chain would eventually
>>>>>>> provide
>>>>>>> this flexibility.
>>>>>>>
>>>>>>> If the chain isn't configured at a fine-grain level, then it's not
>>>>>>> all that
>>>>>>> much more functional than the existing RequestProcessor.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The chain is configured at as fine-grained a level as you like, in
>>>>>> XML. Hubert is talking about configuring the chain programatically
>>>>>> as well, or at least in some way independent of the configuration of
>>>>>> the primary processing chain.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Programmatic configuration is certainly feasible ... there's no
>>>>> requirement in [chain] that you use the XML format at all. It's just
>>>>> one option.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Greetings and request expert advice:
>>>>
>>>> Commons-chain invented by Craig proves to be very flexible and work in
>>>> conjuction with other great technonologies. What i am trying to figure
>>>> out is a proper and practical places for using CoR and IoC (such as
>>>> Spring framework) in the construction and configuration of software
>>>> objects. I put out some of my preliminary thinking and hope some
>>>> experts care to add more arguments to enlighten us.
>>>>
>>>> 1) Both CoR and IoC (and also Jsf setter injection) enable the
>>>> configuration and linking objects via XML metadata. But IoC allows the
>>>> object configuration at a finer level of object attributes and take
>>>> care of the objects declared as singleton. In this sense, IoC is finer
>>>> grain than CoR in object creation, configuration and management.
>>>>
>>>> 2) CoR is very light weight and appropriate for programmatically
>>>> created processes. It does not not have the complexity and the depth
>>>> of plug-in features as Spring IoC.
>>>>
>>>> 3) CoR is finer grain than IoC in the construction and rounting of
>>>> services within and between software layers, while IoC is aprropriate
>>>> at the application level.
>>>>
>>>> 4) If we want to combine Jsf as view controller, Spring IoC and
>>>> commons-chain CoR, a practical infrastructure may be something like
>>>> followings:
>>>> a) Jsf as a view controller takes care of objects directly related
>>>> to User Interface (UI)
>>>> b) Spring IoC takes the responsibility of object creation,
>>>> especially singletons and fine grain configurations of objects not
>>>> directly related to UI. This is a proper choice of configuration if
>>>> other features of Spring framework such as application level event and
>>>> aop are used.
>>>> c) CoR is used to construct Front Controller a la pattern of Struts
>>>> of each software module, the rounting of services among modules, and
>>>> action commands (or chain) of specialized services in each service
>>>> module. It programmatically links created components from IoC to a
>>>> finer grain at each software module, which holds the module Catalog of
>>>> commands.
>>>> d) User session is a proper place for programmatically interactions
>>>> of Jsf, IoC and CoR objects. For example user generated events from
>>>> Jsf is linked through a CoR adapter to dispatch action command as a
>>>> request to appropriate software module (such as
>>>> authentication/authorization, portlet, service, etc) whose responses
>>>> are rendered through Jsf view controller.
>>>>
>>>> BaTien
>>>> DBGROUPS
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> As long as you're willing to copy the base chain-config.xml file and
>>>>>> make a few modifications, then you could simply add your own command
>>>>>> which retrieves a value from the context under a well-known key and
>>>>>> inspects the value to see if validation passed or not. This exact
>>>>>> logic is the first thing executed in the CreateAction's execute
>>>>>> method, which doesn't lookup or create an action unless the form
>>>>>> validated.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> There's actually quite a few different ways to approach this,
>>>>> including the "optionally invoke some other command at this point"
>>>>> mentioned earlier in the thread, so you don't even *have* to
>>>>> cut-n-paste the standard version of the chain.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> You can start experimenting with commons-chain and struts-chain from
>>>>>> CVS Head if you want to see what's going on. You don't have to wait
>>>>>> for Struts 1.3.
>>>>>>
>>>>>>
>>>>>
>>>>> Indeed, Struts-Chain directly illustrates the fine-grained
>>>>> approach to
>>>>> defining the standard request processing chain that Joe describes.
>>>>> Nightly builds are available at:
>>>>>
>>>>> http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Craig
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Don Brown <mr...@twdata.org>.
I look at technology as solutions to problems. IoC solves the problem
of how can I define and configure a component external to the component
and calling code, and CoR tackles the problem of a how can I define a
process or sequence of processes in a pluggable manner.
True, both patterns have a "pluggable" property, but both a HashMap and
a SQL database have a "lookup" property. I think what you are getting
at is, in Struts, we need a way to allow the framework to be easily
customized by both framework extension projects and users. Both IoC and
CoR help us meet that goal, but by solving two different problems that
work against "pluggability". In Struts, I see the need for allowing the
user to have more control over the process of events, as well as what
components are used by that process. So yes, one goal perhaps, but two
different problems being solved in two different ways.
Don
Dakota Jack wrote:
>Without disagreeing with anything you have said, Don, I think the
>confusion is caused in part by the fact that CoR is anticipated in
>part for its pluggable nature. In this respect, there is a real
>connection in functionality between CoR and IoC that is not as
>attenuated as the one between HashMap and a SQL database but more like
>a properties file and a SQL database? You think?
>
>Jack
>
>
>On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <mr...@twdata.org> wrote:
>
>
>>Not you personally BaTien, I don't understand why some people seem to
>>confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
>>and worse, think they are somehow solving the same problem. IoC helps
>>us create components by managing their lifecycle and providing their
>>dependencies. CoR defines a process that let's us flexibly specify what
>>code to execute in what order.
>>
>>Sure, commons-chain does provide the default capability to create
>>commands and configure them with simple properties, but that isn't its
>>purpose and would certainly be replaced in any moderately complex usage,
>>most likely by some sort of IoC. It's like saying a HashMap conflicts
>>with a SQL database as they both store data. They are two very
>>different things with very different problems they are trying to solve.
>>
>>Don
>>
>>
>>
>>BaTien Duong wrote:
>>
>>
>>
>>>Craig McClanahan wrote:
>>>
>>>
>>>
>>>>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
>>>>wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>I need to have a hook into processValidate() on validation failure.
>>>>>>
>>>>>>Currently that can only be done by copy-and-pasting the
>>>>>>processValidate()
>>>>>>method from RequestProcessor into a subclass and sticking a hook
>>>>>>into the
>>>>>>middle of the code.
>>>>>>
>>>>>>When I asked about this on the dev list long ago, it was confirmed
>>>>>>that
>>>>>>there was no other way to do this, but that chain would eventually
>>>>>>provide
>>>>>>this flexibility.
>>>>>>
>>>>>>If the chain isn't configured at a fine-grain level, then it's not
>>>>>>all that
>>>>>>much more functional than the existing RequestProcessor.
>>>>>>
>>>>>>
>>>>>>
>>>>>The chain is configured at as fine-grained a level as you like, in
>>>>>XML. Hubert is talking about configuring the chain programatically
>>>>>as well, or at least in some way independent of the configuration of
>>>>>the primary processing chain.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Programmatic configuration is certainly feasible ... there's no
>>>>requirement in [chain] that you use the XML format at all. It's just
>>>>one option.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Greetings and request expert advice:
>>>
>>>Commons-chain invented by Craig proves to be very flexible and work in
>>>conjuction with other great technonologies. What i am trying to figure
>>>out is a proper and practical places for using CoR and IoC (such as
>>>Spring framework) in the construction and configuration of software
>>>objects. I put out some of my preliminary thinking and hope some
>>>experts care to add more arguments to enlighten us.
>>>
>>>1) Both CoR and IoC (and also Jsf setter injection) enable the
>>>configuration and linking objects via XML metadata. But IoC allows the
>>>object configuration at a finer level of object attributes and take
>>>care of the objects declared as singleton. In this sense, IoC is finer
>>>grain than CoR in object creation, configuration and management.
>>>
>>>2) CoR is very light weight and appropriate for programmatically
>>>created processes. It does not not have the complexity and the depth
>>>of plug-in features as Spring IoC.
>>>
>>>3) CoR is finer grain than IoC in the construction and rounting of
>>>services within and between software layers, while IoC is aprropriate
>>>at the application level.
>>>
>>>4) If we want to combine Jsf as view controller, Spring IoC and
>>>commons-chain CoR, a practical infrastructure may be something like
>>>followings:
>>> a) Jsf as a view controller takes care of objects directly related
>>>to User Interface (UI)
>>> b) Spring IoC takes the responsibility of object creation,
>>>especially singletons and fine grain configurations of objects not
>>>directly related to UI. This is a proper choice of configuration if
>>>other features of Spring framework such as application level event and
>>>aop are used.
>>> c) CoR is used to construct Front Controller a la pattern of Struts
>>>of each software module, the rounting of services among modules, and
>>>action commands (or chain) of specialized services in each service
>>>module. It programmatically links created components from IoC to a
>>>finer grain at each software module, which holds the module Catalog of
>>>commands.
>>> d) User session is a proper place for programmatically interactions
>>>of Jsf, IoC and CoR objects. For example user generated events from
>>>Jsf is linked through a CoR adapter to dispatch action command as a
>>>request to appropriate software module (such as
>>>authentication/authorization, portlet, service, etc) whose responses
>>>are rendered through Jsf view controller.
>>>
>>>BaTien
>>>DBGROUPS
>>>
>>>
>>>
>>>
>>>
>>>>>As long as you're willing to copy the base chain-config.xml file and
>>>>>make a few modifications, then you could simply add your own command
>>>>>which retrieves a value from the context under a well-known key and
>>>>>inspects the value to see if validation passed or not. This exact
>>>>>logic is the first thing executed in the CreateAction's execute
>>>>>method, which doesn't lookup or create an action unless the form
>>>>>validated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>There's actually quite a few different ways to approach this,
>>>>including the "optionally invoke some other command at this point"
>>>>mentioned earlier in the thread, so you don't even *have* to
>>>>cut-n-paste the standard version of the chain.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>You can start experimenting with commons-chain and struts-chain from
>>>>>CVS Head if you want to see what's going on. You don't have to wait
>>>>>for Struts 1.3.
>>>>>
>>>>>
>>>>>
>>>>Indeed, Struts-Chain directly illustrates the fine-grained approach to
>>>>defining the standard request processing chain that Joe describes.
>>>>Nightly builds are available at:
>>>>
>>>>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Joe
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Craig
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Dakota Jack <da...@gmail.com>.
Without disagreeing with anything you have said, Don, I think the
confusion is caused in part by the fact that CoR is anticipated in
part for its pluggable nature. In this respect, there is a real
connection in functionality between CoR and IoC that is not as
attenuated as the one between HashMap and a SQL database but more like
a properties file and a SQL database? You think?
Jack
On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <mr...@twdata.org> wrote:
> Not you personally BaTien, I don't understand why some people seem to
> confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
> and worse, think they are somehow solving the same problem. IoC helps
> us create components by managing their lifecycle and providing their
> dependencies. CoR defines a process that let's us flexibly specify what
> code to execute in what order.
>
> Sure, commons-chain does provide the default capability to create
> commands and configure them with simple properties, but that isn't its
> purpose and would certainly be replaced in any moderately complex usage,
> most likely by some sort of IoC. It's like saying a HashMap conflicts
> with a SQL database as they both store data. They are two very
> different things with very different problems they are trying to solve.
>
> Don
>
>
>
> BaTien Duong wrote:
>
> > Craig McClanahan wrote:
> >
> >> On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
> >> wrote:
> >>
> >>
> >>>
> >>>
> >>>> I need to have a hook into processValidate() on validation failure.
> >>>>
> >>>> Currently that can only be done by copy-and-pasting the
> >>>> processValidate()
> >>>> method from RequestProcessor into a subclass and sticking a hook
> >>>> into the
> >>>> middle of the code.
> >>>>
> >>>> When I asked about this on the dev list long ago, it was confirmed
> >>>> that
> >>>> there was no other way to do this, but that chain would eventually
> >>>> provide
> >>>> this flexibility.
> >>>>
> >>>> If the chain isn't configured at a fine-grain level, then it's not
> >>>> all that
> >>>> much more functional than the existing RequestProcessor.
> >>>>
> >>>
> >>> The chain is configured at as fine-grained a level as you like, in
> >>> XML. Hubert is talking about configuring the chain programatically
> >>> as well, or at least in some way independent of the configuration of
> >>> the primary processing chain.
> >>>
> >>>
> >>
> >>
> >> Programmatic configuration is certainly feasible ... there's no
> >> requirement in [chain] that you use the XML format at all. It's just
> >> one option.
> >>
> >>
> >>
> > Greetings and request expert advice:
> >
> > Commons-chain invented by Craig proves to be very flexible and work in
> > conjuction with other great technonologies. What i am trying to figure
> > out is a proper and practical places for using CoR and IoC (such as
> > Spring framework) in the construction and configuration of software
> > objects. I put out some of my preliminary thinking and hope some
> > experts care to add more arguments to enlighten us.
> >
> > 1) Both CoR and IoC (and also Jsf setter injection) enable the
> > configuration and linking objects via XML metadata. But IoC allows the
> > object configuration at a finer level of object attributes and take
> > care of the objects declared as singleton. In this sense, IoC is finer
> > grain than CoR in object creation, configuration and management.
> >
> > 2) CoR is very light weight and appropriate for programmatically
> > created processes. It does not not have the complexity and the depth
> > of plug-in features as Spring IoC.
> >
> > 3) CoR is finer grain than IoC in the construction and rounting of
> > services within and between software layers, while IoC is aprropriate
> > at the application level.
> >
> > 4) If we want to combine Jsf as view controller, Spring IoC and
> > commons-chain CoR, a practical infrastructure may be something like
> > followings:
> > a) Jsf as a view controller takes care of objects directly related
> > to User Interface (UI)
> > b) Spring IoC takes the responsibility of object creation,
> > especially singletons and fine grain configurations of objects not
> > directly related to UI. This is a proper choice of configuration if
> > other features of Spring framework such as application level event and
> > aop are used.
> > c) CoR is used to construct Front Controller a la pattern of Struts
> > of each software module, the rounting of services among modules, and
> > action commands (or chain) of specialized services in each service
> > module. It programmatically links created components from IoC to a
> > finer grain at each software module, which holds the module Catalog of
> > commands.
> > d) User session is a proper place for programmatically interactions
> > of Jsf, IoC and CoR objects. For example user generated events from
> > Jsf is linked through a CoR adapter to dispatch action command as a
> > request to appropriate software module (such as
> > authentication/authorization, portlet, service, etc) whose responses
> > are rendered through Jsf view controller.
> >
> > BaTien
> > DBGROUPS
> >
> >
> >
> >>> As long as you're willing to copy the base chain-config.xml file and
> >>> make a few modifications, then you could simply add your own command
> >>> which retrieves a value from the context under a well-known key and
> >>> inspects the value to see if validation passed or not. This exact
> >>> logic is the first thing executed in the CreateAction's execute
> >>> method, which doesn't lookup or create an action unless the form
> >>> validated.
> >>>
> >>>
> >>
> >>
> >> There's actually quite a few different ways to approach this,
> >> including the "optionally invoke some other command at this point"
> >> mentioned earlier in the thread, so you don't even *have* to
> >> cut-n-paste the standard version of the chain.
> >>
> >>
> >>
> >>> You can start experimenting with commons-chain and struts-chain from
> >>> CVS Head if you want to see what's going on. You don't have to wait
> >>> for Struts 1.3.
> >>>
> >>
> >>
> >> Indeed, Struts-Chain directly illustrates the fine-grained approach to
> >> defining the standard request processing chain that Joe describes.
> >> Nightly builds are available at:
> >>
> >> http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
> >>
> >>
> >>
> >>> Joe
> >>>
> >>>
> >>
> >>
> >> Craig
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >> .
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Don Brown <mr...@twdata.org>.
Not you personally BaTien, I don't understand why some people seem to
confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
and worse, think they are somehow solving the same problem. IoC helps
us create components by managing their lifecycle and providing their
dependencies. CoR defines a process that let's us flexibly specify what
code to execute in what order.
Sure, commons-chain does provide the default capability to create
commands and configure them with simple properties, but that isn't its
purpose and would certainly be replaced in any moderately complex usage,
most likely by some sort of IoC. It's like saying a HashMap conflicts
with a SQL database as they both store data. They are two very
different things with very different problems they are trying to solve.
Don
BaTien Duong wrote:
> Craig McClanahan wrote:
>
>> On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com>
>> wrote:
>>
>>
>>>
>>>
>>>> I need to have a hook into processValidate() on validation failure.
>>>>
>>>> Currently that can only be done by copy-and-pasting the
>>>> processValidate()
>>>> method from RequestProcessor into a subclass and sticking a hook
>>>> into the
>>>> middle of the code.
>>>>
>>>> When I asked about this on the dev list long ago, it was confirmed
>>>> that
>>>> there was no other way to do this, but that chain would eventually
>>>> provide
>>>> this flexibility.
>>>>
>>>> If the chain isn't configured at a fine-grain level, then it's not
>>>> all that
>>>> much more functional than the existing RequestProcessor.
>>>>
>>>
>>> The chain is configured at as fine-grained a level as you like, in
>>> XML. Hubert is talking about configuring the chain programatically
>>> as well, or at least in some way independent of the configuration of
>>> the primary processing chain.
>>>
>>>
>>
>>
>> Programmatic configuration is certainly feasible ... there's no
>> requirement in [chain] that you use the XML format at all. It's just
>> one option.
>>
>>
>>
> Greetings and request expert advice:
>
> Commons-chain invented by Craig proves to be very flexible and work in
> conjuction with other great technonologies. What i am trying to figure
> out is a proper and practical places for using CoR and IoC (such as
> Spring framework) in the construction and configuration of software
> objects. I put out some of my preliminary thinking and hope some
> experts care to add more arguments to enlighten us.
>
> 1) Both CoR and IoC (and also Jsf setter injection) enable the
> configuration and linking objects via XML metadata. But IoC allows the
> object configuration at a finer level of object attributes and take
> care of the objects declared as singleton. In this sense, IoC is finer
> grain than CoR in object creation, configuration and management.
>
> 2) CoR is very light weight and appropriate for programmatically
> created processes. It does not not have the complexity and the depth
> of plug-in features as Spring IoC.
>
> 3) CoR is finer grain than IoC in the construction and rounting of
> services within and between software layers, while IoC is aprropriate
> at the application level.
>
> 4) If we want to combine Jsf as view controller, Spring IoC and
> commons-chain CoR, a practical infrastructure may be something like
> followings:
> a) Jsf as a view controller takes care of objects directly related
> to User Interface (UI)
> b) Spring IoC takes the responsibility of object creation,
> especially singletons and fine grain configurations of objects not
> directly related to UI. This is a proper choice of configuration if
> other features of Spring framework such as application level event and
> aop are used.
> c) CoR is used to construct Front Controller a la pattern of Struts
> of each software module, the rounting of services among modules, and
> action commands (or chain) of specialized services in each service
> module. It programmatically links created components from IoC to a
> finer grain at each software module, which holds the module Catalog of
> commands.
> d) User session is a proper place for programmatically interactions
> of Jsf, IoC and CoR objects. For example user generated events from
> Jsf is linked through a CoR adapter to dispatch action command as a
> request to appropriate software module (such as
> authentication/authorization, portlet, service, etc) whose responses
> are rendered through Jsf view controller.
>
> BaTien
> DBGROUPS
>
>
>
>>> As long as you're willing to copy the base chain-config.xml file and
>>> make a few modifications, then you could simply add your own command
>>> which retrieves a value from the context under a well-known key and
>>> inspects the value to see if validation passed or not. This exact
>>> logic is the first thing executed in the CreateAction's execute
>>> method, which doesn't lookup or create an action unless the form
>>> validated.
>>>
>>>
>>
>>
>> There's actually quite a few different ways to approach this,
>> including the "optionally invoke some other command at this point"
>> mentioned earlier in the thread, so you don't even *have* to
>> cut-n-paste the standard version of the chain.
>>
>>
>>
>>> You can start experimenting with commons-chain and struts-chain from
>>> CVS Head if you want to see what's going on. You don't have to wait
>>> for Struts 1.3.
>>>
>>
>>
>> Indeed, Struts-Chain directly illustrates the fine-grained approach to
>> defining the standard request processing chain that Joe describes.
>> Nightly builds are available at:
>>
>> http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
>>
>>
>>
>>> Joe
>>>
>>>
>>
>>
>> Craig
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>> .
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by BaTien Duong <ba...@dbgroups.com>.
Craig McClanahan wrote:
>On Wed, 24 Nov 2004 11:03:23 -0700, BaTien Duong
><ba...@dbgroups.com> wrote:
>
>[snip]
>
>
>>3) CoR is finer grain than IoC in the construction and rounting of
>>services within and between software layers, while IoC is aprropriate at
>>the application level.
>>
>>
>
>I don't think of these as mutually exclusive. Why not set up a
>mechanism to configure your CoR command chains out of Chain and
>Command beans instantiated via your favorite IoC container?
>
>The XML format supported by Commons Chain is a convenience, not a requirement.
>
>
That is what i am suggesting and want to see if i may miss something.
Thanks.
BaTien
DBGROUPS
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 24 Nov 2004 11:03:23 -0700, BaTien Duong
<ba...@dbgroups.com> wrote:
[snip]
> 3) CoR is finer grain than IoC in the construction and rounting of
> services within and between software layers, while IoC is aprropriate at
> the application level.
I don't think of these as mutually exclusive. Why not set up a
mechanism to configure your CoR command chains out of Chain and
Command beans instantiated via your favorite IoC container?
The XML format supported by Commons Chain is a convenience, not a requirement.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by BaTien Duong <ba...@dbgroups.com>.
Craig McClanahan wrote:
>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com> wrote:
>
>
>>
>>
>>>I need to have a hook into processValidate() on validation failure.
>>>
>>>Currently that can only be done by copy-and-pasting the processValidate()
>>>method from RequestProcessor into a subclass and sticking a hook into the
>>>middle of the code.
>>>
>>>When I asked about this on the dev list long ago, it was confirmed that
>>>there was no other way to do this, but that chain would eventually provide
>>>this flexibility.
>>>
>>>If the chain isn't configured at a fine-grain level, then it's not all that
>>>much more functional than the existing RequestProcessor.
>>>
>>>
>>The chain is configured at as fine-grained a level as you like, in
>>XML. Hubert is talking about configuring the chain programatically
>>as well, or at least in some way independent of the configuration of
>>the primary processing chain.
>>
>>
>>
>
>Programmatic configuration is certainly feasible ... there's no
>requirement in [chain] that you use the XML format at all. It's just
>one option.
>
>
>
Greetings and request expert advice:
Commons-chain invented by Craig proves to be very flexible and work in
conjuction with other great technonologies. What i am trying to figure
out is a proper and practical places for using CoR and IoC (such as
Spring framework) in the construction and configuration of software
objects. I put out some of my preliminary thinking and hope some experts
care to add more arguments to enlighten us.
1) Both CoR and IoC (and also Jsf setter injection) enable the
configuration and linking objects via XML metadata. But IoC allows the
object configuration at a finer level of object attributes and take care
of the objects declared as singleton. In this sense, IoC is finer grain
than CoR in object creation, configuration and management.
2) CoR is very light weight and appropriate for programmatically created
processes. It does not not have the complexity and the depth of plug-in
features as Spring IoC.
3) CoR is finer grain than IoC in the construction and rounting of
services within and between software layers, while IoC is aprropriate at
the application level.
4) If we want to combine Jsf as view controller, Spring IoC and
commons-chain CoR, a practical infrastructure may be something like
followings:
a) Jsf as a view controller takes care of objects directly related
to User Interface (UI)
b) Spring IoC takes the responsibility of object creation,
especially singletons and fine grain configurations of objects not
directly related to UI. This is a proper choice of configuration if
other features of Spring framework such as application level event and
aop are used.
c) CoR is used to construct Front Controller a la pattern of Struts
of each software module, the rounting of services among modules, and
action commands (or chain) of specialized services in each service
module. It programmatically links created components from IoC to a finer
grain at each software module, which holds the module Catalog of commands.
d) User session is a proper place for programmatically interactions
of Jsf, IoC and CoR objects. For example user generated events from Jsf
is linked through a CoR adapter to dispatch action command as a request
to appropriate software module (such as authentication/authorization,
portlet, service, etc) whose responses are rendered through Jsf view
controller.
BaTien
DBGROUPS
>>As long as you're willing to copy the base chain-config.xml file and
>>make a few modifications, then you could simply add your own command
>>which retrieves a value from the context under a well-known key and
>>inspects the value to see if validation passed or not. This exact
>>logic is the first thing executed in the CreateAction's execute
>>method, which doesn't lookup or create an action unless the form
>>validated.
>>
>>
>>
>
>There's actually quite a few different ways to approach this,
>including the "optionally invoke some other command at this point"
>mentioned earlier in the thread, so you don't even *have* to
>cut-n-paste the standard version of the chain.
>
>
>
>>You can start experimenting with commons-chain and struts-chain from
>>CVS Head if you want to see what's going on. You don't have to wait
>>for Struts 1.3.
>>
>>
>
>Indeed, Struts-Chain directly illustrates the fine-grained approach to
>defining the standard request processing chain that Joe describes.
>Nightly builds are available at:
>
>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
>
>
>
>>Joe
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <jo...@germuska.com> wrote:
>
>
> >I need to have a hook into processValidate() on validation failure.
> >
> >Currently that can only be done by copy-and-pasting the processValidate()
> >method from RequestProcessor into a subclass and sticking a hook into the
> >middle of the code.
> >
> >When I asked about this on the dev list long ago, it was confirmed that
> >there was no other way to do this, but that chain would eventually provide
> >this flexibility.
> >
> >If the chain isn't configured at a fine-grain level, then it's not all that
> >much more functional than the existing RequestProcessor.
>
> The chain is configured at as fine-grained a level as you like, in
> XML. Hubert is talking about configuring the chain programatically
> as well, or at least in some way independent of the configuration of
> the primary processing chain.
>
Programmatic configuration is certainly feasible ... there's no
requirement in [chain] that you use the XML format at all. It's just
one option.
> As long as you're willing to copy the base chain-config.xml file and
> make a few modifications, then you could simply add your own command
> which retrieves a value from the context under a well-known key and
> inspects the value to see if validation passed or not. This exact
> logic is the first thing executed in the CreateAction's execute
> method, which doesn't lookup or create an action unless the form
> validated.
>
There's actually quite a few different ways to approach this,
including the "optionally invoke some other command at this point"
mentioned earlier in the thread, so you don't even *have* to
cut-n-paste the standard version of the chain.
> You can start experimenting with commons-chain and struts-chain from
> CVS Head if you want to see what's going on. You don't have to wait
> for Struts 1.3.
Indeed, Struts-Chain directly illustrates the fine-grained approach to
defining the standard request processing chain that Joe describes.
Nightly builds are available at:
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
>
> Joe
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Joe Germuska <Jo...@Germuska.com>.
>I need to have a hook into processValidate() on validation failure.
>
>Currently that can only be done by copy-and-pasting the processValidate()
>method from RequestProcessor into a subclass and sticking a hook into the
>middle of the code.
>
>When I asked about this on the dev list long ago, it was confirmed that
>there was no other way to do this, but that chain would eventually provide
>this flexibility.
>
>If the chain isn't configured at a fine-grain level, then it's not all that
>much more functional than the existing RequestProcessor.
The chain is configured at as fine-grained a level as you like, in
XML. Hubert is talking about configuring the chain programatically
as well, or at least in some way independent of the configuration of
the primary processing chain.
As long as you're willing to copy the base chain-config.xml file and
make a few modifications, then you could simply add your own command
which retrieves a value from the context under a well-known key and
inspects the value to see if validation passed or not. This exact
logic is the first thing executed in the CreateAction's execute
method, which doesn't lookup or create an action unless the form
validated.
You can start experimenting with commons-chain and struts-chain from
CVS Head if you want to see what's going on. You don't have to wait
for Struts 1.3.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Mike Kienenberger <mk...@alaska.net>.
Joe Germuska <Jo...@Germuska.com> wrote:
> > into an "action-chain" and "view-chain", but maybe it should be more
> > finely grained?
Hubert Rabago <hr...@gmail.com> wrote:
> The extreme case I have in mind would be one chain for each step that
> the current request processor does. Yes, I know, it's extreme. At
> this point, it's just an idea I'm bringing up.
I'd also like to see this.
I need to have a hook into processValidate() on validation failure.
Currently that can only be done by copy-and-pasting the processValidate()
method from RequestProcessor into a subclass and sticking a hook into the
middle of the code.
When I asked about this on the dev list long ago, it was confirmed that
there was no other way to do this, but that chain would eventually provide
this flexibility.
If the chain isn't configured at a fine-grain level, then it's not all that
much more functional than the existing RequestProcessor.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Hubert Rabago <hr...@gmail.com>.
Inline.
On Tue, 23 Nov 2004 11:42:37 -0600, Joe Germuska <jo...@germuska.com> wrote:
> At 11:26 AM -0600 11/23/04, Hubert Rabago wrote:
> >It would be nice if plugins can inject chain elements at specific
> >points in the chain at startup, programatically. This way, plugins
> >can be programmed to modify specific portions of the chain that it is
> >concerned with, without affecting other portions of the chain or
> >modifications of other plugins.
>
> I don't think you could do this with zero modifications to the
> chain-config, but it would be easy enough to add one or more
> LookupCommands like the one in the current example chain-config which
> look for injected commands under specific names and in specific
> catalogs. If you thought that there were some clear logical ways to
> group the base chain-config.xml, we could have it run as a series of
> lookup commands. I already am thinking that we should partition it
> into an "action-chain" and "view-chain", but maybe it should be more
> finely grained?
>
The extreme case I have in mind would be one chain for each step that
the current request processor does. Yes, I know, it's extreme. At
this point, it's just an idea I'm bringing up.
> On the other hand, why not just specify an alternate chain-config
> file which does exactly what you need it to do?
Specific apps would be able to do this, but I was trying to think from
the perspective of a plugin developer. I haven't looked at an example
yet, but would the use of tiles require both a struts-config change to
activate the plugin, as well as a chain-config change to modify the
chain? What if an app were to use multiple plugins that inject their
own commands at different points? Do we leave the changes to the
end-user/app-developer?
> Or are you looking for a more comprehensive and flexible solution,
> like Maven's "preGoal" and "postGoal" definitions which allow you to
> add arbitrary goals anywhere. This would be tricky right now because
> commands aren't required to have names.
>
> Joe
>
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain enhancement idea
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:26 AM -0600 11/23/04, Hubert Rabago wrote:
>How would plugins work with the chain configuration?
>
>I've written ActionServlet/RequestProcessor extensions and plugins in
>the past. Often, the reason is to inject custom pre-, actual, or
>post-processing at specific steps. An example would Tiles, which IIRC
>intercepts the forward processing to see if the destination is a
>configured tile, otherwise lets the default forward processing
>continue.
>
>It would be nice if plugins can inject chain elements at specific
>points in the chain at startup, programatically. This way, plugins
>can be programmed to modify specific portions of the chain that it is
>concerned with, without affecting other portions of the chain or
>modifications of other plugins.
I don't think you could do this with zero modifications to the
chain-config, but it would be easy enough to add one or more
LookupCommands like the one in the current example chain-config which
look for injected commands under specific names and in specific
catalogs. If you thought that there were some clear logical ways to
group the base chain-config.xml, we could have it run as a series of
lookup commands. I already am thinking that we should partition it
into an "action-chain" and "view-chain", but maybe it should be more
finely grained?
On the other hand, why not just specify an alternate chain-config
file which does exactly what you need it to do?
Or are you looking for a more comprehensive and flexible solution,
like Maven's "preGoal" and "postGoal" definitions which allow you to
add arbitrary goals anywhere. This would be tricky right now because
commands aren't required to have names.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex