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 s
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 ho
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 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 framework. If you
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