On 20/08/10 18:42, Dominik Dorn wrote:
> I came up with this a few months ago. The answer I got was that it's
> not a bug in the implementation but in the specification that does not
> specify how far CDI and JSF should work together.
Hooray for complicated interlocking specs developed in parallel :S . I
thought CDI was suppoed to make things easier and more consistent, but
so far I've just had problems with it compared to JSF2's injection features.
Did you find a way to solve or work around this issue? Give up on
Glassfish's CDI/Weld support as not production-ready and go back to pure
JSF2? Lookup the EJB via JNDI instead? Avoid the need to use EJBs?
Something else?
I'm going to expose my ignorance of JNDI at this point and ask, if you
used JNDI, how you looked up the EJB you needed. I've been trying, but
just can't seem to obtain the bean.
If I enumerate the entries under "java:module/env/" with something like:
try {
InitialContext ctx = new InitialContext();
NamingEnumeration<NameClassPair> items = ctx.list("java:module/env/");
while (items.hasMoreElements()) {
NameClassPair p = items.next();
System.err.println("JNDI item: " + p.getName() +
": " + p.getClassName());
}
} catch (NamingException ex) {
throw new RuntimeException(ex);
}
.... I can find the @Named model beans, but not the EJBs. A lookup for
the fully qualified classname of the EJB under java:module/env/ throws a
naming exception reporting that the class name can't be found.
How does one obtain an EJB from a FacesConverter?
( and should I just switch to targeting JBoss AS + Seam, where this
stuff reportedly works? )
--
Craig Ringer