I figured there would be no problem using field injection since one of the big accomplishments of 299 was to make that service extremely efficient. I'm just thinking that we should leverage other types of injection where appropriate, perhaps making the judgment call at the time. For instance, if a bean uses one other dependency, and it always needs that dependency, then I think it should be provided through an @Initializer constructor. I see field injection more as a "I need it sometimes, but not always and maybe never" case. Then of course there are producer methods and the like that could avoid the field injection if the dependency pertains only to that method.
...so in short, I think we should choose wisely rather than always opting for field injection....and we should avoid as much as possible direct lookups to the Manager inside of a method...because it makes the class more difficult to unit test.
Btw, testing Web Beans so far is just dreamy. I get excited just to write tests again ;)
I don't see a good reason to avoid the use of injection with the web
beans core, since it doesn't have the same performance implications.
Anyway, we could hardcode optimizations for commonly used types...
On Mon, Apr 27, 2009 at 1:00 PM, Dan Allen <email@example.com> wrote:
> In the development of Seam 3, when we need a reference to another component,
> which of the following should we be using (in general practice, not
> necessarily exclusively)?
> @Current Expressions expressions;
> @Current Manager manager
> (bindings may exist too)
> The heavy use of statics in Seam made it a huge pain to setup for
> unit/multi-unit testing. It's a toss up for me w/ Seam 3 because while it is
> easy to inject a mock Expressions in a pure unit test (no Web Beans
> manager), it is arguably just as easy to inject a @Mock MockExpressions with
> the thin @Artifact test framework. I still like the idea of being able to go
> w/o the manager though.
> As a follow up question, when we do an injection, should it be private,
> package, or protected. Package seems to make the most sense now that it is
> easy for us to put tests in the same package. Private seems like a bad
> choice to me...with protected maybe a bit too exposed.
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a message if
> you feel that it did not reach my attention.
> seam-dev mailing list