Chris,
I wonder if you could cite the specification you are referring
to. To the best of my knowledge, there is no specification that
states what you state. (The closest spec that I can think of is
the OMG's Interoperable Naming Service specification, which we
support, but do not mandate the use of, in our product.) I
understand that this behavior is found in some products. But I
should point out it is not the behavior found in other products.
For example, in our product you don't need to provide a host/port
to locate objects, whether those objects run locally or remotely.
AFAIK, both behaviors are compliant with J2EE 1.2.
IMO, in a well-designed distributed systems you should keep the
amount of hard-coded information to a minimum. Requiring that
you provide consistent host/post info to all clients seems like
a major headache!
P.S. IMO, whether you hard-code the info into your Java code,
or hard-code it into some properties and/or resource files and/or
shell scripts is not particularly relevant. Any which way, you
are having to hard-code information that is dynamic in nature,
and ought not to be hard-coded anywhere. The only difference
is the syntax and/or location of the hard-coding, typically.
-jkw
"Bono, Chris" wrote:
>
> Sven,
> Specifying the properties in the constructor of InitialContext is portable
> and necessary in cases when you are looking up a jndi resource from another
> machine. The no-args constructor will get you the context of the appserver
> you are running under. However if you needed to lookup a jndi resource on
> another machine, or you are a stand-alone client app that needs to lookup
> a jndi resource (such as an EJBHome), you will have to tell jndi what implementation
> to use and the location of the resource. (Context.INITIAL_CONTEXT_FACTORY and
> Context.PROVIDER_URL, respectively)
> If you are worried about hardcoding the values, don't hardcode them, make them
> data driven.
>
> Chris
>
> -----Original Message-----
> From: sven [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 19, 2000 2:58 PM
> To: [EMAIL PROTECTED]
> Subject: InitialContext
>
> 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?
>
> sven
>
> ===========================================================================
> 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".
