Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 14D486D05 for ; Mon, 13 Jun 2011 09:15:09 +0000 (UTC) Received: (qmail 7795 invoked by uid 500); 13 Jun 2011 09:15:08 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 7733 invoked by uid 500); 13 Jun 2011 09:15:08 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 7726 invoked by uid 99); 13 Jun 2011 09:15:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jun 2011 09:15:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of genspring@gmail.com designates 209.85.215.54 as permitted sender) Received: from [209.85.215.54] (HELO mail-ew0-f54.google.com) (209.85.215.54) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jun 2011 09:15:00 +0000 Received: by ewy1 with SMTP id 1so2205988ewy.13 for ; Mon, 13 Jun 2011 02:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1su0HpFZ2dg/Ep3L63ukW+p7PD0idfXNQ6v36MIZKdw=; b=sc0mtYfcjGyYcJxQCGq6AW2Rn7fMLtRL2qvprr1Y8n5O9k5Fz+plxbUCeBxSqYrTYR OhINzQjaiLT0ZYwbgpfx8uc2nHiVsqCRwu1FtxqbU0GwBaXvHabRjEeeGx4wUu/qrz/o WFVx4z230JJSnb0kh1S7g3qA5tjp4vv/SjI3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=efj2f1Sm1nGbYVsICdYsbz5sjYhwI+sXJebCcRlRzVxyUTegwRqey+5XXRvyKRMY+i DF/6TmPWc5blJRXTB939XuRNkz/WXMNnGZ97ivNmM7Beh1SZa/MNNlUjRfCY66IHCQ/K V2eeVunm3e0D4liNvGJUZMyXnRwrdZkqkXedA= MIME-Version: 1.0 Received: by 10.213.4.10 with SMTP id 10mr2512918ebp.102.1307956480049; Mon, 13 Jun 2011 02:14:40 -0700 (PDT) Received: by 10.213.30.17 with HTTP; Mon, 13 Jun 2011 02:14:40 -0700 (PDT) In-Reply-To: <34115D2E-6DBB-47C1-A172-A6762D7ABCE9@gmail.com> References: <34115D2E-6DBB-47C1-A172-A6762D7ABCE9@gmail.com> Date: Mon, 13 Jun 2011 17:14:40 +0800 Message-ID: Subject: Re: [DISCUSSION] How to bring server global/app context to applient context ? From: Shawn Jiang To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=000e0cd1ea6e6002a804a59459b3 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd1ea6e6002a804a59459b3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 13, 2011 at 11:35 AM, David Blevins 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 > 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 --000e0cd1ea6e6002a804a59459b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 13, 2011 at 11:35 AM, David = Blevins <da= vid.blevins@gmail.com> wrote:

On Jun 12, 2011, at 2:53 AM, Shawn Jiang wrote:

> For leveraging openejb remote jndi system idea, =A0 I thought about it= , =A0 to add =A0"global/app xxx" "openejb/deployment/xxx&quo= t; mapping in openejb so that when a jndi request comes, =A0openejb could r= eturn the requested object with following path
>
> java:global/xxxxx name =A0----> =A0"openejb/deployment/xxxx&qu= ot; name =A0---> ejb proxy object.

In that regard we sort of have a global tree already -- was never fin= ished, but will get us by. =A0Implemented a quick 'global' lookup a= bility in the o.a.openejb.ejbd.JndiRequestHandler

It basically assumes all names that start with "global" are globa= l names and directs the call to the "first" global namespace.

Typically we've been using the "moduleId" request parameter t= o redirect calls to other contexts. =A0We 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, =A0 how do we wrap the ja= va:global and java:app jndi lookup with something like ClientEjbReference s= o that it could genereate a remote openejb jndi request =A0 in initialConte= xt.lookup() automatically ? =A0 And we need to bind a environment entries b= inding copy to openejb jndi ?

Not sure on this one either. =A0If we're using xbean-naming on th= e client we could maybe use a federated context to delegate all unsuccessfu= l "global" lookups to the OpenEJB client context.

AppClient is using RootContext,=A0 we still could fall back to ope= nejb client context when it can't find the global/app name. =A0 I'v= e started to do the initial patch based on openejb remote jndi and local gl= obal/app name retry.=A0

I'm now blocked by build failures caused by the poor network.=A0 wi= ll attach the patch for review once I finish it.



-David


> On Sun, Jun 12, 2011 at 2:51 PM, David Jencks <david_jencks@yahoo.com> wrote:
> I think we should use the openejb remote jndi system. =A0We might need= to modify it. =A0AFAIK the only things it makes sense to get to the app cl= ient are environment entries and remote ejbs.
>
>
> thanks
> david jencks
>
>
> On Jun 11, 2011, at 8:28 PM, Shawn Jiang wrote:
>
> > Curretly, =A0we only include the ear global and app context to ap= plication client context. =A0 because applient is running in different VM o= ther than server itself. =A0 As a result, =A0you can't use JNDI lookup = to get the server global/app reference =A0in appclient.
> >
> > Sure we want to add the global and app context in whole server to= appclient module. =A0 Currently, =A0following code was used to create the = app client context at build time.
> >
> > ----------------------------------
> >
> > org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBea= ns(EARContext, Module, Bundle, Collection) {
> >
> > ....
> > AbstractName jndiContextName =3D earContext.getNaming().createChi= ldName(appClientDeploymentContext.getModuleName(), "StaticJndiContext&= quot;, "StaticJndiContext");
> > GBeanData jndiContextGBeanData =3D new GBeanData(jndiContextName,= StaticJndiContextPlugin.class);
> > jndiContextGBeanData.setAttribute("context", appClientM= odule.getJndiContext());
> > ......
> >
> > }
> >
> > -------------------------------
> >
> >
> > Can anyone shed some light on how to bring server global/app cont= ext to applient context ?
> >
> > --
> > Shawn
>
>
>
>
> --
> Shawn




--
Shawn
--000e0cd1ea6e6002a804a59459b3--