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 <lukaszlen...@apache.org> wrote: > 2017-06-20 21:48 GMT+02:00 Ken McWilliams <ken.mcwilli...@gmail.com>: > > 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 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > -- Sent from my C64 using a 300 baud modem
