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? thanks, adam -- _________________________________________________________ Adam Brin Director of Technology, Digital Antiquity 480.965.1278 > On Jun 21, 2017, at 11:34 AM, Ken McWilliams <ken.mcwilli...@gmail.com> 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 <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
