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
...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 ;)
On Tue, Apr 28, 2009 at 4:17 PM, Gavin King <gavin.king(a)gmail.com> wrote:
I don't see a good reason to avoid the use of injection with the
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 <dan.j.allen(a)gmail.com> wrote:
> In the development of Seam 3, when we need a reference to another
> 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
> 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
> the thin @Artifact test framework. I still like the idea of being able to
> 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
> 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
> 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
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.