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.
regards,
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:
http://cwiki.apache.org/confluence/display/S2WIKI/Convention%2CCodebehind+and+REST+2.3
I also opened a ticket for fixing the depenency between
REST->Codebehind, which I don't see why it should exists:
https://issues.apache.org/struts/browse/WW-2667
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
