Without too long of a reply, here are a few thoughts:
- Solid, unchanging public APIs are possible
- Refactoring and using the latest technologies is the only way to
survive
- This would not break separation or dictate it for that matter
- It would force necessary
First, injecting the Container (or Injector as it is called) is allowed in the
JSR and the API is abstracted well enough that it shouldn't cause major
concerns.
On the flip-side, I contend that those instances are broken and can be fixed.
I also don't agree that 330 is too narrow. It should
I am carrying the Guice thread over here because I'm getting lost a bit...
Don, you bring up quite a few good points and I don't want to come off
as argumentative, but I don't necessarily agree with all of them...
This thread can hopefully talk to the API Problem
You brought up a point about how
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The Managed Beans JSR I started reading
the other day does offer a few useful features that we don't have. One
is the conversation scope, which I think Struts 2 could really
benefit from. That's
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown mr...@twdata.org wrote:
It isn't about needing a struts-light, it is adding unnecessary
bulk. When I was more active, I spent a lot of time trying to kick
out dependencies, tighten up our weak API's, and overall simplify
interactions with the
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote:
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The Managed Beans JSR I started reading
the other day does offer a few useful features that we don't have. One
is the conversation scope,
