Bob,
> 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?
>
We are using RMIClassLoaders to explicitly download the factory class from
the server if it is not already available on the client. This also allows us
to require only one piece of contact info for the server (which is the
string http URL of our class server). You have to use JNDI 1.1.2 (which is
1.1.1 compiled for Java 2) to work around the security policy issue while
instantiating the factory class.
Imre Kifor
Valto Systems
>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".
>
===========================================================================
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".
