struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary D Ashley Jr." <>
Subject RE: Compartmentalization of Modules (was Re: [18111] et al)
Date Thu, 22 Jan 2004 07:00:55 GMT
I've found that using a cross module html:link tag very useful.

	- We are using web.xml security restrictions on a module by
module basis (centrally managed security).  For us this was mainly used
as a stop gap security measure to ensure that a poorly configured role
in a single action mapping, didn't break our security model.
	- The main benefit was enhancing the html link tag to determine
if a user was "inRole" and effectively hiding links from unauthorized
users.  This effectively expanded/collapsed our navigation menus based
on the users access level to the system.  It is hoped that this would
avoid many frivolous emails/calls to help desk support about why a user
might be getting a 503 error.  While the logic:present tag is a useful
alternative, it would have caused jsp code bloat, and managing security
access in both jsps and struts config files.  (The same with the switch

		i.e.:  <html:link action="" module="" ...

It seemed that if you have action="" attribute, then module="" was the
next logical step with making struts modular.  For us, it certainly
helped provide the glue in a very large data centric struts application.
Large obviously relative to my situation, so more specifically: 20
modules, 10 state/local government agencies, 30 roles, 10,000 users (250
core 9am-5pm users), and 6 developers.

It seems modular link and rewrite tags are a nice step in the right
direction.  Well, just one perspective to consider.



-----Original Message-----
From: Robert Leland [] 
Sent: Tuesday, January 20, 2004 10:01 PM
To: Struts Developers List
Subject: Re: Compartmentalization of Modules (was Re: [18111] et al)

Ted Husted wrote:

>Like James, I've been counseling teams to go multiple struts-configs
rather than modules, because of the issues with cross-linking and
sharing resources between modules. 
>If we go ahead with the patch to html:link, to match the other changes
we made this week, then I wouldn't have to steer people away from
>As it stands, I believe the most common use case is that large teams
want to use modules as part of a divide-and-conquer strategy. 
>I'd suggest that we go ahead an apply these remaining patches, so that
we support sharing of resources and linking between the named modules
and the default module. 
>If someone comes up with a patch to make the contextRelative tag
attribute configurable or immutable, then we can apply that too. 
>My one concern is that "contextRelative" is a verbose attribute name
and potentially confusing. From one perspective, the module is the
current "context" :). It really means to say applicationContextRelative,
but that's impossibly long for an attribute name.
We went the 'application' naming route before, why not just stick with a

single term module,
and call it moduleRelative ? Which is what is is, 'relative to the 
current module.

>While I'm at it, how about if we turn the attribute around and
deprecate "contextRelative=true" in favor of "modular=false"?
>So we'd have things tags <html:img page="/assets/logo.gif"
modular="false"  /> instead of   <html:img page="/assets/logo.gif"
contextRelative="true"  /> 
>As mentioned, once we mop this up, I believe we can roll 1.2.0. :)
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message