struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken McWilliams <ken.mcwilli...@gmail.com>
Subject Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)
Date Tue, 20 Jun 2017 19:48:48 GMT
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.

-- 
Sent from my C64 using a 300 baud modem

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