ok so here's a thread that started in the Web Beans forum.
I very rarely argue with the Seam devs' ideas and opinions (well, lately anyways :)
But consider this from PMuir in my link:
Q: So is outjection (which is 1/3 of bijection), now an anti-pattern, so to speak?
PMuir: It's not an anit-pattern IMO, but I would always use it as an optimization, not part of the base design for the app.
Q: I've used outjectin a lot in my code using @Out in Seam apps... Is the problem due to the fact that the HttpSession gets bloated with objects when you continually outject to session and/or conversation contexts?
PMuir: No, for me the problem is it produces apps in which the wiring can be harder to understand.
So I'm wondering if any of you Seam developers agree/disagree with these statements (I'm neutral now)? I think the reason PMuir is talking about the wiring being harder to understand is that it's sometimes difficult (even in a small app) to track down to which Seam component the injected variable was originally outjected from.
Perhaps a productivity issue? The bijection
occurs in a context space (e.g. HttpSession or Conversation scope, which is managed space in HttpSession) which is sort of
invisible to the developer.
Well, isn't that what JBoss Tools is for? There is a Seam components view available. But all it shows is the scope for that Seam component, the package and class for that component, and that's it. No context variable data is available. And even if it was, what if you had dozens or hundreds of Seam components that are bijecting variables left and right? Gets hard to keep track of. Perhaps that's what he means by
wiring can be harder to understand. And then compared to using JNDI lookups like we did left and right in Struts/EJB2.x apps (and even straight-up EJB3)?
Wondering if DI w/ Guice in JSR299 will be different/better....
So does the comment about outjection apply to injection as well? You obviously know exactly where the variable is coming from when you outject (but not necessarily so when you inject).