I've go ahead and re-added the fix and update WW-1489 as well. Do have a go
through if you got the time, thx.
Cheers.
Don Brown [EMAIL PROTECTED] wrote: Hmm...ok. The reason I took it out was it
was initializing the
framework twice, but I can see how we would need it. If you have a
I've redesigned the Struts configuration scheme to better structure
XWork and Struts internals, allow self-configuring plugins, and reduce
the amount of configuration necessary to write a Struts application -
none, in fact.
The core changes are:
- A new dependency injection engine in XWork
On 11/13/06, Don Brown [EMAIL PROTECTED] wrote:
My favorite part of the changes is the ability to have a fully
functional Struts app with no additional XML or properties files. Just
set the actionPackages property in web.xml, and Struts will scan those
packages and their subpackages for any
I'd be interested in doing this in Equinox as well. Does it simply
follow convention over configuration or are annotations leveraged?
Got any documentation? ;-)
Matt
On 11/13/06, Ted Husted [EMAIL PROTECTED] wrote:
On 11/13/06, Don Brown [EMAIL PROTECTED] wrote:
My favorite part of the
On 11/13/06, Matt Raible [EMAIL PROTECTED] wrote:
I'd be interested in doing this in Equinox as well. Does it simply
follow convention over configuration or are annotations leveraged?
Got any documentation? ;-)
Both. :) Look at the 'Person Manager' section of the showcase for an
example of
On 11/13/06, Wendy Smoak [EMAIL PROTECTED] wrote:
(Last I heard, any class name ending in 'Action' will be discovered.)
Last you heard where?
Is there another thread concerning these changes that we should review?
-Ted.
-
Hi guys,
There might be a fix releated to this
(https://issues.apache.org/struts/browse/WW-1489) that seems to be broken.
WW-1489 abstracted the common logic from both DispatcherFilter and
ActionContextCleanUp to an Abstract filter. With the latest commit,
FilterDispatcher is put back to its
Yeah, I did have to put the filters back to their original state. I
found the _dispatcher and dispatcher variables really confusing and I'm
not sure I understand the original usecase why the cleanup filter needs
to have a dispatcher instance at all. Could you go into detail why the
cleanup
No kidding...I've been working on this damn thing every spare minute for
the last two weeks, trying to get it done before my first child (a son)
arrives (I hear it changes your life drastically) :)
As Wendy said, the best example right now is in the showcase, where the
person package uses the
That sounds exactly like the piece I was working one the last week, so
it seems you guys got more time. Gonna check it soon!
./alex
--
.w( the_mindstorm )p.
On 11/13/06, Don Brown [EMAIL PROTECTED] wrote:
No kidding...I've been working on this damn thing every spare minute for
the last two
I made a page from the cheatsheet, to help get us started.
* http://cwiki.apache.org/WW/zero-configuration.html
-T.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 11/13/06, Ted Husted [EMAIL PROTECTED] wrote:
On 11/13/06, Wendy Smoak [EMAIL PROTECTED] wrote:
(Last I heard, any class name ending in 'Action' will be discovered.)
Last you heard where?
Is there another thread concerning these changes that we should review?
Nope, just Don saying Hey,
Could you go into detail why the cleanup filter needs to initialize the
dispatcher?
Yup sure. :)
ActionContextCleanUp and FilterDispatcher both keeps a copy of Dispatcher, and
put them in thread local only if one doesn't exists yet. The order of filters
when using sitemesh would be
1]
13 matches
Mail list logo
