Well I am looking at the Parameter Filter Interceptor
(http://cwiki.apache.org/WW/parameter-filter-interceptor.html) which I
am proposing we complement by allowing the same thing with annotations.
Currently we have a wizard like section in one of our sites which we are
backing with Spring session
I'm more than happy to provide these archetypes as part of AppFuse
Light (or putting them under the Struts umbrella). I plan on adding
support for Struts 2 + JSF Plugin in the near future.
Currently, I'm waiting for Maven to release their ArchetypeNG plugin
that allows you to create archetypes fro
This sounds more of a security level concern and is currently handled by
ACEGI and I would assume other projects as well. Or am I missing something?
-bp
Martin Gilday wrote:
Where abouts is the annotations plugin housed? I could not see it in
the struts2 trunk or sandbox trunk. Following Do
Hmmm ... it worked fine for me.
What errors are you getting?
I just did:
[EMAIL PROTECTED] ~/svn/STRUTS_2_0_X]$ mvn clean install -Pall
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Struts 2
[INFO] Struts 2 Core
[INFO] Struts Plugins
[INFO] Struts 2 Codebehind Plu
I think I would agree actually. I'm not sure about the performance
implications. I had only planned on preventing the parameters
interceptor setting to them, so it wouldn't be on every field access.
- Original message -
From: "Chris Pratt" <[EMAIL PROTECTED]>
To: "Struts Developers List
> My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> setter. It might make more sense for this feature/annotation to be part
> of the annotations plugin. Does anyone else see this as a use
Ted Husted wrote:
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
True, but I was talking about APT, and in that case it's not really
making anything easier as far as I can tell... APT is already pretty
close to plug-and-play as you know... aside from making the config file
name a d
I've got a little bit of time today, I'll take a look at it.
--
James Mitchell
On Oct 23, 2007, at 10:18 AM, Ted Husted wrote:
Argh!
I'm getting test-build errors on the HEAD. I don't know if these are
the same we were having before, or a new issue. I double my heap
setting to 2048, but no
Am Dienstag, 23. Oktober 2007 16:02:01 schrieb Ted Husted:
> Does NetBeans bundle a database now? Along with Spring 2, Hibernate 3,
> and Struts 1 (not to mention Tapestry), MyEclipse 6 also includes
> Tomcat and Derby, so it is, in fact, an end- to-end, full-stack
> solution.
If you choose to ins
Argh!
I'm getting test-build errors on the HEAD. I don't know if these are
the same we were having before, or a new issue. I double my heap
setting to 2048, but no joy. So, it's probably looping.
---
[#attr.templateDir]
2007-10-23 10:13:37,090 WARN [CommonsLogger.java:46] : Could not find prope
On 10/23/07, Piero Sartini <[EMAIL PROTECTED]> wrote:
> This sounds much like NetBeans ;-)
Quite possibily. It's been awhile since I looked at NetBeans. Of
course, an advantage there is that you can also get Java in the same
download :)
I've been doing conducting a series of training classes for
On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> I guess this is where we differ. I think we absolutely shouldn't be
> creating new conventions because:
> 1. The Rails conventions have been used for years and have proven valuable
Struts 1 has been used for years, and proven valuable. But that
Am Dienstag, 23. Oktober 2007 15:18:01 schrieb Ted Husted:
> With Java installed, MyEclipse is now a full stack out-of-the box. You
> don't actually *need* to download anything else. Period. It's also an
> AppFuse-style full-stack, in that you can choose to add and subtract
> features like Struts 1
Fair enough, I guess I was responding more to the little maven 2 here,
little JPA there comment. I would love to see a truly end-to-end
solution like MyEclipse tie everything together. Last I checked, they
weren't supporting Struts 2, but perhaps that's changed?
Don
On 10/23/07, Ted Husted <[EM
I guess this is where we differ. I think we absolutely shouldn't be
creating new conventions because:
1. The Rails conventions have been used for years and have proven valuable
2. The Rails conventions match what people think about when they
think of a Restful URL
3. Conventions are already dif
On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> Heh, it is the cobbled-together Java solutions that drive many people
> to Rails in the first place :) I do think there is value in the
> Appfuse approach and would like them to do more to encourage faster,
> full-stack development.
I'm not sure
I have spend some time thinking about this problem - especially when I
was working on the ajax code - but I can't come up with a good solution
(or maybe its just I haven't thought about it enough).
The problem is the bigger picture, and as I see it, is that you may want
to re-use an entire par
On 10/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> Why not make this "name.extension", and make it part of the core framework?
>
> Instead of just having one default result, we could have a default
> result for various extension types. Not just for this plugin, but for
> all XWork2 applications.
Craig McClanahan wrote:
> I've gone over to the dark side :-)
No, no, no. I went over to the dark side when I stuck with my team
after the organization switched to .NET. :)
Personally, I'd characterize going over to Rails as walking into the light :)
We have several other Struts committers that
(From "Plugins gone Wild")
On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> Also, I wouldn't include the rest plugin in core as it places some
> strict requirements on the format of the url that won't be compatible
> with most Struts 2 apps.
That's a good point. I went over the Rails conventio
On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> * Ability to customize XML and JSON output (declare a result named
> "NAME-EXTENSION", e.g. "success-xml"
Why not make this "name.extension", and make it part of the core framework?
Instead of just having one default result, we could have a def
The release has been submitted for mirroring. Here's a draft
announcement that we could post tomorrow morning. Is there anything in
the release that we should be highlighting?
The Apache Struts group is pleased to announce that Struts 2.0.11 is
available as a "General Availability" release.
On 10/23/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
> Where abouts is the annotations plugin housed? I could not see it in
> the struts2 trunk or sandbox trunk. Following Don's comment in this
> https://issues.apache.org/struts/browse/WW-2264 I was interested in
> trying to created this feature
The source has been moved to the codebehind plugin. The package is
org.apache.struts2.config. If we keep it there, which is fine with me,
then we wouldn't need a separate annotations plugin.
*
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/codebehind/src/main/java/org/apache/struts2/c
Where abouts is the annotations plugin housed? I could not see it in
the struts2 trunk or sandbox trunk. Following Don's comment in this
https://issues.apache.org/struts/browse/WW-2264 I was interested in
trying to created this feature "A new feature we could add would be a
new annotation so that
+1 GA binding
* Antonio Petrelli
* Ted Husted
* Rainer Hermanns
+1 GA supporting
* Piero Sartini
* Matt Raible (committer)
* Pedro Herrera
Struts 2.0.11 is now rated at GA, and I will proceed to announce the release.
-Ted.
The problem seems to be that we need a volunteer who is eager to work
on this feature. The patch was a start, but only a start, and the
comments indicate that there is still a lot of work to do.
-Ted.
On 10/19/07, Aymeric Levaux <[EMAIL PROTECTED]> wrote:
> Hi,
>
> At this time there is no way to
So, to follow-up, the amended struts-core-plugins.jar list seems to be
* annotations plugin (new)
* codebehind plugin (including zero-config)
* tags plugin (new)
I'd like to keep codebehind in the core, since I believe we are on
track for making XML-action-free Struts apps the recommended a
On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> True, but I was talking about APT, and in that case it's not really
> making anything easier as far as I can tell... APT is already pretty
> close to plug-and-play as you know... aside from making the config file
> name a default, which wo
On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> It might be interesting to have several "bundles":
> * Core - codebehind, dojo
> * Starter - codebehind, dojo, spring, jpa
> * Rest - codebehind, rest, dojo
This might be a great role for AppFuse-style Maven prototypes!
-Ted.
---
Initially, it was just knee-jerk backward-compatibility with the Ajax
theme. But, I think this is a good point. If we want extensions to the
base tags, we can always just drop in whatever other plugin we like.
Or just use Ajax "out of the box", without the plugin grease.
The name "core" came about
Great post, Craig. Most everything you describe is supported by the
Rest Plugin:
* All the described URL patterns
* The automatic use of the Location header after a POST
* Ability to switch representation using extension (adding accept
header support would be easy)
* All actions are on one Co
I haven't been following this topic too closely, so apologies if I have
missed the point. Why is dojo being considered a core plugin? I
understand it is used by some of the tags to simplify some AJAX tasks,
are there any other benefits to it?. From my brief experience with it
Dojo is not the mos
On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > >
> > > [...]
> > > Which reminds me, this plugin is targeted towards HTML-based web apps
> > > that want to expose their information i
34 matches
Mail list logo
