On 12/07/2010 02:35 AM, Carlo de Wolf wrote: OK. No, the intent is like we talked about: the binding can happen first, and things depend on the binding. If a binding is used before it is ready it has one of several possible outcomes: 1. If the service is still coming up, wait for it to finish. 2. If the service is missing, error. 3. If the service is there but has failed, error. This seems to be about the best we can do due to the required two-phase nature of EJB startup. Ah okay. Does this mean that these interceptors cannot be disabled globally, at all? If so, I'll make note of that. OK, so the user has to specify them? That is the intent of the rule, but I may have got it wrong in the requirements. You're right, the dependency should be on the JNDI binding (first phase). I'll make that correction. I implied it via #5's note, but for now I'd prefer to leave it unspecified until we can be sure it will work 100% of the time. That's the point of bullet #3 on that item. I didn't order the resolution that way though, because I had assumed that the endpoint activation is something outside of the control of the EJB layer (i.e. it comes from JCA as a message inflow thing of some sort). I suppose this rather implies a different dependency relationship: the MDB doesn't depend on the endpoint activation; rather, the endpoint activation depends on a consumer (the MDB) being available (which makes much more sense, now that I think of it). I can make that change. Yeah that's what I'm getting at. The possibility of circular deps is what makes it interesting. The problem is that it's hard to detect all possible errors (including initialization errors) in all EE resources before their dependents are ready to execute. So something may come "up" (on the assumption that because the JNDI binding was successful, the component will become available) only to fail during initialization or usage when the dependency itself fails to initialize for some reason. But, it looks like this two-phase setup is probably the most elegant solution allowed by the spec in any case. I'll make the changes, keep the comments coming... -- - DML

On 12/7/10 8:25 AM, Jaikiran Pai wrote: Yes, all clients (in particular app client) need to have a global namespace that mirrors the server for at least remote . However, this doesn't mean we *must* use remote JNDI calls to do it. I think a more flexible (and likely more efficient) thing to do is to have a "replicated" naming view. So when an app client is setup it maintains it's own "comp" and "module", and global can lazily sync via some mechanism. This solves many issues, like what does java:comp/ORB point to on a client. It only makes sense to point to the client's local ORB instance. The same applies to jdbc/jca resources. -- Jason T. Greene JBoss, a division of Red Hat