struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeromy Evans <>
Subject Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
Date Fri, 06 Jun 2008 14:24:16 GMT
Hi Musachy,

Just letting you know I just moved a large rest-plugin app from an old 
2.1.3-snapshot to the current head to try things out...and it still 
works :-)

Here's what I had to do: 
  - added codebehind as a direct dependency for the application (for 
now) as it was removed as a dependency from rest-plugin
  - removed direct use of 
struts.configuration.classpath.disableActionScanning=true, which still 
has an effect.

I'll move this app over to a Rest+Convention later.

I don't share the view that plugins must not have dependencies on other 
plugins.  I have plugins that provide Controllers so a run-time 
dependency on the rest plugin is mandatory as the rest plugin provides 
fundamental behaviour. Some of those Controllers use @Result annotations 
so an explicit dependency on CodeBehind (or Convention later) also now 
exists. It doesn't sit comfortably with me that the pom has to reference 
both dependencies explicitly when the actual requirement is for the 
rest-plugin and its transitive dependencies (such as struts-core and 
codebehind/convention).  I also am certain I will need to publish S2 
plugins that depend on these plugins (and others) later.

 Jeromy Evans

PS. rest howcase on trunk can't build as it uses @Results and now needs 
an explicit dependency on CodeBehind/Convention added to its pom.

Musachy Barroso wrote:
> I created a proposal page on the wiki for this:
> I also opened a ticket for fixing the depenency between
> REST->Codebehind, which I don't see why it should exists:
> After taking care of that issue, and if we get to agree on the new
> "unknown-handler-stack" (nobody has said anything pro/against yet), we
> are done with the blocking concerns. (I think)
> musachy
> On Wed, Jun 4, 2008 at 9:25 AM, Musachy Barroso <> wrote:
>> Here is yet another idea, this one assumes that multiple
>> UnknowHandler(s) can be stacked (which I am prototyping). If we modify
>> ControllerClasspathPackageProvider, so it delegates to an instance of
>> ClasspathPackageProvider instead of extending it, and using reflection
>> for the delegation of those few methods, we could have a nice setup:
>> 1. Applications using Codebehind
>> No changes to Codebehind were done, they will continue to work
>> 2.Applications using Codebehind + REST
>> REST ControllerClasspathPackageProvider will find Codebehind's
>> ClasspathPackageProvider in the classpath, and delegate to it using
>> reflection. These applications will continue to work without any
>> modification.
>> 3. Applications using REST + Convention
>> REST ControllerClasspathPackageProvider won't find Codebehind's
>> ClasspathPackageProvider in the classpath so it won't do anything.
>> REST will work on top of Convention (this works fine).
>> Plugins will be standalone, like they are now, and backward
>> compatibility will be kept. As a side effect, REST could be used with
>> XML configuration without Codebehind being in the classpath. I know
>> reflection is not a very elegant solution, but it would be temporary
>> until Codebehind is phased out, a few versions later.
>> musachy
> ------------------------------------------------------------------------
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 8.0.100 / Virus Database: 269.24.6/1481 - Release Date: 3/06/2008 7:31 PM

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message