You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by nicolas De Loof <ni...@cgey.com> on 2004/04/01 09:33:48 UTC
Re: Splitting struts-config into multiple jar and read them as reso
urce stream
Just a detail I just think about :
Using this patch, web can develop a Struts module as a subproject and
include it in WAR as a jar, but what's about tiles-def.xml and
validation.xml ?
This plugins should get a similar enhancement to be able to build
jar-modules with Struts "commonly used" plugins.
Nico.
nicolas De Loof a écrit :
> This means that included module jar must be built with knowledge of
> the module on witch it will be associated. Not a big issue, as loading
> from jars should be great for big apps.
>
> Nico.
>
> Filippo Munafò a écrit :
>
>> Yes, the patch has trasparently extended also non default module config.
>>
>> ActionServlet.init() (unmodified) call initModuleConfig first for
>> default module
>> and then for each module config found in controller init parameters.
>>
>> So you can do something like this:
>>
>> <init-param>
>> <param-name>config</param-name>
>>
>> <param-value>/WEB-INF/struts-config.xml,META-INF/struts-config.xml</param-value>
>>
>> </init-param>
>> <init-param>
>> <param-name>config/module1</param-name>
>>
>> <param-value>/WEB-INF/module1/struts-config.xml,META-INF/module1/struts-config.xml</param-value>
>>
>> </init-param>
>>
>> Or, for example, you can put module1 struts-config only in jar and
>> the default only in WEB-INF:
>>
>> <init-param>
>> <param-name>config</param-name>
>> <param-value>/WEB-INF/struts-config.xml</param-value>
>> </init-param>
>> <init-param>
>> <param-name>config/module1</param-name>
>> <param-value>META-INF/module1/struts-config.xml</param-value>
>> </init-param>
>>
>>
>> Filippo
>>
>> -----Original Message-----
>> From: nicolas De Loof [mailto:nicolas.deloof@cgey.com] Sent:
>> Wednesday, March 31, 2004 10:27
>> To: Struts Developers List
>> Subject: Re: Splitting struts-config into multiple jar and read them
>> as reso urce stream
>>
>> As far as I understand your patch, config included in jars is added
>> to default module config.
>> Is they're any way to associate a jar (including config) to a struts
>> module ?
>>
>> Nico.
>>
>> Filippo Munafò a écrit :
>>
>>
>>
>>> Following your suggestion, I've just submitted a patch as
>>> bugzilla Enhancement (#28051).
>>>
>>> I've tried to make as few changes as possible to the source of
>>> action servlet in order to avoid any regression.
>>>
>>> Is it ok?
>>>
>>> Filippo
>>>
>>> -----Original Message-----
>>> From: Craig R. McClanahan [mailto:craigmcc@apache.org] Sent:
>>> Tuesday, March 23, 2004 18:38
>>> To: Struts Developers List
>>> Subject: Re: Splitting struts-config into multiple jar and read them
>>> as resource stream
>>>
>>> Quoting Ted Husted <hu...@apache.org>:
>>>
>>>
>>>
>>>
>>>
>>>> On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote:
>>>>
>>>>
>>>>
>>>>> Perfect! What you did in JSF is exatcly what we need:
>>>>>
>>>>> "the controller servlet automatically recognize 'META-INF/struts-
>>>>> config.xml' resources in any JAR files that were included in the
>>>>> application."
>>>>>
>>>>> When in struts?
>>>>>
>>>>> Can I help?
>>>>>
>>>>>
>>>>
>>>> I think we do the same sort of thing in Commons Chain, n'est pas?
>>>>
>>>>
>>>>
>>>
>>> This particular functionality was in relationship to automatically
>>> finding and
>>> loading struts-config.xml files (contributed by JAR files dropped in
>>> to the
>>> WAR) without having to explicitly note them in context init
>>> parameters. It
>>> doesn't really relate to per-request processing.
>>>
>>> I can't do this today, but anyone who wants to help on this need
>>> only submit an
>>> enhancement request (with a patch) to ActionServlet.init() to scan the
>>> configuration resources in addition to what it already does. The
>>> secret sauce
>>> is to use ClassLoader.findResources() to get the list of URLs to be
>>> processed.
>>>
>>>
>>>
>>>
>>>
>>>> -Ted.
>>>>
>>>>
>>>
>>> Craig
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: struts-dev-help@jakarta.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: 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
RE: Splitting struts-config into multiple jar and read them as
reso urce stream
Posted by Joe Germuska <Jo...@Germuska.com>.
>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: Splitting struts-config into multiple jar and read them as
reso urce stream
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:48 PM -0800 4/1/04, Martin Cooper wrote:
>4) As I've mentioned before (in this same thread, I think), I believe we
>need to factor out the configuration code and make it pluggable.
Although this is Martin's fourth point, I think it should be the
starting point. If we move to a way where configuration is
pluggable, then someone could experiment with the classpath-scanning
autoconfig until they are sure that it is workable before introducing
it, and/or introduce it in a way which is clearly experimental.
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).
If this parameter were undefined, the default configurator would be
called (which would just be the factored out current behavior.) If
the parameter were defined, then one would need to explicitly list
the default configurator.
Like I said, this is kind of off the cuff, but I do think this is the
first step.
While we're talking about it, we should have in mind the frequently
requested feature of dynamic reloading, although I don't think we
should let it stop anything.
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: Splitting struts-config into multiple jar and read them as reso urce stream
Posted by Ted Husted <hu...@apache.org>.
On Thu, 01 Apr 2004 22:48:03 -0800, Martin Cooper wrote:
> Let me throw out a few thoughts on this thread, and modules in
> general, as I try to catch up. (I'm still in this seemingly-
> perpetual state of not having the time to fully expound on my
> thoughts on future enhancements to modules, darn it! ;)
Another thing to think about is that we also want to position ourselves to support JAR 168 portlets before long.
Is there going to be a relationship between portlets and modules? Are we going to be able to use modules as portlets? Or are we going to be able to have modules within portlets?
> 4) As I've mentioned before (in this same thread, I think), I
> believe we need to factor out the configuration code and make it
> pluggable. Going forward, the Struts Core should rely on certain
> configuration objects being defined, without caring about how they
> got there. The default config reader, obviously, would do what we
> do today, but we should make it easy to provide an alternate config
> reader that might do its thing in an entirely different manner.
> (I'm sure the IoC fans out there will have something to say on this
> topic. ;)
+1
I haven't looked at Joe's code yet, but it would be very helpful if we could manufacture configurations in a testing environment, without having to read them in from an XML file. Once we have contexts in the signatures, it will be easy to test the core components independently.
-Ted.
---------------------------------------------------------------------
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 Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, April 01, 2004 2:00 AM
> To: Struts Developers List
> Subject: Re: Splitting struts-config into multiple jar and read them as
> reso urce stream
>
>
> nicolas De Loof wrote:
>
> > Just a detail I just think about :
> > Using this patch, web can develop a Struts module as a subproject and
> > include it in WAR as a jar, but what's about tiles-def.xml and
> > validation.xml ?
> >
> I agree with your thinking ... if we concieve that a module should be
> "self configured" simply by having its JAR file included in the webapp,
> then we need to cover these bases as well.
>
> > This plugins should get a similar enhancement to be able to build
> > jar-modules with Struts "commonly used" plugins.
>
> And should be able to adapt to whatever multi-module design
> emerges as well.
Absolutely. I would much rather think all of this through, rather than rush
into an enhancement that seems interesting on the face of it, but that we'd
end up wanting to change in the long (or even short) term.
Let me throw out a few thoughts on this thread, and modules in general, as I
try to catch up. (I'm still in this seemingly-perpetual state of not having
the time to fully expound on my thoughts on future enhancements to modules,
darn it! ;)
1) The idea of a one-to-one mapping between modules and jars, together with
auto-configuration, is an interesting one, and in certain scenarios could
work very well. However, if we want to allow for this, I would much rather
have the jars not know what their module names are, and have that configured
(or auto-determined) through some other mechanism. This is similar to the
way that a web app doesn't have to know its context path ahead of time.
Taking the web app analogy one step further, one idea might be to take the
jar name as the module name, just as a war file name is used as part of the
context path. So foo.jar would correspond to a module named 'foo', and
default.jar would correspond to the default module (assuming, of course,
that these jars have a struts-config.xml file under META-INF).
2) The one-to-one mapping idea is most useful when modules are considered as
independent entities (as they are intended to be with the current design),
or at least independently configured entities. Once the ideas of shared
configuration or inter-module dependencies are introduced, it starts to lose
some (but not all) of its appeal. For example, if multiple modules wanted to
share some message bundles to avoid loading multiple copies of them, that
configuration would have to live somewhere outside of the module jars. As
another example, in a hierarchical module scenario, there would need to be a
way to specify inter-module dependencies.
3) Mixing auto-configuration with explicit configuration seems like a really
bad idea, and a recipe for trouble, to me. Imagine trying to debug an
application in which you have some explicitly defined struts-config.xml
files as well as some jar files which might, or might not, include their own
configuration. This might not be so bad if you know, or have control over,
the entire application, but consider the case in which modules are being
used to allow multiple independent teams to work on a single web application
(which, not incidentally, was one of the major original justifications for
introducing modules the way they are today).
4) As I've mentioned before (in this same thread, I think), I believe we
need to factor out the configuration code and make it pluggable. Going
forward, the Struts Core should rely on certain configuration objects being
defined, without caring about how they got there. The default config reader,
obviously, would do what we do today, but we should make it easy to provide
an alternate config reader that might do its thing in an entirely different
manner. (I'm sure the IoC fans out there will have something to say on this
topic. ;)
Well, that got a *lot* longer than I originally intended. Sorry, folks. Not
sure if that's ultimately good or bad...
--
Martin Cooper
> > Nico.
>
> Craig
>
> >
> >
> > nicolas De Loof a écrit :
> >
> >> This means that included module jar must be built with knowledge of
> >> the module on witch it will be associated. Not a big issue, as
> >> loading from jars should be great for big apps.
> >>
> >> Nico.
> >>
> >> Filippo Munafò a écrit :
> >>
> >>> Yes, the patch has trasparently extended also non default module
> >>> config.
> >>>
> >>> ActionServlet.init() (unmodified) call initModuleConfig first for
> >>> default module
> >>> and then for each module config found in controller init parameters.
> >>>
> >>> So you can do something like this:
> >>>
> >>> <init-param>
> >>> <param-name>config</param-name>
> >>>
> >>>
> <param-value>/WEB-INF/struts-config.xml,META-INF/struts-config.xml
> </param-value>
> >>>
> >>> </init-param>
> >>> <init-param>
> >>> <param-name>config/module1</param-name>
> >>>
> >>>
> <param-value>/WEB-INF/module1/struts-config.xml,META-INF/module1/s
> truts-config.xml</param-value>
> >>>
> >>> </init-param>
> >>>
> >>> Or, for example, you can put module1 struts-config only in jar and
> >>> the default only in WEB-INF:
> >>>
> >>> <init-param>
> >>> <param-name>config</param-name>
> >>> <param-value>/WEB-INF/struts-config.xml</param-value>
> >>> </init-param>
> >>> <init-param>
> >>> <param-name>config/module1</param-name>
> >>> <param-value>META-INF/module1/struts-config.xml</param-value>
> >>> </init-param>
> >>>
> >>>
> >>> Filippo
> >>>
> >>> -----Original Message-----
> >>> From: nicolas De Loof [mailto:nicolas.deloof@cgey.com] Sent:
> >>> Wednesday, March 31, 2004 10:27
> >>> To: Struts Developers List
> >>> Subject: Re: Splitting struts-config into multiple jar and read them
> >>> as reso urce stream
> >>>
> >>> As far as I understand your patch, config included in jars is added
> >>> to default module config.
> >>> Is they're any way to associate a jar (including config) to a struts
> >>> module ?
> >>>
> >>> Nico.
> >>>
> >>> Filippo Munafò a écrit :
> >>>
> >>>
> >>>
> >>>> Following your suggestion, I've just submitted a patch as
> >>>> bugzilla Enhancement (#28051).
> >>>>
> >>>> I've tried to make as few changes as possible to the source of
> >>>> action servlet in order to avoid any regression.
> >>>>
> >>>> Is it ok?
> >>>>
> >>>> Filippo
> >>>>
> >>>> -----Original Message-----
> >>>> From: Craig R. McClanahan [mailto:craigmcc@apache.org] Sent:
> >>>> Tuesday, March 23, 2004 18:38
> >>>> To: Struts Developers List
> >>>> Subject: Re: Splitting struts-config into multiple jar and read
> >>>> them as resource stream
> >>>>
> >>>> Quoting Ted Husted <hu...@apache.org>:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Perfect! What you did in JSF is exatcly what we need:
> >>>>>>
> >>>>>> "the controller servlet automatically recognize 'META-INF/struts-
> >>>>>> config.xml' resources in any JAR files that were included in the
> >>>>>> application."
> >>>>>>
> >>>>>> When in struts?
> >>>>>>
> >>>>>> Can I help?
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I think we do the same sort of thing in Commons Chain, n'est pas?
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> This particular functionality was in relationship to automatically
> >>>> finding and
> >>>> loading struts-config.xml files (contributed by JAR files dropped
> >>>> in to the
> >>>> WAR) without having to explicitly note them in context init
> >>>> parameters. It
> >>>> doesn't really relate to per-request processing.
> >>>>
> >>>> I can't do this today, but anyone who wants to help on this need
> >>>> only submit an
> >>>> enhancement request (with a patch) to ActionServlet.init()
> to scan the
> >>>> configuration resources in addition to what it already does. The
> >>>> secret sauce
> >>>> is to use ClassLoader.findResources() to get the list of URLs to be
> >>>> processed.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -Ted.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> Craig
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: struts-dev-help@jakarta.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
>
>
>
> ---------------------------------------------------------------------
> 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: Splitting struts-config into multiple jar and read them as reso
urce stream
Posted by Craig McClanahan <cr...@apache.org>.
nicolas De Loof wrote:
> Just a detail I just think about :
> Using this patch, web can develop a Struts module as a subproject and
> include it in WAR as a jar, but what's about tiles-def.xml and
> validation.xml ?
>
I agree with your thinking ... if we concieve that a module should be
"self configured" simply by having its JAR file included in the webapp,
then we need to cover these bases as well.
> This plugins should get a similar enhancement to be able to build
> jar-modules with Struts "commonly used" plugins.
And should be able to adapt to whatever multi-module design emerges as well.
> Nico.
Craig
>
>
> nicolas De Loof a écrit :
>
>> This means that included module jar must be built with knowledge of
>> the module on witch it will be associated. Not a big issue, as
>> loading from jars should be great for big apps.
>>
>> Nico.
>>
>> Filippo Munafò a écrit :
>>
>>> Yes, the patch has trasparently extended also non default module
>>> config.
>>>
>>> ActionServlet.init() (unmodified) call initModuleConfig first for
>>> default module
>>> and then for each module config found in controller init parameters.
>>>
>>> So you can do something like this:
>>>
>>> <init-param>
>>> <param-name>config</param-name>
>>>
>>> <param-value>/WEB-INF/struts-config.xml,META-INF/struts-config.xml</param-value>
>>>
>>> </init-param>
>>> <init-param>
>>> <param-name>config/module1</param-name>
>>>
>>> <param-value>/WEB-INF/module1/struts-config.xml,META-INF/module1/struts-config.xml</param-value>
>>>
>>> </init-param>
>>>
>>> Or, for example, you can put module1 struts-config only in jar and
>>> the default only in WEB-INF:
>>>
>>> <init-param>
>>> <param-name>config</param-name>
>>> <param-value>/WEB-INF/struts-config.xml</param-value>
>>> </init-param>
>>> <init-param>
>>> <param-name>config/module1</param-name>
>>> <param-value>META-INF/module1/struts-config.xml</param-value>
>>> </init-param>
>>>
>>>
>>> Filippo
>>>
>>> -----Original Message-----
>>> From: nicolas De Loof [mailto:nicolas.deloof@cgey.com] Sent:
>>> Wednesday, March 31, 2004 10:27
>>> To: Struts Developers List
>>> Subject: Re: Splitting struts-config into multiple jar and read them
>>> as reso urce stream
>>>
>>> As far as I understand your patch, config included in jars is added
>>> to default module config.
>>> Is they're any way to associate a jar (including config) to a struts
>>> module ?
>>>
>>> Nico.
>>>
>>> Filippo Munafò a écrit :
>>>
>>>
>>>
>>>> Following your suggestion, I've just submitted a patch as
>>>> bugzilla Enhancement (#28051).
>>>>
>>>> I've tried to make as few changes as possible to the source of
>>>> action servlet in order to avoid any regression.
>>>>
>>>> Is it ok?
>>>>
>>>> Filippo
>>>>
>>>> -----Original Message-----
>>>> From: Craig R. McClanahan [mailto:craigmcc@apache.org] Sent:
>>>> Tuesday, March 23, 2004 18:38
>>>> To: Struts Developers List
>>>> Subject: Re: Splitting struts-config into multiple jar and read
>>>> them as resource stream
>>>>
>>>> Quoting Ted Husted <hu...@apache.org>:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Perfect! What you did in JSF is exatcly what we need:
>>>>>>
>>>>>> "the controller servlet automatically recognize 'META-INF/struts-
>>>>>> config.xml' resources in any JAR files that were included in the
>>>>>> application."
>>>>>>
>>>>>> When in struts?
>>>>>>
>>>>>> Can I help?
>>>>>>
>>>>>
>>>>>
>>>>> I think we do the same sort of thing in Commons Chain, n'est pas?
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> This particular functionality was in relationship to automatically
>>>> finding and
>>>> loading struts-config.xml files (contributed by JAR files dropped
>>>> in to the
>>>> WAR) without having to explicitly note them in context init
>>>> parameters. It
>>>> doesn't really relate to per-request processing.
>>>>
>>>> I can't do this today, but anyone who wants to help on this need
>>>> only submit an
>>>> enhancement request (with a patch) to ActionServlet.init() to scan the
>>>> configuration resources in addition to what it already does. The
>>>> secret sauce
>>>> is to use ClassLoader.findResources() to get the list of URLs to be
>>>> processed.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Ted.
>>>>>
>>>>>
>>>>
>>>>
>>>> Craig
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: struts-dev-help@jakarta.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org