On Fri, May 29, 2009 at 7:29 AM, Pete Muir <pmuir@bleepbleep.org.uk> wrote:
We should probably maintain Java 5 support for Seam 3 - I see some Java 6 deps creeping in (like the java.util.ServiceLoader in bridge-api).

Absolutely. I just threw that in there right now to get it working quickly as a prototype. That module is still under review so I didn't want to spend time on writing a Java 5 substitute for ServiceLoader until we got it resolved.

Speaking of which, we have brainstormed several approaches to this problem, one of which is to use a custom servlet as a way to capture the BeanManager from an injection and store it in the application context. However, wouldn't it still be reasonable to have an SPI to hide this detail, with the implementation being to consult the application context? JSF's ExternalContext is available through a static call (via FacesContext#getCurrentInstance()), but what about other frameworks like Wicket? You are now faces with the issue of getting access to the application context (maybe there is a way in Wicket).

And one other thought. In the SeamELResolver we want to be able to instantiate the WebBeansELResolver for resolving named beans via EL expressions in the Java API (an example is in a bundle message). But the ELResolver is impl specific. So again, we would need a portable way to instantiate this class. I was going to use an SPI for that and put it in this module. But then we do need an impl per 299 impl.


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.