Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Ken McWilliams]

Thank you for meditating on this!

On Mon, Jul 10, 2017 at 2:07 AM, Lukasz Lenart 
wrote:

> I thought about this idea and it requires implementation of a root
> Dispatcher with list of child Dispatchers per config file/package/etc.
> Doable but won't happen soon ;-)
>
> 2017-06-23 23:22 GMT+02:00 Ken McWilliams :
> > Yes, something like that.
> >
> > But I think i can be done in a hackish way without much change. Really it
> > is the conventions plugin that is at fault, or rather a lack of
> convention
> > regarding sharing configuration that aught to be standardized.
> >
> > The beans and constants are currently scoped globally, just inside the
> >  the beans in struts2-conventions-plugin
> struts-plugin.xml
> > file can only be set once.
> >
> > Consider the struts2-rest plugin, at a quick glance of the setup
> > documentation it is clear that it wants to impose it's own conventions:
> > https://cwiki.apache.org/confluence/display/WW/REST+Plugin you will see
> a
> > number of blocks such as:
> >
> > 
> > 
> >  > "rest-default"/>
> > 
> >
> > Which are required in the setup. This isn't as simple as it aught to be,
> > there should be a number of packages defined in the rest plugins
> > struts-plugin.xml and by extending that get the most typical
> configurations
> > (obviously every configuration can't be known but a couple choices
> wouldn't
> > be bad). Is it reasonable for people to be intimately familiar with the
> > conventions configuration such that they would know how to configure the
> > rest plugin? As it stands this seems to be the case but in terms of user
> > experience, it's a bit of a pain and if you want both your conventions
> AND
> > the rest plugin, you find yourself being stuck (like an under-inflated
> > balloon animal, you can choose to have the head inflated of the tail, but
> > not both).
> >
> > This is one possible way to solve the issue:
> > - Create a new interceptor called "PackageConfigurationInterceptor";
> since
> > interceptors are instantiated once per package they have the scope that I
> > would expect.
> > - When using conventions scan for the existence of this interceptor, if
> > found use it's beans and constants in place of the global ones.
> >
> > ===
> > package com.kenmcwilliams.struts.config;
> >
> > public class ConventionsPackageConfigInterceptor extends
> > PackageConfigInterceptor {
> >
> > public ConventionsPackageConfigInterceptor() {
> > super();
> > //   > name="convention"
> > class="org.apache.struts2.convention.ConventionUnknownHandler"/>
> > this.beans.add(new
> > StrutsBean("com.opensymphony.xwork2.UnknownHandler", "convention",
> > "org.apache.struts2.convention.ConventionUnknownHandler"));
> >
> > //   > name="convention"
> > class="org.apache.struts2.convention.PackageBasedActionConfigBuilder"/>
> > //   > name="convention"
> > class="org.apache.struts2.convention.SEOActionNameBuilder"/>
> > //   > name="convention"
> > class="org.apache.struts2.convention.DefaultResultMapBuilder"/>
> > //   > name="convention"
> > class="org.apache.struts2.convention.DefaultInterceptorMapBuilder"/>
> > //   > name="convention"
> > class="org.apache.struts2.convention.ConventionsServiceImpl"/>
> > this.beans.add(new
> > StrutsBean("org.apache.struts2.convention.ActionConfigBuilder",
> > "convention",
> > "org.apache.struts2.convention.PackageBasedActionConfigBuilder"));
> > this.beans.add(new
> > StrutsBean("org.apache.struts2.convention.ActionNameBuilder",
> "convention",
> > "org.apache.struts2.convention.SEOActionNameBuilder"));
> > this.beans.add(new
> > StrutsBean("org.apache.struts2.convention.ResultMapBuilder",
> "convention",
> > "org.apache.struts2.convention.DefaultResultMapBuilder"));
> > this.beans.add(new
> > StrutsBean("org.apache.struts2.convention.InterceptorMapBuilder",
> > "convention",
> > "org.apache.struts2.convention.DefaultInterceptorMapBuilder"));
> > this.beans.add(new
> > StrutsBean("org.apache.struts2.convention.ConventionsService",
> > "convention", "org.apache.struts2.convention.ConventionsServiceImpl"));
> > //   > name="convention.packageProvider"
> > class="org.apache.struts2.convention.ClasspathPackageProvider"/>
> > //   > name="convention.containerProvider"
> > class="org.apache.struts2.convention.ClasspathConfigurationProvider"/>
> > //
> > this.beans.add(new
> > StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
> > "convention.packageProvider",
> > "org.apache.struts2.convention.ClasspathPackageProvider"));
> > this.beans.add(new
> > StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
> > "convention.packageProvider",
> > "org.apache.struts2.convention.ClasspathConfigurationProvider"));
> >
> > //   > value="convention"/>
> > //   > value="convention"/>
> > //   value="convention"/>
> > //   > value="convention"/>
> > //   > 

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Lukasz Lenart]

I thought about this idea and it requires implementation of a root
Dispatcher with list of child Dispatchers per config file/package/etc.
Doable but won't happen soon ;-)

2017-06-23 23:22 GMT+02:00 Ken McWilliams :
> Yes, something like that.
>
> But I think i can be done in a hackish way without much change. Really it
> is the conventions plugin that is at fault, or rather a lack of convention
> regarding sharing configuration that aught to be standardized.
>
> The beans and constants are currently scoped globally, just inside the
>  the beans in struts2-conventions-plugin struts-plugin.xml
> file can only be set once.
>
> Consider the struts2-rest plugin, at a quick glance of the setup
> documentation it is clear that it wants to impose it's own conventions:
> https://cwiki.apache.org/confluence/display/WW/REST+Plugin you will see a
> number of blocks such as:
>
> 
> 
>  "rest-default"/>
> 
>
> Which are required in the setup. This isn't as simple as it aught to be,
> there should be a number of packages defined in the rest plugins
> struts-plugin.xml and by extending that get the most typical configurations
> (obviously every configuration can't be known but a couple choices wouldn't
> be bad). Is it reasonable for people to be intimately familiar with the
> conventions configuration such that they would know how to configure the
> rest plugin? As it stands this seems to be the case but in terms of user
> experience, it's a bit of a pain and if you want both your conventions AND
> the rest plugin, you find yourself being stuck (like an under-inflated
> balloon animal, you can choose to have the head inflated of the tail, but
> not both).
>
> This is one possible way to solve the issue:
> - Create a new interceptor called "PackageConfigurationInterceptor"; since
> interceptors are instantiated once per package they have the scope that I
> would expect.
> - When using conventions scan for the existence of this interceptor, if
> found use it's beans and constants in place of the global ones.
>
> ===
> package com.kenmcwilliams.struts.config;
>
> public class ConventionsPackageConfigInterceptor extends
> PackageConfigInterceptor {
>
> public ConventionsPackageConfigInterceptor() {
> super();
> //   name="convention"
> class="org.apache.struts2.convention.ConventionUnknownHandler"/>
> this.beans.add(new
> StrutsBean("com.opensymphony.xwork2.UnknownHandler", "convention",
> "org.apache.struts2.convention.ConventionUnknownHandler"));
>
> //   name="convention"
> class="org.apache.struts2.convention.PackageBasedActionConfigBuilder"/>
> //   name="convention"
> class="org.apache.struts2.convention.SEOActionNameBuilder"/>
> //   name="convention"
> class="org.apache.struts2.convention.DefaultResultMapBuilder"/>
> //   name="convention"
> class="org.apache.struts2.convention.DefaultInterceptorMapBuilder"/>
> //   name="convention"
> class="org.apache.struts2.convention.ConventionsServiceImpl"/>
> this.beans.add(new
> StrutsBean("org.apache.struts2.convention.ActionConfigBuilder",
> "convention",
> "org.apache.struts2.convention.PackageBasedActionConfigBuilder"));
> this.beans.add(new
> StrutsBean("org.apache.struts2.convention.ActionNameBuilder", "convention",
> "org.apache.struts2.convention.SEOActionNameBuilder"));
> this.beans.add(new
> StrutsBean("org.apache.struts2.convention.ResultMapBuilder", "convention",
> "org.apache.struts2.convention.DefaultResultMapBuilder"));
> this.beans.add(new
> StrutsBean("org.apache.struts2.convention.InterceptorMapBuilder",
> "convention",
> "org.apache.struts2.convention.DefaultInterceptorMapBuilder"));
> this.beans.add(new
> StrutsBean("org.apache.struts2.convention.ConventionsService",
> "convention", "org.apache.struts2.convention.ConventionsServiceImpl"));
> //   name="convention.packageProvider"
> class="org.apache.struts2.convention.ClasspathPackageProvider"/>
> //   name="convention.containerProvider"
> class="org.apache.struts2.convention.ClasspathConfigurationProvider"/>
> //
> this.beans.add(new
> StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
> "convention.packageProvider",
> "org.apache.struts2.convention.ClasspathPackageProvider"));
> this.beans.add(new
> StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
> "convention.packageProvider",
> "org.apache.struts2.convention.ClasspathConfigurationProvider"));
>
> //   value="convention"/>
> //   value="convention"/>
> //  
> //   value="convention"/>
> //   value="convention"/>
> this.constants.add(new
> StrutsConstant("struts.convention.actionConfigBuilder", "convention"));
> this.constants.add(new
> StrutsConstant("struts.convention.actionNameBuilder", "convention"));
> this.constants.add(new
> StrutsConstant("struts.convention.resultMapBuilder", "convention"));
> this.constants.add(new
> 

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Ken McWilliams]

Yes, something like that.

But I think i can be done in a hackish way without much change. Really it
is the conventions plugin that is at fault, or rather a lack of convention
regarding sharing configuration that aught to be standardized.

The beans and constants are currently scoped globally, just inside the
 the beans in struts2-conventions-plugin struts-plugin.xml
file can only be set once.

Consider the struts2-rest plugin, at a quick glance of the setup
documentation it is clear that it wants to impose it's own conventions:
https://cwiki.apache.org/confluence/display/WW/REST+Plugin you will see a
number of blocks such as:






Which are required in the setup. This isn't as simple as it aught to be,
there should be a number of packages defined in the rest plugins
struts-plugin.xml and by extending that get the most typical configurations
(obviously every configuration can't be known but a couple choices wouldn't
be bad). Is it reasonable for people to be intimately familiar with the
conventions configuration such that they would know how to configure the
rest plugin? As it stands this seems to be the case but in terms of user
experience, it's a bit of a pain and if you want both your conventions AND
the rest plugin, you find yourself being stuck (like an under-inflated
balloon animal, you can choose to have the head inflated of the tail, but
not both).

This is one possible way to solve the issue:
- Create a new interceptor called "PackageConfigurationInterceptor"; since
interceptors are instantiated once per package they have the scope that I
would expect.
- When using conventions scan for the existence of this interceptor, if
found use it's beans and constants in place of the global ones.

===
package com.kenmcwilliams.struts.config;

public class ConventionsPackageConfigInterceptor extends
PackageConfigInterceptor {

public ConventionsPackageConfigInterceptor() {
super();
//  
this.beans.add(new
StrutsBean("com.opensymphony.xwork2.UnknownHandler", "convention",
"org.apache.struts2.convention.ConventionUnknownHandler"));

//  
//  
//  
//  
//  
this.beans.add(new
StrutsBean("org.apache.struts2.convention.ActionConfigBuilder",
"convention",
"org.apache.struts2.convention.PackageBasedActionConfigBuilder"));
this.beans.add(new
StrutsBean("org.apache.struts2.convention.ActionNameBuilder", "convention",
"org.apache.struts2.convention.SEOActionNameBuilder"));
this.beans.add(new
StrutsBean("org.apache.struts2.convention.ResultMapBuilder", "convention",
"org.apache.struts2.convention.DefaultResultMapBuilder"));
this.beans.add(new
StrutsBean("org.apache.struts2.convention.InterceptorMapBuilder",
"convention",
"org.apache.struts2.convention.DefaultInterceptorMapBuilder"));
this.beans.add(new
StrutsBean("org.apache.struts2.convention.ConventionsService",
"convention", "org.apache.struts2.convention.ConventionsServiceImpl"));
//  
//  
//
this.beans.add(new
StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
"convention.packageProvider",
"org.apache.struts2.convention.ClasspathPackageProvider"));
this.beans.add(new
StrutsBean("com.opensymphony.xwork2.config.PackageProvider",
"convention.packageProvider",
"org.apache.struts2.convention.ClasspathConfigurationProvider"));

//  
//  
//  
//  
//  
this.constants.add(new
StrutsConstant("struts.convention.actionConfigBuilder", "convention"));
this.constants.add(new
StrutsConstant("struts.convention.actionNameBuilder", "convention"));
this.constants.add(new
StrutsConstant("struts.convention.resultMapBuilder", "convention"));
this.constants.add(new
StrutsConstant("struts.convention.interceptorMapBuilder", "convention"));
this.constants.add(new
StrutsConstant("struts.convention.conventionsService", "convention"));
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  
//  

this.constants.add(new
StrutsConstant("struts.convention.result.path", "/WEB-INF/content/"));
this.constants.add(new
StrutsConstant("struts.convention.result.flatLayout", "true"));
this.constants.add(new
StrutsConstant("struts.convention.action.suffix", "Action"));
this.constants.add(new
StrutsConstant("struts.convention.action.disableScanning", "false"));
this.constants.add(new
StrutsConstant("struts.convention.action.mapAllMatches", "false"));
this.constants.add(new
StrutsConstant("struts.convention.action.checkImplementsAction", "true"));
this.constants.add(new
StrutsConstant("struts.convention.default.parent.package",
"convention-default"));
this.constants.add(new
StrutsConstant("struts.convention.action.name.lowercase", "true"));
this.constants.add(new
StrutsConstant("struts.convention.action.name.separator", "-"));
this.constants.add(new
StrutsConstant("struts.convention.package.locators",

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Lukasz Lenart]

2017-06-22 2:45 GMT+02:00 Ken McWilliams :
> 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).

Did I get this right, you want to have multiple configuration in the
same app, like having multiple struts.xml files in one app, right?
Hmm... maybe it is doable ... per a root package 


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

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Ken McWilliams]

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 
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 
> 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 http://www.lenart.org.pl/
> >>
> >> -
> >> To unsubscribe, e-mail: 

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Adam Brin]

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  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 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

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Ken McWilliams]

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 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

Re: Limitations using Struts2-conventions-plugin (lack of multiple configuration roots)

[Lukasz Lenart]

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 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org