Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 77458 invoked from network); 27 Apr 2006 06:14:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Apr 2006 06:14:33 -0000 Received: (qmail 85673 invoked by uid 500); 27 Apr 2006 06:14:29 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 85635 invoked by uid 500); 27 Apr 2006 06:14:28 -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 85624 invoked by uid 99); 27 Apr 2006 06:14:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Apr 2006 23:14:28 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of manu.t.george@gmail.com designates 64.233.162.193 as permitted sender) Received: from [64.233.162.193] (HELO nz-out-0102.google.com) (64.233.162.193) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Apr 2006 23:14:27 -0700 Received: by nz-out-0102.google.com with SMTP id 4so1517687nzn for ; Wed, 26 Apr 2006 23:14:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Z58zKFSP6ONLi4BAh/h0vftu1Vhh9lFxQmodNqSNUXpIAg/h0yu9KSnVe0D4UdYL2V5Lu26MtyvGA86VxzvGx56WuvgSzDmhS982n6IDBjokNxbLrXZCjNYDsVtLu0GYFOikyNHlYTFA1AQLXIWY8tYGuLSjEPrOZXePyeV5OFg= Received: by 10.65.150.20 with SMTP id c20mr757651qbo; Wed, 26 Apr 2006 23:14:07 -0700 (PDT) Received: by 10.65.204.18 with HTTP; Wed, 26 Apr 2006 23:14:07 -0700 (PDT) Message-ID: <466797bd0604262314r8bce69fk2b3e8c4138221cb4@mail.gmail.com> Date: Thu, 27 Apr 2006 11:44:07 +0530 From: "Manu George" To: dev@geronimo.apache.org Subject: Re: Implementing Global JNDI In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3063_18516355.1146118447025" References: <2ed2f49c0604210240i6aeb689dnf5baf7e5f0cd7bd0@mail.gmail.com> <466797bd0604250734l7a09562eg34be2e8d1826bd8a@mail.gmail.com> <466797bd0604260015p7368f630h9414a9cafa0c6be3@mail.gmail.com> <444F24D8.7070804@worldonline.fr> <2ed2f49c0604260501sc22dfcbg4ace0ca0894efd54@mail.gmail.com> <444F6BD7.1030202@worldonline.fr> <466797bd0604260632r147bd3c3u898774514f07e324@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_3063_18516355.1146118447025 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree with what Dain said. I also believe that as the spec says the J2EE component enviroment should not be writable and we need not provide any option for that either. It is not necessary. Apps can bind to other namespaces. On 4/26/06, Dain Sundstrom wrote: > > Are you planning on making the J2EE component enviroment (java:comp/ > env) writable? I can see making the global tree writable, but am > concerned about making the component environment itself writable. > The J2EE 1.4 spec page 64 states: > > The container must ensure that the application component instances > have only > read access to their environment variables. The container must throw the > javax.naming.OperationNotSupportedException from all the methods of the > javax.naming.Context interface that modify the environment naming > context > and its subcontexts > > I suppose we could add an optional flag for non-compliant > applications to allow them to modify their environment, but I think > the default for the component environment should be read-only. > > BTW, I am in favor of making everything else writable. > > -dain > > On Apr 26, 2006, at 6:32 AM, Manu George wrote: > > > Hi, Guillaume > > I guess if a writable context is implemented still the approach > > given above should work. As we will be using the ENCConfigBuilder > > only to populate the ENC during startup the interfaces can be used > > to refer to the gbeans representing the deployed artefacts. > > Whatever we will be writing to context from apps would be done > > after startup of server and lost at shutdown. So there would not > > be any problem due to geronimo using interfaces to get the GBean > > names as what we will be adding at runtime will not be gbeans and > > we will not use ENCConfigBuilder. Am I right? > > > > Now a new property for jndiname will also be required in the plans > > for the connectors. > > > > P.S.This property was actually present in the older versions of > > geronimo but was removed. I also remember david jencks mentioning > > in the mailing list that he had a working implementation of a > > context which he removed for some reason. > > > > Thanks > > Manu > > > > > > > > > >On 4/26/06, Guillaume Nodet < guillaume.nodet@worldonline.fr> wrote: > > > > > > > > >>When a JNDI context is created for a given configuration, the > > interface > > >>name is used to determine the name of the gbean that will be > > mapped to > > >>this JNDI reference (and to create a proxy ?). > > >>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs. > > >>But I guess this is irrelevant if the objects are bound when they > > are > > >>created. > > >> > > >>Btw, should the global JNDI tree be read-only, or read-write ? > > >>IMHO, a read-write global JNDI tree would be very usefull. > > >> > > >>Cheers, > > >>Guillaume Nodet > > >> > > >> > > >>Manu George wrote: > > >> > > >> > > >> > > >>>Thanks David. > > >>> > > >>>Guillaume , Which proxy in the JNDI Tree are you referring where > > >>>geronimo requires the main interface name? Are you speaking of > > >>>UserTransaction etc? I thought those were standard names that we > > can > > >>>use to access them and will not be provided in DD? Please > > clarify and > > >>>correct me if I am wrong. > > >>> > > >>>Thanks > > >>>Manu > > >>> > > >>>On 4/25/06, *David Jencks* > >>>> wrote: > > >>> > > >>> It's required for corba ejb references. > > >>> > > >>> david jencks > > >>> > > >>> On Apr 25, 2006, at 7:34 AM, Manu George wrote: > > >>> > > >>> > Hi, > > >>> > I have a question regarding one of the objects > > present in > > >>> > the current application local JNDI Context. What is the > > >>> > HandleDelegate entry for? > > >>> > > > >>> > Thanks > > >>> > Manu > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > > ------=_Part_3063_18516355.1146118447025 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree with what Dain said.  I also believe that as the spec says the J2EE component enviroment should not be writable and we need not provide any option for that either. It is not necessary. Apps can bind to other namespaces.

On 4/26/06, Dain Sundstrom <dain@iq80.com> wrote:
Are you planning on making the J2EE component enviroment (java:comp/
env= ) writable?  I can see making the global tree writable, but amconcerned about making the component environment itself writable.
The J= 2EE 1.4 spec page 64 states:

The container must ensure that the application= component instances
have only
read access to their environment varia= bles. The container must throw the
javax.naming.OperationNotSupportedExc= eption from all the methods of the
javax.naming.Context interface that modify = the environment naming
context
and its subcontexts

I suppose w= e could add an optional flag for non-compliant
applications to allow the= m to modify their environment, but I think
the default for the component environment should be read-only.

B= TW, I am in favor of making everything else writable.

-dain

O= n Apr 26, 2006, at 6:32 AM, Manu George wrote:

> Hi, Guillaume
>    I guess if a writable context is implemente= d still the approach
> given above should work.   As we wil= l be using the ENCConfigBuilder
> only to populate the ENC during sta= rtup the interfaces can be used
> to refer to the gbeans representing the deployed artefacts.
>= ; Whatever we will be writing to context from apps would be done
> af= ter startup of server and lost at shutdown.  So there would not> be any problem due to geronimo using interfaces to get the GBean
> names as what we will be adding at runtime will not be gbeans and<= br>> we will not use ENCConfigBuilder.  Am I right?
>> Now a new property for jndiname will also be required in the plans> for the connectors.
>
> P.S.This property was actually present in the older versio= ns of
> geronimo but was removed. I also remember david jencks mentio= ning
> in the mailing list that he had a working implementation of a
> context which he removed for some reason.
>
> Thanks> Manu
>
>
> >
> >On 4/26/06, Guillaume = Nodet < guillaume.node= t@worldonline.fr > wrote:
> >
> >
> >>When a JNDI conte= xt is created for a given configuration, the
> interface
> >= >name is used to determine the name of the gbean that will be
> ma= pped to
> >>this JNDI reference (and to create a proxy ?).
> >= ;>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.
> = >>But I guess this is irrelevant if the objects are bound when they
> are
> >>created.
> >>
> >>Btw,= should the global JNDI tree be read-only, or read-write ?
> >>= IMHO, a read-write global JNDI tree would be very usefull.
> >>
> >>Cheers,
> >>Guillaume Nodet
> >>> >>
> >>Manu George wrote:
> >>
>= >>
> >>
> >>>Thanks David.
> >&g= t;>
> >>>Guillaume , Which proxy in the JNDI Tree are you refer= ring where
> >>>geronimo requires the main interface name?&n= bsp; Are you speaking of
> >>>UserTransaction etc? I th= ought those were standard names that we
> can
> >>>use to access them and will not be provide= d in DD? Please
> clarify and
> >>>correct me if I am = wrong.
> >>>
> >>>Thanks
> >>>= Manu
> >>>
> >>>On 4/25/06, *David Jencks* <david_jencks@yahoo.com
> = >>><mailto: david_jen= cks@yahoo.com >> wrote:
> >>>
> >>>  &n= bsp; It's required for corba ejb references.
> >>>
&= gt; >>>    david jencks
> >>>> >>>    On Apr 25, 2006, at 7:34 AM, Man= u George wrote:
> >>>
> >>>    > Hi,<= br>> >>>    >      = ;   I have a question regarding one of the objects
> present in
> &= gt;>>    > the current application local JNDI = Context. What is the
> >>>    > Handl= eDelegate entry for?
> >>>    >
> >>>    > Thanks
> >>&g= t;    > Manu
> >>>
> >>&g= t;
> >>>
> >>>
> >
> >
&= gt; >
> >
>


------=_Part_3063_18516355.1146118447025--