On Wed, 4 Dec 2002, maninder s batth wrote:
> Date: Wed, 04 Dec 2002 10:47:31 -0800 > From: maninder s batth <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Re: get JNDI Context from client side where??? > > could you pls gime page # in 2.3 servlet spec about enviroment context > documentation. > i would like to read whole but as of now i am focussed on jndi aspect of > tomcat. > thank you > You'll have to search long and hard to find it in the servlet spec :-). The JNDI naming context requirements come from the J2EE Platform Specification <http://java.sun.com/j2ee> chapter on Naming. Tomcat cannot implement all of these features (for example, it doesn't have any EJB support, so it cannot do much for an <ejb-ref>), but Tomcat does strive to implement the subset it can in a manner compatible with J2EE. That's why an app programmed to use JNDI resources for data sources, for example, should be able to run unchanged on any J2EE-based app server. On the particular feature you are speaking of, J2EE app servers are required to be able to expose *a* naming context to a J2EE app client which has been packaged with the appropriate support libraries for that app server. However, this naming context would not be the same context instance as for a web application stored in a server -- it would be one custom crafted for that app client, based on the app client's deployment descriptor. It would be technically feasible (although non-portable) to add a way that an external client (i.e. running in a separate JVM) could get access to a webapp's naming context, using CORBA or RMI. However, even if you went to all this work, it wouldn't do you very much good -- many of the resources stored in the webapp naming context, such as data sources, are not Serializable and could not be acquired and used from a separate JVM anyway. My advice would be to abandon the idea of trying to access the webapp's naming context from an external application. If you need to have information that is shared between a webapp and standalone apps, the simplest thing to do is store it in a database that both of them access. If the data changes and you need synchronization, investigate things like JINI and JavaSpaces to maintain the coordination for you. Craig > Shapira, Yoav wrote: > > >Hi, > >The tomcat environment context is only bound within the tomcat JVM > >internally, as mandated by the 2.3 servlet spec. You shouldn't have > >direct access to it from an external source, like your client. And > >anyways, would you want your client to require the internal Catalina > >jars on its classpath? > > > >Yoav Shapira > >Millennium ChemInformatics > > > > > > > > > >>-----Original Message----- > >>From: Kevin Chen [mailto:[EMAIL PROTECTED]] > >>Sent: Wednesday, December 04, 2002 6:39 AM > >>To: [EMAIL PROTECTED] > >>Subject: get JNDI Context from client side > >> > >>Hi all: > >> > >>How can I get Tomcat JNDI context from client side?? > >>I wanna write a client side java code that can lookup Tomcat JNDI > >> > >> > >context. > > > > > >>Here is the code i wrote: > >> > >>Properties p = new Properties(); > >> p.put(Context.INITIAL_CONTEXT_FACTORY, > >>"org.apache.naming.java.javaURLContextFactory"); > >> p.put(Context.PROVIDER_URL, "rmi://localhost:1099"); > >> > >> try > >> { > >> Context ic = new javax.naming.InitialContext(p); > >> Object obj = ic.lookup("java:comp/env"); > >> ... > >> ... > >> } > >> > >> > >>And I got the following error message: > >>javax.naming.NameNotFoundException: No object bound for java:comp/env > >> > >>It seems like I didnt get the JNDI context of Tomcat. > >>Can anyone help?? > >> > >>Thanks!! > >> > >> > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > Your favorite stores, helpful shopping tools and great gift ideas. > Experience the convenience of buying online with Shop@Netscape! > http://shopnow.netscape.com/ > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>