struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Brin <>
Subject Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)
Date Wed, 21 Jun 2017 19:56:03 GMT
Hi Ken,
  I think I’m with Lukasz, I wonder if the following might be useful for folks to get onto
the same page (just from my own head):

• a sample project that shows the trade-offs?
• a diagram or visualization that shows how the new model might lay out?



Adam Brin
Director of Technology, Digital Antiquity

> On Jun 21, 2017, at 11:34 AM, Ken McWilliams <> wrote:
> 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 <>
> wrote:
>> 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