struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken McWilliams <>
Subject Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)
Date Wed, 21 Jun 2017 18:34:47 GMT
Sure, it would be most ideal if there could be variables scoped to struts
action packages, and accessible from only within that package.

Step 1 (Create beans and constants scoped to the package level):
Simply creating an interceptor to hold all the configuration that is
currently found in struts-plugin.xml would be a lazy start, interceptors
are instantiated once per package so they meet the scope requirement well.
Perhaps creating extending

Step 2: (Create configuration based on the per-instance package state.)
I'm not sure how that would work out... The actions convention wiring
configuration would be run, once for each package that has this magical
conventions-config-interceptor in its stack. Probably creating a new
conventions plugin as proof of concept. I tried creation a configuration
provider a while back and got slowed down to the point of giving up.

End Objective:
To encapsulate conventions such that multiple types of conventions could
operate simultaneously starting at different roots. As an example, the rest
plugin depends on the conventions plugin however it changes the global
configuration in such a way that normal conventions no longer work. In this
way contributors could develop conventions based code which would be
readily mergeable with anyone else's (plugins which use conventions but
have no side effects).

On Wed, Jun 21, 2017 at 12:39 AM, Lukasz Lenart <>

> 2017-06-20 21:48 GMT+02:00 Ken McWilliams <>:
> > I like to use the conventions plugin but find myself fighting with it
> more
> > often than not.
> >
> > I think conventions should establish a "convention". Now the plugin
> > certainly does this in the *singular* but say I want restful services
> > handled by conventions, and then I want perhaps a set of packages to
> > contain public documents, and another set of packages to require some
> form
> > of security but also follow some sort of conventions... well I find it
> > impossible to use the conventions plugin and need to resort to additional
> > configuration. Creating packages in struts.xml, or using XML to override
> > the conventions.
> >
> > Do you think it would be reasonable to have the conventions plugin,
> create
> > a new configuration interceptor for which all the constants (package
> level
> > constants, as there is one interceptor instance per stack), and the rest
> of
> > the conventions configuration could be looked up from each of these
> > configurations?
> >
> > So the conventions plugin would need to check each struts package to see
> if
> > extends conventions-default and if so, wire the actions at startup for
> each
> > in turn. If that is too limiting perhaps just make this one interceptor a
> > requirement for the scan.
> >
> > Also under this scheme, it would be good to create an "include" for the
> > Java package scan rather than the "exclude" which is more suited to one
> > root.
> >
> > I think this scheme would greatly reduce annotation usage as it would be
> > possible to stay entirely within established conventions, rendering
> > overrides unnecessary.
> This sounds interesting but I'm not really grasp all the details.
> Maybe we can start with a one thing and then implement another. Can
> you split your idea into single steps?
> Regards
> --
> Ɓukasz
> + 48 606 323 122
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sent from my C64 using a 300 baud modem

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message