You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/04/04 02:36:13 UTC
RE: Splitting struts-config into multiple jar and read them as
reso urce stream
>I'm just making this up as I go, but what if there were an optional
>servlet init param which could consist of one or more class names,
>where each class implemented a "StrutsConfigurator" interface. Then
>in servlet.init(), the servlet could instantiate each and pass
>itself to the configure method (or maybe just pass the
>ServletContext, if that's safer or better).
I decided to take a look at this today, and it's a little bit tangly.
I figure that it's not something to commit until we cut Struts 1.2.1
anyway, but here is a bit about how I'm starting and some questions.
All feedback is welcomed.
I created an interface: org.apache.struts.action.StrutsConfigurator.
I have no great love for the name nor insistence on it being in that
package.
I wanted it to have a single method:
public void configure(ServletConfig config) throws Exception;
I'm open to any strong opinions about whether it should throw
ServletException instead, or anything else.
However, it's tricky to only pass in the ServletConfig, as some of
the legacy code that I'm trying to move out from ActionServlet into
an implementation class (currently named "ClassicConfigurator") wants
access to the ActionServlet itself. Specifically, the datasources
are still a member of the ActionServlet, rather than being shared in
the Application Context. I have never used Struts to manage
datasources and don't really plan to, but I don't want to mess anyone
up. Should we move those into the ServletContext so that various
configurators can get at them? Or just relax and pass ActionServlet
into the configurator instead? I'd really like to avoid that if
possible.
However, I now remember, we also need an ActionServlet to initialize
plugins. Do I just have to bite the bullet? Or can we figure out
another way? I can't think of anything which would be backwards
compatible. I just liked the idea of keeping the actual
ActionServlet class out of things, especially as we pull more and
more functionality out of that class.
In a different vein, I was wondering about handling "internal"
message resources. I was thinking about copying the pattern from
ActionServlet, but there are classes (like ExceptionHandler) which do
essentially the same thing but in a slightly different pattern. In
the spirit of consistency, is there a "preferred" implementation
pattern that we should use for this?
Assuming that all this gets straightened out, then, the final step
would be to deprecate the ActionServlet init* methods which are
copied into ClassicConfigurator and to re-implement the middle-part
of init() to initialize one or more configurators and execute their
configure methods. But maybe we'll get into that a little more later.
My first pass was pretty crude, just copying stuff from ActionServlet
into ClassicConfigurator. It seems like it might make sense to make
it easier for things like a configDigester to be shared, but then,
perhaps its not appropriate to assume that extended config rulesets
that apply to one configurator apply to another. If that's the case,
well, everyone already has access to the ConfigRuleSet class which
covers the basics.
Looking forward to some feedback...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting
struts-config into multiple jar...)
Posted by Joe Germuska <Jo...@Germuska.com>.
>>Just thought of one more thing: technically, since the Configurator
>>has access to the entire ServletContext, should we have a destroy()
>>method also? I would kind of prefer to leave that out and keep it
>>simple, since otherwise it might get confusing about where cleanup
>>responsibilities lie... but we may not be able to avoid it. (Then
>>again, we may be able to wait until someone asks for it/has a use
>>case.)
>
>Yes, I can see use cases for this (such as saving current state
>information that will be used the next time the configuration is
>loaded). But if you add a destroy method, haven't you just
>recreated the PlugIn API?
More or less, yes. That had crossed my mind. The major difference
being, of course, when the methods get called. I suppose one could
write a plugin which instantiated more action mappings, form beans,
etc. (I bet someone already has!) but it doesn't seem very tidy...
If someone had an idea for how to coordinate the timing of calls to
plugins to distinguish between configuration responsibilities (the
new use case) and other plugin uses, I'd be happy to hear it. I was
more looking for "the simplest thing that could possibly work" to
open up configuration along the lines of recent discussion on the DEV
list.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Core BSF Action [was Re: Refactoring Struts Initialization ...]
Posted by Don Brown <mr...@twdata.org>.
It is too bad we don't have a Cocoon "blocks" type ability. Their block
system allows them to easily build special versions of Cocoon with only
the capabilities desired. Their system encourages new ideas and
capabilities with minimal impact to those that don't need the additional
functionality.
Don
Ted Husted wrote:
>On Mon, 05 Apr 2004 11:14:45 -0700, Don Brown wrote:
>
>
>>True, however that is only if your actions are Java classes. I've
>>developed Struts apps using scripting languages, particularly
>>BeanShell, to get a quick prototype of the application up and
>>running. Later, I can easily change those scripts to Java classes
>>if there is need.
>>
>>
>
>I'd be in favor of moving Struts BSF into the core, as one of our standard Actions.
>
>http://struts.sourceforge.net/struts-bsf/index.html
>
>This will create another compile-time dependency for Struts, and runtime if you use it, but I think the utility is well worth the cost.
>
>Given DynaActionForms and the Validator, we can create working "straw" applications without any Java code. The addition of Don's BSF Action makes MVC applications available to JSP writers with a scripting skill set. What could be simpler than that? :)
>
>-Ted.
>
>
>
>---------------------------------------------------------------------
>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
Core BSF Action [was Re: Refactoring Struts Initialization ...]
Posted by Ted Husted <hu...@apache.org>.
On Mon, 05 Apr 2004 11:14:45 -0700, Don Brown wrote:
> True, however that is only if your actions are Java classes. I've
> developed Struts apps using scripting languages, particularly
> BeanShell, to get a quick prototype of the application up and
> running. Later, I can easily change those scripts to Java classes
> if there is need.
I'd be in favor of moving Struts BSF into the core, as one of our standard Actions.
http://struts.sourceforge.net/struts-bsf/index.html
This will create another compile-time dependency for Struts, and runtime if you use it, but I think the utility is well worth the cost.
Given DynaActionForms and the Validator, we can create working "straw" applications without any Java code. The addition of Don's BSF Action makes MVC applications available to JSP writers with a scripting skill set. What could be simpler than that? :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)
Posted by Ted Husted <hu...@apache.org>.
On Mon, 05 Apr 2004 12:49:07 -0700 (PDT), David Graham wrote:
> That's an interesting point. I really think ease of use should be
> a major priority for Struts 2.0 and this factors into that goal.
> There are people who strongly dislike Struts and we should listen
> to their complaints; a large number of which center around
> complexity.
Another good idea would be to review the 242 outstanding enhancement requests -- made by people who actually like Struts -- for things that we could do in 2.x -or- 1.x . ;)
Heck, 29 of these even have patches :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)
Posted by David Graham <gr...@yahoo.com>.
--- Don Brown <mr...@twdata.org> wrote:
> Craig R. McClanahan wrote:
>
> > <snip />
> >
> > I personally believe that, even if we implemented dynamic
> > reconfiguration support for the config files themselves, developers
> > will be disappointed in how little this helps in a development cycle
> > -- you're not going to pick up added or changed Java classes without a
>
> > container-managed restart of the webapp (except on *some* containers
> > where you haven't yet loaded the class in question), so typical
> > development use cases like "add the next Action" are going to require
> > restarts anyway.
>
> True, however that is only if your actions are Java classes. I've
> developed Struts apps using scripting languages, particularly BeanShell,
>
> to get a quick prototype of the application up and running. Later, I
> can easily change those scripts to Java classes if there is need. For
> Struts to detect a configuration file change and automatically reload
> the config, as Cocoon can do (can be turned off of course), would go a
> long way to make it possible to quickly develop/prototype Struts
> applications.
That's an interesting point. I really think ease of use should be a major
priority for Struts 2.0 and this factors into that goal. There are people
who strongly dislike Struts and we should listen to their complaints; a
large number of which center around complexity.
David
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting struts-config
into multiple jar...)
Posted by Don Brown <mr...@twdata.org>.
Craig R. McClanahan wrote:
> <snip />
>
> I personally believe that, even if we implemented dynamic
> reconfiguration support for the config files themselves, developers
> will be disappointed in how little this helps in a development cycle
> -- you're not going to pick up added or changed Java classes without a
> container-managed restart of the webapp (except on *some* containers
> where you haven't yet loaded the class in question), so typical
> development use cases like "add the next Action" are going to require
> restarts anyway.
True, however that is only if your actions are Java classes. I've
developed Struts apps using scripting languages, particularly BeanShell,
to get a quick prototype of the application up and running. Later, I
can easily change those scripts to Java classes if there is need. For
Struts to detect a configuration file change and automatically reload
the config, as Cocoon can do (can be turned off of course), would go a
long way to make it possible to quickly develop/prototype Struts
applications.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting struts-config
into multiple jar...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Joe Germuska wrote:
> [snip]
> While we're on the thread, I remembered one other thing: right now,
> the configuration freezes each module config. I've never been 100%
> clear on why Struts uses 'freeze' to lock things down. Is there any
> legitimate reason for more than one configurator to be involved in
> setting up a ModuleConfig? If so, we need to either take out the
> freezing or push it up into ActionServlet to do after it has given
> each StrutsConfigurator a chance to do its thing. In my "draft", I
> just left the moduleConfig.freeze() inside the "ClassicConfigurator",
> but I wanted to check on this question.
The original motivation for freezing the configuration was to allow
HashMap lookups during execution to run without time-wasting (for the
99.9% use case) synchronization. When 1.1 introduced PlugIn, we also
moved the freeze() call to after PlugIns have executed their
initialization, so that PlugIns can dynamically modify the configuration
information as well. We'd certainly want to do the same thing with
configurators ... not freeze until they've all had their shot at
updating the configuration.
I personally believe that, even if we implemented dynamic
reconfiguration support for the config files themselves, developers will
be disappointed in how little this helps in a development cycle --
you're not going to pick up added or changed Java classes without a
container-managed restart of the webapp (except on *some* containers
where you haven't yet loaded the class in question), so typical
development use cases like "add the next Action" are going to require
restarts anyway.
>
> Just thought of one more thing: technically, since the Configurator
> has access to the entire ServletContext, should we have a destroy()
> method also? I would kind of prefer to leave that out and keep it
> simple, since otherwise it might get confusing about where cleanup
> responsibilities lie... but we may not be able to avoid it. (Then
> again, we may be able to wait until someone asks for it/has a use case.)
Yes, I can see use cases for this (such as saving current state
information that will be used the next time the configuration is
loaded). But if you add a destroy method, haven't you just recreated
the PlugIn API? Indeed, isn't configuring Struts just a special case of
what PlugIn is for (albeit its one that we'd probably want to ensure ran
before user-defined PlugIns)?
>
> Joe
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)
Posted by Ted Husted <hu...@apache.org>.
On Sun, 04 Apr 2004 09:04:24 -0600, Joe Germuska wrote:
>> IMO, Struts datasource handling should be deprecated and removed.
>> It had it's place in the past but now Struts has no business
>> "managing" datasources; that's the containers job and most of
>> them do it better than Struts. I would like part of Struts 2.x
>> to focus on simplifying users' lives and removing this feature
>> follows in that spirit; but that may be for another thread.
>>
>
> Well, I was thinking about doing this refactoring in a pre 2.x
> timeline and maintaining compatibility. But I agree that
> datasource handling should be left out of Struts.
It's important to note that the DataSource manager is not managing the underlying implementations in the way a container would, but making them available through a "catalog" interface. This component just takes whatever datasource instances it is handed and retains the references as a list. Before deprecating and removing anything like this, we should create a standalone version that people could plugin. I am quite certain many people still use it and 1.x is suppose to be backward compatible. Someone could add it to the legacy package, or find some other home for it. But, personally, I'd say removing it would seem to be more trouble than leaving it be. Unlike our ill-fated datasource implementation, the manager is zero maintenance. :)
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Refactoring Struts Initialization (was RE: Splitting
struts-config into multiple jar...)
Posted by Joe Germuska <Jo...@Germuska.com>.
>This thread seems to have taken a turn into something I'm interested in;
>too bad the subject didn't change with it so I could have started
>following sooner.
You really didn't miss much yet...
>I really don't like methods that throw Exception so I like
>ServletException better.
No problem. I just really don't like many layers of wrapper
exceptions that make it hard to get to the root of the problem.
ExceptionUtils in commons-lang helps, of course. Anyway, in this
case, it's unlikely that there will be many layers, so consider that
changed.
>IMO, Struts datasource handling should be deprecated and removed. It had
>it's place in the past but now Struts has no business "managing"
>datasources; that's the containers job and most of them do it better than
>Struts. I would like part of Struts 2.x to focus on simplifying users'
>lives and removing this feature follows in that spirit; but that may be
>for another thread.
Well, I was thinking about doing this refactoring in a pre 2.x
timeline and maintaining compatibility. But I agree that datasource
handling should be left out of Struts.
>At this point isn't ActionServlet merely init. code plus delegation to the
>RequestProcessor? In the future ActionServlet may just be delegating to
>init. classes and to Commons Chain so I agree that we should probably
>limit passing it around. It's really more of a starting point for a
>request than anything else.
Yes, it is, but the PlugIn interface still calls for it. Of course,
the Servlet is already storing itself in Application context under
Globals.ACTION_SERVLET_KEY, so I suppose we could leave it out of the
interface while still maintaining backwards compatibility. Since
ActionServlet.datasources is protected and I was putting
"ClassicConfigurator" in the o.a.s.action package, that's really all
that's necessary to deal with both of these issues.
How does that sound?
Of course, ActionServlet is tangled up in the API for Action and
ActionForm too, so we probably aren't going to really be able to
clean that up before Struts 2. Still, I think it's good to point the
direction. Besides backwards compatibility, in those cases, is there
any reason we should be passing the Servlet and not just the
ServletContext?
While we're on the thread, I remembered one other thing: right now,
the configuration freezes each module config. I've never been 100%
clear on why Struts uses 'freeze' to lock things down. Is there any
legitimate reason for more than one configurator to be involved in
setting up a ModuleConfig? If so, we need to either take out the
freezing or push it up into ActionServlet to do after it has given
each StrutsConfigurator a chance to do its thing. In my "draft", I
just left the moduleConfig.freeze() inside the "ClassicConfigurator",
but I wanted to check on this question.
Just thought of one more thing: technically, since the Configurator
has access to the entire ServletContext, should we have a destroy()
method also? I would kind of prefer to leave that out and keep it
simple, since otherwise it might get confusing about where cleanup
responsibilities lie... but we may not be able to avoid it. (Then
again, we may be able to wait until someone asks for it/has a use
case.)
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Refactoring initiaization code [was: Splitting struts-config into multiple jar and read them as reso urce stream]
Posted by Ted Husted <hu...@apache.org>.
Just changing the subject line per David's suggestion :)
On Sat, 03 Apr 2004 23:05:44 -0800 (PST), David Graham wrote:
> This thread seems to have taken a turn into something I'm
> interested in; too bad the subject didn't change with it so I could
> have started following sooner. If this is about refactoring Struts
> initialization code out of ActionServlet then I'm definitely
> interested. In fact, I took a look at this some time ago but
> stopped to pursue other items.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Splitting struts-config into multiple jar and read them as reso urce stream
Posted by David Graham <gr...@yahoo.com>.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> >I'm just making this up as I go, but what if there were an optional
> >servlet init param which could consist of one or more class names,
> >where each class implemented a "StrutsConfigurator" interface. Then
> >in servlet.init(), the servlet could instantiate each and pass
> >itself to the configure method (or maybe just pass the
> >ServletContext, if that's safer or better).
>
> I decided to take a look at this today, and it's a little bit tangly.
> I figure that it's not something to commit until we cut Struts 1.2.1
> anyway, but here is a bit about how I'm starting and some questions.
> All feedback is welcomed.
This thread seems to have taken a turn into something I'm interested in;
too bad the subject didn't change with it so I could have started
following sooner. If this is about refactoring Struts initialization code
out of ActionServlet then I'm definitely interested. In fact, I took a
look at this some time ago but stopped to pursue other items.
>
> I created an interface: org.apache.struts.action.StrutsConfigurator.
> I have no great love for the name nor insistence on it being in that
> package.
>
> I wanted it to have a single method:
> public void configure(ServletConfig config) throws Exception;
>
> I'm open to any strong opinions about whether it should throw
> ServletException instead, or anything else.
I really don't like methods that throw Exception so I like
ServletException better.
>
> However, it's tricky to only pass in the ServletConfig, as some of
> the legacy code that I'm trying to move out from ActionServlet into
> an implementation class (currently named "ClassicConfigurator") wants
> access to the ActionServlet itself. Specifically, the datasources
> are still a member of the ActionServlet, rather than being shared in
> the Application Context. I have never used Struts to manage
> datasources and don't really plan to, but I don't want to mess anyone
> up. Should we move those into the ServletContext so that various
> configurators can get at them? Or just relax and pass ActionServlet
> into the configurator instead? I'd really like to avoid that if
> possible.
IMO, Struts datasource handling should be deprecated and removed. It had
it's place in the past but now Struts has no business "managing"
datasources; that's the containers job and most of them do it better than
Struts. I would like part of Struts 2.x to focus on simplifying users'
lives and removing this feature follows in that spirit; but that may be
for another thread.
>
> However, I now remember, we also need an ActionServlet to initialize
> plugins. Do I just have to bite the bullet? Or can we figure out
> another way? I can't think of anything which would be backwards
> compatible. I just liked the idea of keeping the actual
> ActionServlet class out of things, especially as we pull more and
> more functionality out of that class.
At this point isn't ActionServlet merely init. code plus delegation to the
RequestProcessor? In the future ActionServlet may just be delegating to
init. classes and to Commons Chain so I agree that we should probably
limit passing it around. It's really more of a starting point for a
request than anything else.
David
>
> In a different vein, I was wondering about handling "internal"
> message resources. I was thinking about copying the pattern from
> ActionServlet, but there are classes (like ExceptionHandler) which do
> essentially the same thing but in a slightly different pattern. In
> the spirit of consistency, is there a "preferred" implementation
> pattern that we should use for this?
>
> Assuming that all this gets straightened out, then, the final step
> would be to deprecate the ActionServlet init* methods which are
> copied into ClassicConfigurator and to re-implement the middle-part
> of init() to initialize one or more configurators and execute their
> configure methods. But maybe we'll get into that a little more later.
>
> My first pass was pretty crude, just copying stuff from ActionServlet
> into ClassicConfigurator. It seems like it might make sense to make
> it easier for things like a configDigester to be shared, but then,
> perhaps its not appropriate to assume that extended config rulesets
> that apply to one configurator apply to another. If that's the case,
> well, everyone already has access to the ConfigRuleSet class which
> covers the basics.
>
> Looking forward to some feedback...
> Joe
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Imagine if every Thursday your shoes exploded if you tied them
> the usual way. This happens to us all the time with computers, and
> nobody thinks of complaining."
> -- Jef Raskin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org