Rickard,
            I am using J2EE server for testing purposes.In case of using a
stateful/less session bean,I am just leaving the InitialContext()
constructor blank and in the context instance's lookup,all I am mentioning
is the jndi name which I mentioned in the server's console.That's that.!! I
am not using system properties' object to access my directory services.But
the server is sending a jar file to the client which contains stub
classes,thru which the bean can be accessed.Tell me if this is done can we
simply avoid passing system props obj into initialcontext()?

rgds,
shankar

> -----Original Message-----
> From: Rickard �berg [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 1:27 PM
> To:   [EMAIL PROTECTED]
> Subject:      Re: InitialContext
>
> Hi!
>
> sven wrote:
> > I'm currently having a training for Weblogic and am having a discussion
> =
> > with my instructor on obtaining the initial context. I've been using =
> > Orion for a while and have some experience with IAS.
> >
> > In my opinion, the weblogic way of obtaining the InitialContext using =
> > the InitialContext(Properties env) constructor is non-portable since =
> > deployment on any other Application Server would mean I have to =
> > recompile my EJB=B4s and client classes to point to the proper =
> > InitialContextFactory and Context.provider.URL. Both Orion and IAS allow
> =
> > to create the initial context using the no-arguments constructor.
> >
> > Am I reading the specs wrong?
>
> There are three ways to provide InitialContext settings:
> 1) Through System properties
> 2) By adding a file called jndi.properties to classpath which contains
> these settings
> 3) By using the InitialContext(Properties) constructor
>
> In case 3) you can either
> a) hardcode (which is done by most examples. Terrible)
> b) softcode by placing properties in a properties file
>
> For 3b (flexible yet dynamic) I suggest the following. Place JNDI
> properties for server X that you want to connect to in x.properties.
> Then load them in your program by doing:
> Properties env = new Properties();
> env.load(getClass().getResourceAsStream("/x.properties"));
> Context xContext = new InitialContext(env);
>
> This will allow you to keep settings in text files, and still be able to
> direct your client to many servers (simply have one properties file per
> server you want to connect to).
>
> If you only have one server that your client should connect to, use 1 or
> 2. And 1) can also be done with the above code:
> System.getProperties().load(getClass().getResourceAsStream("/system.proper
> ties"));
> So, by placing your additional system properties in "system.properties"
> you avoid having to use the -D JVM flag or hardcoding them.
>
> HTH,
>   Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to