Sure, doing Struts2/Shiro integration at the moment. Will come back to this, it was a rant from running into issues when setting up some personal demo projects. The limitation from one static configuration to cover all conventions (which really just lets you use one convention, at least well). And issues in certain configuration being picked up from the xml, views and annotations(class and package level). Namely when actions are created by only creating views, I didn't think I couldn't apply package level annotations and have them configure the actions unless a class is also created.
So yes I'll come back to this in a bit. On Wed, Jun 21, 2017 at 1:56 PM, Adam Brin <ab...@digitalantiquity.org> wrote: > 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 > > -- Sent from my C64 using a 300 baud modem
