<div class="gmail_quote">On Wed, Mar 24, 2010 at 11:59 AM, David Allen <span dir="ltr"><<a href="mailto:drallendc@gmail.com">drallendc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am Mittwoch, den 24.03.2010, 11:36 -0400 schrieb Dan Allen:<br>
<div><div></div><div class="h5">> On Wed, Mar 24, 2010 at 11:24 AM, David Allen <<a href="mailto:drallendc@gmail.com">drallendc@gmail.com</a>><br>
> wrote:<br>
> Am Mittwoch, den 24.03.2010, 11:11 -0400 schrieb Dan Allen:<br>
> > On Wed, Mar 24, 2010 at 3:38 AM, Emmanuel Bernard<br>
> > <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
> > But how do you solve that in SE? Or even in a web<br>
> environment,<br>
> > more and more web environment are getting away from<br>
> the<br>
> > servlet API imposed constraint.<br>
> ><br>
> ><br>
> > Sigh. And that's why this problem is more difficult than it<br>
> has to be.<br>
> > Because we can't even handle the 80-90% case.<br>
> ><br>
> ><br>
> > But you did get me thinking. Maybe the way to address the<br>
> problem is<br>
> > to see this more as an integration concern for the SPI. So<br>
> if I'm<br>
> > running in a servlet environment (whether it be a servlet<br>
> container or<br>
> > Java EE), then I'm providing an implementation that<br>
> standardizes on<br>
> > the servlet context. But we can define other mappings for<br>
> other known<br>
> > environments, or unknown environments can supply the SPI<br>
> impl.<br>
> ><br>
> ><br>
> > Btw, it's not like JNDI is all that portable to SE either ;)<br>
><br>
><br>
> Actually JNDI is quite simple and can be used in any Java<br>
> application.<br>
> It does not necessarily require a server. It is just an API<br>
> and a<br>
> simple implementation can always be used to provide the<br>
> necessary<br>
> functionality within an SE.<br>
><br>
> Here's one example:<br>
> <a href="http://www.osjava.org/simple-jndi/index.html" target="_blank">http://www.osjava.org/simple-jndi/index.html</a><br>
><br>
><br>
> What I meant by portable is that an extension can assume it is<br>
> present. We can only assume it is present in Java EE, because it is<br>
> only required there. Servlet containers, while they do have JNDI,<br>
> don't have a writable java:comp/env JNDI namespace, so that's pretty<br>
> much the same as it not being there. That's the whole reason we are in<br>
> this fix.<br>
<br>
</div></div>Yeah, this might be true in general; however, we do have Weld working in<br>
Tomcat, and I believe it is entered into JNDI there as well. It took<br>
some work to do that, though, since that space is normally read-only at<br>
runtime. And actually that was done under the old java:app namespace.<br>
Maybe this is even more difficult under java:comp/env.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div>My understanding was that onus is on the developer to include the BeanManager definition in context.xml (and similar for Jetty). To me, that's just an unnecessary requirement. I'm being tough because a lot of end developers are going to see this requirement and be like "forget it, too much work".</div>
<div><br></div><div>-Dan</div><div> </div></div>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>