struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: Non-peer sub-apps (was RE: Local/Global Exception Handling: H ow d o you specify ContextRe lati ve path(action's input) in the Sub-App s ' str uts-config.xml)
Date Wed, 14 Aug 2002 22:55:06 GMT


> -----Original Message-----
> From: Trieu, Danny [mailto:DTrieu@downeysavings.com]
> Sent: Wednesday, August 14, 2002 2:55 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Non-peer sub-apps (was RE: Local/Global 
> Exception Handling:
> H ow d o you specify ContextRe lati ve path(action's input) in the
> Sub-Apps ' str uts-config.xml)
> 
> 
> Martin,
> 
> Thanks for sharing!  What you were doing can be a solution 
> that works with
> sub-module too.  Craig,
> Replied earlier, and agree to introduce the contextRelative 
> attribute for
> the <exception .... />.  Which is alright with me.  What I want is
> consitency, and what Craig provided was to stay consistence with the
> <forward .... /> that already have the contextRelative attribute.
> 
> What you were doing is great too, and so can we both?  
> Meaning, there can be
> an init param that allow
> The app toggle back and forth between Hierarchical Modules(Non-peer
> sub-apps???) and the way the current sub-module was designed 
> for.  I don't
> know, I might be asking too much out of the framework, but 
> consitency and
> flexibility is what I am looking forward.  
> 
> To be hornest, I like the way you described better.  Since, 
> reusable View
> Compenents is often needed more then re-usable Sub-Module.  
> From what I see
> and experienced, Sub-Module is nice to organize/simplify the 
> app structure.
> Where as re-usable view component are more benefitial to the entire
> application.  May be we haven't fully understand everyone needs for
> modulization of web-app.  I hope Craig, Ted, Cedric, and you 
> will address
> this in your book on Struts, and provide a, or an 
> alternative, solution to
> the problem.

I don't think either design is really better than the other. The two designs
have different goals, and they each meet their goals rather well, I believe.

You're absolutely right that we don't really know yet how people are going
to use Struts modules. That's one reason that I have not tried to work my
design into the Struts code base alongside the current design. (Another
reason is that my employer owns the code for what I described. :) Craig's
initial design was, I believe, intended to be a first step, the goal being
to see how people would use it, before developing it further.

It's very important that we hear from people like yourself who have
particular use cases in mind. Once we've collected some feedback, we can put
it all into a big pot, stir, and see what we come up with. ;-)

--
Martin Cooper


> 
> Thanks you all for your great work and support!!!
> 
> Danny.
> 
> FYI.  We're currently using Struts1.1( with Sub-Module ) for a big
> accounting project.  The size of the team is about 20 
> developers.  And every
> since I troduced Sub-Module feature, it seem to introduce
> More problems and harder to maintain.  Redundunt codes 
> scarther in every
> Sub-Module, customizing Struts' code is the solution whenever 
> we're running
> into a problem.  I guess this is normal to software when it is in its
> earliest state.  I am only trying to share my experience, so 
> we all can
> learn from each other.
> 
> -----Original Message-----
> From: Martin Cooper [mailto:martin.cooper@tumbleweed.com] 
> Sent: Wednesday, August 14, 2002 1:52 PM
> To: 'Struts Users Mailing List'
> Subject: Non-peer sub-apps (was RE: Local/Global Exception 
> Handling: How d o
> you specify ContextRe lati ve path(action's input) in the 
> Sub-Apps' str
> uts-config.xml)
> 
> 
> I understand what you are trying to do, because I've done it 
> myself. It
> really isn't the way modules (sub-apps) were designed to be 
> used, and I
> extended several aspects of Struts to get it to work. Let me 
> describe my app
> a bit, and how I extended Struts to do what I needed to do.
> 
> Rather than being built as a set of independent peer modules, 
> as Struts
> modules are intended to be used, my app is based on a 
> hierarchy of modules.
> At the root is a framework which glues the hierarchy together 
> and provides
> common services and resources to other modules. The root 
> module is also the
> Struts default module. All of the other modules in the app 
> are dependent
> (possibly indirectly) on this root module. I'll skip the 
> details of multiple
> levels of hierarchy, because it gets complicated quickly, and 
> I don't think
> it's relevant for what you are looking for.
> 
> The hierarchy is built up at startup time, because modules 
> can be added to,
> or removed from, the app after the initial installation 
> process. To do this,
> I override init(), because I don't store the locations of my
> struts-config.xml files in web.xml. (That's a whole other 
> story.) Further
> initialisation is done using a Struts PlugIn. The PlugIn 
> knows about the
> hierarchy, and knows about the organisation of modules into module
> directories. It can therefore locate configuration files and 
> digest them in
> an order appropriate for the hierarchy (i.e. allowing child modules to
> override properties set by their parents).
> 
> To allow modules to forward control to their parents, I wrote 
> my own version
> of ActionMapping, so that I could override findForward(). My 
> version of
> findForward() looks through local forwards first, and then 
> the module's
> global forwards. That's just what Struts does. However, if it 
> doesn't find
> the forward it's looking for in either of those places, it 
> will then walk up
> the hierarchy, looking through the global forwards of parent 
> modules, until
> it gets to the root module. If it still doesn't find a 
> matching forward,
> well, you're out of luck.
> 
> I do something similar for locating message resources, except 
> that I didn't
> have to override Struts for that. I simply have a 
> MessageLocator class which
> knows how to find messages based on the hierarchy and some additional
> conditions that may be supplied. In order for this to work on 
> my JSP pages,
> I did have to write my own version of <bean:message> to use 
> this scheme,
> though.
> 
> Currently, I have 5 modules, with at least 2 more to go, and 
> it all works
> nicely.
> 
> In any case, I've rambled long enough. I hope this helps, and 
> gives you some
> ideas as to how you might address your own issues.
> 
> --
> Martin Cooper
> 
> 
> > -----Original Message-----
> > From: Trieu, Danny [mailto:DTrieu@downeysavings.com]
> > Sent: Wednesday, August 14, 2002 9:35 AM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Local/Global Exception Handling: How do you specify 
> > ContextRe lati ve path(action's input) in the Sub-Apps' 
> > struts-config.xml
> > 
> > 
> > Craig,
> > 
> > Thanks for your help.  It has been valuable.  Craig,
> > Sub-Module are very
> > useful.  However, it seems to
> > Only allow you to modulize the controller components and 
> not the View
> > components.  Let says we are using tiles, or some others 
> > technique, for our
> > View Composition Strategy (VCS).  VCS and Sub-Module doesn't 
> > works right out
> > of the box.  Under VCS, resource available in one common 
> > source.  Where as,
> > with Sub-Module, resource available in differen logic source 
> > depend on which
> > logical sub-module a request belong to.  This introduce 
> > problem when control
> > is hand over to the VCS, where its assumsion of resouce(e.g. links,
> > images...) that comes from a comon place is now impratical.  
> > 
> > Sure, we can overcome this with some modification like modify the 
> > <html:link/> tag to have attribute that can render its links to be 
> > context relative.  Or in the config.xml of the current 
> sub-module, we
> > can set global
> > <forward....contextRelative="true"> and have all the view's 
> > link tag to used
> > this.  But this can be a problem when diff sub-module use 
> > common view will
> > have to copy the <forward...> declaration every sub-module 
> > config.xml file.
> > 
> > If we already allow <forward ... > to be context relative.
> > Why not allow
> > <exception  path=".." contextRelative="true" ...> to be 
> > context relative as
> > well?  And also, can all of the common declaration be declare 
> > in the the
> > default sub-model, and lookup will start at the current 
> sub-module and
> > traverse upward to the default sub-module?
> > 
> > I might not have a good understanding of the current design
> > of sub-module,
> > so please explain so we all can learn.
> > 
> > Thanks Craig,
> > 
> > danny
> > 
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Tuesday, August 13, 2002 5:21 PM
> > To: Struts Users Mailing List
> > Subject: RE: Local/Global Exception Handling: How do you 
> > specify ContextRe
> > lati ve path(action's input) in the Sub-Apps' struts-config.xml
> > 
> > 
> > 
> > 
> > On Tue, 13 Aug 2002, Trieu, Danny wrote:
> > 
> > > Date: Tue, 13 Aug 2002 16:31:27 -0700
> > > From: "Trieu, Danny" <DTrieu@downeysavings.com>
> > > Reply-To: Struts Users Mailing List 
> <struts-user@jakarta.apache.org>
> > > To: 'Struts Users Mailing List' <struts-user@jakarta.apache.org>
> > > Subject: RE: Local/Global Exception Handling: How do you specify
> > >     ContextRe lati ve path(action's input) in the Sub-Apps'
> > > struts-config.xml
> > >
> > > Can you give me an example of how path one <exception/> can
> > be set to
> > > a module-relative resource? This can be a JSP, Tiles'
> > definition, or
> > > an Action relative to the module's config file right?
> > >
> > 
> > The path on an exception is defined as a "module-relative 
> URI to the 
> > resource that will complete the request/response if an exception 
> > occurs". In other words, Struts will tack create the complete URI by
> > tacking the module
> > prefix on the front (that's what would *not* happen if a
> > contextRelative="true" attribute were added).
> > 
> > So, if you had a JSP page at the module-relative path
> > "/showException.jsp"
> > that you wanted you use, you'd just say:
> > 
> >   <exception ... path="/showException.jsp" ... />
> > 
> > You'll have to ask Cedric about whether Tiles treats this
> > kind of a path the
> > same as the path on a <forward> so that you can reference a 
> > Tile.  I don't
> > know the answer to that one.
> > 
> > > Thanks,
> > >
> > > danny
> > 
> > Craig
> > 
> > 
> > >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > Sent: Tuesday, August 13, 2002 4:13 PM
> > > To: Struts Users Mailing List
> > > Subject: Re: Local/Global Exception Handling: How do you specify
> > > ContextRelati ve path(action's input) in the Sub-Apps' 
> > > struts-config.xml
> > >
> > >
> > >
> > >
> > > On Tue, 13 Aug 2002, Trieu, Danny wrote:
> > >
> > > > Date: Tue, 13 Aug 2002 14:43:48 -0700
> > > > From: "Trieu, Danny" <DTrieu@downeysavings.com>
> > > > Reply-To: Struts Users Mailing List
> > <struts-user@jakarta.apache.org>
> > > > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > > Subject: Local/Global Exception Handling: How do you specify
> > > >     ContextRelati ve path(action's input) in the Sub-Apps'
> > > > struts-config.xml
> > > >
> > > > Craig,
> > > >
> > > > Do you know how this can be done?
> > > >
> > > > Thanks,
> > > >
> > >
> > > Currently, paths on <exception> declarations are all
> > considered to be
> > > module-relative.  Doing this would require the addition of a
> > > "contextRelative" attribute on the <exception> element, 
> and making 
> > > sure that the code in ExceptionHandler respected it.  Filing an 
> > > enhancement request in the bug tracking system would be 
> appropriate:
> > >
> > >   http://nagoya.apache.org/bugzilla/
> > >
> > > if it's not there already.
> > >
> > > Personally, I have a concern about implementing this.  One
> > of the nice
> > > things about application modules today is that they are 
> pretty much
> > > self contained and independent of each other.  Starting to 
> > depend on
> > > external things like common exception handlers increases
> > the fragility
> > > and complexity of installing a module -- no longer can you
> > just "add a
> > > new struts-config.xml file and restart the webapp.  You've
> > got to make
> > > sure that all the shared dependencies are satisfied.
> > >
> > > Of course, the same philosophy was behind the idea that WAR files
> > > *should* be indepdendent and self contained, but no, 
> everyone wants 
> > > shared JAR files in Tomcat's common/lib directory (or the 
> > equivalent
> > > on other
> > > servers) ...
> > >
> > > > Danny
> > > >
> > > >
> > >
> > > Craig
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: 
> > > <mailto:struts-user-help@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <mailto:struts-user-help@jakarta.apache.org>
> > >
> > >
> > 
> > 
> > --
> > To unsubscribe, e-mail: 
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-user-help@jakarta.apache.org>
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message