On Dec 5, 2007 4:11 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Ok, you offered help, now you're in for it :)
I tried to build from the top-level directory I checked out to after a
fresh checkout and it didn't work. I'm at a loss any time I see a Maven
problem (which, in my experience, is
Either way, there should be a release plan if we are moving forward with 1.4.0
* http://wiki.apache.org/struts/StrutsReleasePlans
-T.
On Dec 5, 2007 4:41 AM, Niall Pemberton [EMAIL PROTECTED] wrote:
I don't remember agreeing to move to JDK 1.5 (from JDK 1.4) for the
next Struts (1.4) version
I *definitely* say no... I know in my shop, we're going to be stuck with
JDK 1.4 for nearly another year because of Websphere, so it would keep
me from moving up the Struts 1.x ladder (although, we're still on 1.2.8
I believe, so we're back a ways regardless).
My feeling is that S1 should
Niall Pemberton wrote:
Looks like core uses JDK 1.5 features - for example the
IllegalStateException constructors which take a Throwable cause were
only added in JDK 1.5:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html
I don't remember agreeing to move to JDK
Well, I saw this morning that Ted linked the Struts 2 release notes on the
MoinMoin wiki. So that started me thinking is MoinMoin the struts wiki or
just the struts 1 wiki? I was hoping for the latter, because then we would
have another wiki for a Struts 3.
Paul
On Dec 5, 2007 11:02 AM, Wendy
Martin, thanks!! :-D
On Dec 5, 2007 11:41 AM, Martin Cooper [EMAIL PROTECTED] wrote:
On Dec 5, 2007 9:30 AM, Paul Benedict [EMAIL PROTECTED] wrote:
Well, I saw this morning that Ted linked the Struts 2 release notes on
the
MoinMoin wiki.
Actually, he UNlinked them, so that MoinMoin
On Dec 5, 2007 9:30 AM, Paul Benedict [EMAIL PROTECTED] wrote:
Well, I saw this morning that Ted linked the Struts 2 release notes on the
MoinMoin wiki.
Actually, he UNlinked them, so that MoinMoin IS just the S1 wiki.
--
Martin Cooper
So that started me thinking is MoinMoin the struts
Any chance we can actually have one wiki for all of Struts? I know we're
using cwiki also to create Struts production documentation, but we can also
use it for development plans? I'd rather leave MoinMoin for a unified wiki
space for all of us.
Paul
So if I want to whiteboard some ideas for code sharing between both s1 and
s2, which wiki should be preferred?
On Dec 5, 2007 11:41 AM, Martin Cooper [EMAIL PROTECTED] wrote:
On Dec 5, 2007 9:30 AM, Paul Benedict [EMAIL PROTECTED] wrote:
Well, I saw this morning that Ted linked the Struts 2
On Dec 5, 2007 9:38 AM, Paul Benedict [EMAIL PROTECTED] wrote:
Any chance we can actually have one wiki for all of Struts? I know we're
using cwiki also to create Struts production documentation, but we can also
use it for development plans? I'd rather leave MoinMoin for a unified wiki
space
I'm confused - why don't we just allow public methods to be called?
Matt
On Dec 5, 2007, at 1:06 PM, Don Brown wrote:
I'm about to commit a fairly large patch that, among other things,
adds built-in support for limiting what methods can be invoked on an
Action. My motivation was actually to
Thanks Paul. No rush, I have a DataVision build to roll today anyway,
not to mention a really hairy prod LDAP issue at work, so it's not like
I have nothing else to do :o
Frank
Paul Benedict wrote:
Well this is a definite oversight and so mea culpa. I am surprised neither
my Maven build
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
Does it make sense to collapse the SU ActionNames and ActionName
annotations into this new annotation? This annotation could provide
additional parameters to control the URLs for the method. If
Don Brown wrote:
1. A new property/constant titled 'struts.restrictToDeclaredMethod'
that will instruct the ActionConfig (where the allowedMethods property
lives) to only allow the method that is explicitly defined (defaults
to 'execute'). If false, all methods will be allowed.
2. A new
I'm about to commit a fairly large patch that, among other things,
adds built-in support for limiting what methods can be invoked on an
Action. My motivation was actually to improve the ability for the
REST plugin to introspect what HTTP methods are supported (automatic
HTTP OPTIONS and WADL
I'm going to start working on the SmartURLs port. Here's what I'm planning:
1. Deprecate all the current codebehind annotations and classes
2. Create a new package named org.apache.struts2.plugin.codebehind
3. Move the SmartURLs classes over (simple re-package)
4. Move annotations into
I didn't unilaterally decide to use JDK 1.5 features. No worries. This is
just an oversight, but what bugs me is that the Maven compiler (at least on
my side) didn't set the right compiler version and catch the error. Bummer.
Anyway, AFAIK, 1.4 is still a JDK 1.4 project. But since Frank tried
Well this is a definite oversight and so mea culpa. I am surprised neither
my Maven build picked this up nor Continuum which is running the
Struts 1.4build at Apache. When I get home, Frank, I will fix this for
you.
Paul
On Dec 5, 2007 7:55 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote:
I
Don Brown wrote:
2. A new attribute on the action element called 'allowedMethods',
which takes a comma-separated list of method names to allow
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
I'm thinking about doing all three, but I'm not sure #2
STR-3118 has been opened to track this issue:
https://issues.apache.org/struts/browse/STR-3118
You should have no problems now, but you never know. :)
Paul
On Dec 5, 2007 10:25 AM, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Thanks Paul. No rush, I have a DataVision build to roll today
I've been emailing the authors of HDIV offline for some quite time. I take a
fond interest in data integrity and security, and believe their project is a
great benefit to Struts. The problem, of course, exists that S1 and S2 are
so radical in architecture that separate deliverables are required.
21 matches
Mail list logo
