On Mon, Jun 13, 2011 at 11:35 AM, David Blevins <[email protected]>wrote:
> > On Jun 12, 2011, at 2:53 AM, Shawn Jiang wrote: > > > For leveraging openejb remote jndi system idea, I thought about it, > to add "global/app xxx" "openejb/deployment/xxx" mapping in openejb so that > when a jndi request comes, openejb could return the requested object with > following path > > > > java:global/xxxxx name ----> "openejb/deployment/xxxx" name ---> ejb > proxy object. > > In that regard we sort of have a global tree already -- was never finished, > but will get us by. Implemented a quick 'global' lookup ability in the > o.a.openejb.ejbd.JndiRequestHandler > > It basically assumes all names that start with "global" are global names > and directs the call to the "first" global namespace. > > Typically we've been using the "moduleId" request parameter to redirect > calls to other contexts. We can leverage that for global/app lookups as > well if it makes things easier. > > Don't know if we want to use it, but it's there if we do. > > > But we still need to handle the client side, how do we wrap the > java:global and java:app jndi lookup with something like ClientEjbReference > so that it could genereate a remote openejb jndi request in > initialContext.lookup() automatically ? And we need to bind a environment > entries binding copy to openejb jndi ? > > Not sure on this one either. If we're using xbean-naming on the client we > could maybe use a federated context to delegate all unsuccessful "global" > lookups to the OpenEJB client context. > AppClient is using RootContext, we still could fall back to openejb client context when it can't find the global/app name. I've started to do the initial patch based on openejb remote jndi and local global/app name retry. I'm now blocked by build failures caused by the poor network. will attach the patch for review once I finish it. > -David > > > > On Sun, Jun 12, 2011 at 2:51 PM, David Jencks <[email protected]> > wrote: > > I think we should use the openejb remote jndi system. We might need to > modify it. AFAIK the only things it makes sense to get to the app client > are environment entries and remote ejbs. > > > > > > thanks > > david jencks > > > > > > On Jun 11, 2011, at 8:28 PM, Shawn Jiang wrote: > > > > > Curretly, we only include the ear global and app context to > application client context. because applient is running in different VM > other than server itself. As a result, you can't use JNDI lookup to get > the server global/app reference in appclient. > > > > > > Sure we want to add the global and app context in whole server to > appclient module. Currently, following code was used to create the app > client context at build time. > > > > > > ---------------------------------- > > > > > > > org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(EARContext, > Module, Bundle, Collection) { > > > > > > .... > > > AbstractName jndiContextName = > earContext.getNaming().createChildName(appClientDeploymentContext.getModuleName(), > "StaticJndiContext", "StaticJndiContext"); > > > GBeanData jndiContextGBeanData = new GBeanData(jndiContextName, > StaticJndiContextPlugin.class); > > > jndiContextGBeanData.setAttribute("context", > appClientModule.getJndiContext()); > > > ...... > > > > > > } > > > > > > ------------------------------- > > > > > > > > > Can anyone shed some light on how to bring server global/app context to > applient context ? > > > > > > -- > > > Shawn > > > > > > > > > > -- > > Shawn > > -- Shawn
