Exactly. That was the original idea. Both you and Richard
Monson-Haefel have mentioned similarity with the Corba Trader.
This idea is not nearly so ambitious.
There is no semantics associated with the "export" function
envisioned. A client would already know what object it required
but it wouldn't have to know exactly from what location it was
being served. As Richard pointed out, there is a level of
indirection but I disagree that this is a bad thing, since IMHO:
1) it is better to know one place to go to get info about object location
than to keep up with multiple locations
2) management of services is more flexible since servers
may be added and moved without having to modify
client code
3) the convention of looking in one place for object references
enables a generalization of initialization code, i.e., initial context
and home object creation.
4) this generalized code becomes an object factory that client
code utilizes thus abstracting "object location" issues from
client software coding
I'm finding though that there is an issue with the JNDI
InitialContextFactory code: how to get it? The factory code
is needed by the client to create the initial context but it may
not be resident on the client.
Any ideas?
Bob
Bob Pecor
Vanguard Cellular Systems, Inc.
336.286.1742 (Voice) 336.286.1881 (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Chris Raber [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 16, 1999 5:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Bean access to server info
I am with you on the idea.
As a compromise you could use LDAP to publish the
information similar to
your work around and as discussed below and
then use a two step process:
1. Looks up component attributes via LDAP using attributes
to filter to the
component you want (e.g. Trader)
2. Have the LDAP entry contain the strings or equivalent
object
representations as discussed below. Use that information to
lookup the bean
in the particular vendors JNDI registry...
-Chris.
> -----Original Message-----
> From: Bob Pecor [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 16, 1999 1:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean access to server info
>
> Yeah, I'm doing that currently as a work around
> but I would rather discover the info. See discussion
> in the rest of the thread.
>
> Thanks,
>
> Bob
>
> Bob Pecor
> Vanguard Cellular Systems, Inc.
> 336.286.1742 (Voice) 336.286.1881 (Fax)
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
> -----Original Message-----
> From: Chris Raber
[mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 16, 1999 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bean access to server
info
>
> The only restriction on what can be placed
in the
> Properties
> object accessed
> via a Bean's Context is that the key and
value objects are
> Strings. So for
> the scenario you outline, you could encode
the string to
> contain the
> necessary information. What one could do
is encode the
> key/value pairs into
> one string in the bean's properties,
something like:
>
> "key1=value1;key2=value2;key3=value3"...
>
> One would simply parse the one string and
build a
> Properties
> instance to us
> to get the initial JNDI context...
>
> -Chris.
>
>
>
> > -----Original Message-----
> > From: Bob Pecor [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 16, 1999 8:32 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Bean access to server
info
> >
> > Not enough info, Chris. The info needed
for the URL is
> the protocol and
> > port
> > (no problem with the host address). One
might also need
> the JNDI initial
> > context factory class name as another
attribute.
> >
> > The problem is that some vendors us the
RMI registry and
> some use their
> > own naming service. In the latter case
the initial
> context factory is
> > also
> > needed.
> >
> > Thanks,
> >
> > Bob
> >
> > Bob Pecor
> > Vanguard Cellular Systems, Inc.
> > 336.286.1742 (Voice) 336.286.1881 (Fax)
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >
> > -----Original
Message-----
> > From: Chris Raber
> [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March
15, 1999 6:03 PM
> > To:
[EMAIL PROTECTED]
> > Subject: Re: Bean
access to
> server
> info
> >
> > One option: Use the
properties
> information
> in the beans
> > deployment
> > descriptor...
> >
> > -Chris.
> >
> > > -----Original
Message-----
> > > From: Bob Pecor
[SMTP:[EMAIL PROTECTED]]
> > > Sent: Monday, March
15, 1999 2:52 PM
> > > To:
[EMAIL PROTECTED]
> > > Subject: Bean
access to server
> info
> > >
> > > How does an object (at
class
> initialization time)
> > determine details of the
> > > EJB Server serving it
up?
> > >
> > > I have an EJB that
would like to
> register itself with,
> > say, an LDAP server
> > > so potential clients
can
> > > use it. It needs to
build and store a
> URL as the
> > "remotelocation"
> > > attribute
> > > of the LDAP entry.
> > > How can the bean
determine this
> information in an
> > implementation
> > > independent
> > > manner?
> > >
> > > Any ideas?
> > >
> > > Thanks,
> > >
> > > Bob
> > >
> > > Bob Pecor
> > > Vanguard Cellular
Systems, Inc.
> > > 336.286.1742 (Voice)
336.286.1881
> (Fax)
> > > [EMAIL PROTECTED]
> <mailto:[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".
>
>
>
==========================================================================
> =
> 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".
===========================================================================
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".
