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 equivelant object
represenations 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".
