[Struts-Dev] Multi-App support and using actions across applications

["Laine Donlan (DEV)" <la...@hotmail.com>]

This may be a feature of the multi-application support, but I wanted to make
sure.  And if it was I wanted to get a little more info on the reasoning for
it.  Basically I have a main config and a sub config.  An action is
processed using an action configured by the main application.  The result of
that request is a JSP with an <html:form> on it.

Due to the constraints on action attribute of the form, the action can only
be an Action configured in the main configuration.  I think there is a lot
of potential in having sub application (as well as the main) share
configurations - actions, forms, etc.  Or at least reduce the constraints on
the action so that a user of Struts can integrate applications with out
modifying code.

Any thoughts?

Laine

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

[Andrew Myers <Ab...@netscape.net>]

craigmcc@apache.org wrote:

>In the mean time, my design goal was to make it possible to load multiple
>independent Struts applications into a single webapp, for the following
>purposes:
>
>* An individual Struts app should be able to be packaged in a WAR
>  by itself, or in combination with other Struts apps, with *no*
>  changes to the code, pages, resources, or the struts-config.xml
>  file.
>
A nice goal but not quite my experience yet.  I'm experimenting with 
sub-apps using recent nightly builds and have found that if you have a 
sub-app called "foo" it seems to look for the JSPs under a directory 
called "foo" when you call findForward from your action class.  However 
if you forward to a jsp which uses the struts template library the 
template:put tag stills looks for the file relative to the application 
root folder (not the subapp's root folder).   Am I doing something wrong 
or is this a problem?

Andrew.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

["Craig R. McClanahan" <cr...@apache.org>]

On Sat, 2 Mar 2002, Martin Cooper wrote:

> Date: Sat, 2 Mar 2002 15:47:47 -0800
> From: Martin Cooper <ma...@tumbleweed.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>,
>      struts-dev@japache.org
> Subject: Re: [Struts-Dev] Multi-App support and using actions across
>     applications
>
> Yes, I expect that the multiple module support will remain essentially as is
> for Struts 1.1. (Unless Craig has any more nice surprises for us, that is!)
> This would be the first step in the scenario I described. Essentially, this
> provides the support many people have requested for hosting multiple Struts
> applications within a single web app.
>

This is my current thinking ... multiple application support has been
highly requested, and I think it's going to take a while to consider how
to do hierarchical things correctly, or even if we want it at all (yes,
Martin, I know you do :-).

In the mean time, my design goal was to make it possible to load multiple
independent Struts applications into a single webapp, for the following
purposes:

* An individual Struts app should be able to be packaged in a WAR
  by itself, or in combination with other Struts apps, with *no*
  changes to the code, pages, resources, or the struts-config.xml
  file.

* There should be no restrictions on using the same name for actions,
  form beans, forwards, and other configurable items across Struts
  apps -- in effect, each app gets its own "namespace".

* The Struts app that is used to handle a particular request is based
  on prefix mapping of the request URI (in a manner similar to the way
  a servlet container uses prefix mapping against the various context
  paths to choose which webapp to execute.

That being said, nothing stops you from sharing Java classes (actions,
form beans, utilities, and so no) between the individual applications that
are included together.  You cannot directly share JSP pages (although it
is easy to set up build processes that make multiple copies from a single
source repository at deployment time, if you need them shared).  The thing
that is definitely not shared in the current design is the configuration
information -- each Struts app has to be configured completely
independently to meet the goals described above.  IMHO, that's a Good
Thing -- sharing increases complexity and fragility of a large scale
application, by re-introducing cross dependencies that multiple app
support is striving to eliminate.

But we'll have to see how that all works out at some future point when a
solid design for hierarchical sharing is proposed.


> As Ted mentioned, we don't really have an official name yet. At some point
> in the discussions, Ted suggested that "modules" might be a good term for
> the sub-apps. Since then, I have adopted that terminology in the big app I
> am developing, so I, for one, would be happy if we selected that terminology
> for Struts itself. ;-) (At one point, we were calling them plug-ins within
> my team at work. I'm glad we didn't stick with that, since Craig has
> recently introduced to Struts a different feature with that name!)
>

In the internal comments, I've been calling these things sub-applications,
which is at least technically accurate, but not very cool sounding.  We've
been laughing off the idea of a Struts-let, but ...

> --
> Martin Cooper
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

[Martin Cooper <ma...@tumbleweed.com>]

Yes, I expect that the multiple module support will remain essentially as is
for Struts 1.1. (Unless Craig has any more nice surprises for us, that is!)
This would be the first step in the scenario I described. Essentially, this
provides the support many people have requested for hosting multiple Struts
applications within a single web app.

As Ted mentioned, we don't really have an official name yet. At some point
in the discussions, Ted suggested that "modules" might be a good term for
the sub-apps. Since then, I have adopted that terminology in the big app I
am developing, so I, for one, would be happy if we selected that terminology
for Struts itself. ;-) (At one point, we were calling them plug-ins within
my team at work. I'm glad we didn't stick with that, since Craig has
recently introduced to Struts a different feature with that name!)

--
Martin Cooper

PS - FYI, the body of your mail messages from your japache.org address
arrive as attachments for me. There seems to be something odd about the
character set they use.


----- Original Message -----
From: <st...@japache.org>
To: <st...@jakarta.apache.org>
Sent: Saturday, March 02, 2002 5:11 AM
Subject: Re: [Struts-Dev] Multi-App support and using actions across
applications


> This message uses a character set that is not supported by the Internet
> Service.  To view the original message content,  open the attached
> message. If the text doesn't display correctly, save the attachment to
> disk, and then open it using a viewer that can display the original
> character set. <<message.txt>>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

[Ted Husted <hu...@apache.org>]

struts-dev@japache.org wrote:
>   The other question is what is the offical name of this new feature? Is it multi-apps, multi-modules, sub-apps? I've seen all of these references, but I want to know the proper way to refer to this in the OReilly book.

I don't believe there is an official name at this point, and probably
won't be until there is more documentation. (Contributions welcome.) In
the end, it probably won't be multi-app, since it makes it sounds like
we're crossing the application barrier, when we are not. But since that
was in the subject line of the original message, it's a natural way for
people to refer to the functionality. Right now, it seems that we're
trying things on for size, and to see what fits.

On the news page, we referred to "multiple application modules". I've
been referring to "multiple configuration" support on the User list
occaisonally. This describes what actually happens - multiple Struts
configurations are loaded within the same application, and most of the
class names refer to "config".  But multiple configuration does not roll
trillingly off the tongue. 


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

[st...@japache.org]

Martin,

  I have two quick questions relating to this. First, do you think that this is the way that multi-modules (sub-apps) will stay for the beta/1.1 release? That is, that a sub-app will be somewhat limited in how it can reference actions in other sub-apps, similar to the problem that Laine mentioned here regarding the FormTag. What I'm wondering is as the beta draws near, what changes are still going to be made to the Tag library to support this new feature. You mentioned a step-wise approach. Is 1.1 the first step? What are developers actually going to be able to use multi-modules for in 1.1. What are going to be the limitations, benefits, etc...

  The other question is what is the offical name of this new feature? Is it multi-apps, multi-modules, sub-apps? I've seen all of these references, but I want to know the proper way to refer to this in the OReilly book.

Thanks,
Chuck Cavaness
--
Posted via jApache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Struts-Dev] Multi-App support and using actions across applications

[Martin Cooper <ma...@tumbleweed.com>]

I think the current state of the multi-module support should be viewed as a
first step towards a greater goal. This first step enables multiple modules
which are essentially independent of each other. In my mind, the next step
would be peer-to-peer integration, such that, for example, one module could
reference the global forwards of another module. The step after that might
be to allow for a hierarchical inter-relationship between modules, where
forwards might be looked up across multiple modules according to a defined
hierarchy.

That said, I should make a confession. I have an immediate need (in my "day
job") to develop a multi-module application based on a hierarchical model.
Much of the framework is already in place, but it's not sufficiently general
at this point to contribute back to Struts. Hopefully, I'll be able to do
that at some point.

--
Martin Cooper


----- Original Message -----
From: "Laine Donlan (DEV)" <la...@hotmail.com>
To: <st...@jakarta.apache.org>
Sent: Friday, March 01, 2002 8:50 AM
Subject: [Struts-Dev] Multi-App support and using actions across
applications


> This may be a feature of the multi-application support, but I wanted to
make
> sure.  And if it was I wanted to get a little more info on the reasoning
for
> it.  Basically I have a main config and a sub config.  An action is
> processed using an action configured by the main application.  The result
of
> that request is a JSP with an <html:form> on it.
>
> Due to the constraints on action attribute of the form, the action can
only
> be an Action configured in the main configuration.  I think there is a lot
> of potential in having sub application (as well as the main) share
> configurations - actions, forms, etc.  Or at least reduce the constraints
on
> the action so that a user of Struts can integrate applications with out
> modifying code.
>
> Any thoughts?
>
> Laine
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>