struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trieu, Danny" <DTr...@downeysavings.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-Apps ' str uts-config.xml)
Date Wed, 14 Aug 2002 21:54:37 GMT
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.

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>


Mime
View raw message