[thammoud]

Thank you very much. EJBCLIENT-34 certainly looks promising as far as the context setup is concerned.

We should avoid the confusion that's already there related to the various ways (remote-naming and ejb-client API) for remote EJB invocations.

7 is very new, the two current methods of remote invocation are a bit confusing. i.e Break the damn API if you have to , since we will have to live with the consequences for a very very long time. Good luck and thank you gain.

[sumitsu]

Jaikiran, thank you for continuing to pursue this issue.  I took a look at your latest source code under your fork of the jboss-ejb-client project; please let me know if I'm understanding correctly:

• The JNDI InitialContext will still be initialized with Context.URL_PKG_PREFIXES=org.jboss.ejb.client.naming.
• However, instead of using a singleton EJBNamingContext (EJBNamingContext.ROOT), a new EJBNamingContext will be created and initialized using the JNDI environment map passed to the InitialContext.
• If that environment map contains a key-value pair org.jboss.ejb.client.scoped.context=true, then a unique identifier (derived from an atomic sequence) will be assigned to the EJBNamingContext instance, and a new EJBClientContext will be created from the values in the JNDI environment map used to initialize the EJBNamingContext.
  
• The new EJBClientContext (with specified environment variables) will be cached (registered) in a map (ConfigBasedEJBClientContextSelector.identifiableContexts) contained in the singleton ContextSelector referenced by EJBClientContext.SELECTOR.  Its key will be the unique ID assigned to the EJBNamingContext.
• All EJB lookups through the EJBNamingContext instance will be proxied to that EJBClientContext by looking up the EJBNamingContext's unique ID in ConfigBasedEJBClientContextSelector.identifiableContexts.
• When the EJBNamingContext is closed, the associated EJBClientContext will be deregistered via removal from ConfigBasedEJBClientContextSelector.identifiableContexts.

If the above is correct, then thread-safety should be maintained by virtue of the locally-scoped (non-singleton) EJBNamingContext instances plus the synchronized access to ConfigBasedEJBClientContextSelector.identifiableContexts.

Also, it will no longer be necessary to change the EJBClientContext.SELECTOR singleton, per the original without-a-property-file workaround -- and in fact doing so would break any clients using this new "identifiable contexts" way of performing remote lookups, since it would make the identifiableContexts map inaccessible.  (Probably not a problem, as long as one ensures that the original workaround code is not running anywhere else in the same class loader.)

Is the above a good description of your changes?  Thanks again for your work on this.

[rodakr]

Jaikiran

Thanks 1000 time in adance for IdentityEJBClientContextSelector with register & unregigster ...

[jaikiran]

Wow! I wasn't expecting anyone to go find that branch and then understand the new code

But your summary of those changes is right, that's exactly what's being done.

[mevans7]

Followup to markus78 who provided a solution to the remote EJB lookup without the jboss-ejb-client.properties file:

Note that while under jboss 4.x, you could close the InitialContext() object then call the proxy method, using the markus78 solution, you CANNOT close the InitialContext() before you make the EJB call.