This is just what I am trying to do - publish to LDAP. The only
problem is that I can't tell my server to publish to LDAP. Some
servers publish to the local RMI registry, some to their own
proprietary (albeit JNDI compliant) naming service.
Since I haven't the control over the server, I must publish via
the bean itself.
Even if server X allows specification of the JNDI service and
location to use, server Y does not. How do we bring them
together?
Having a solution that only works with one vendor is not my
idea of open systems. If I wanted that I'd just use ActiveX.
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: Richard Monson-Haefel
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 16, 1999 12:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Bean access to server info
This idea of publishing the beans held by an EJB server on
another service
sounds a lot like the CORBA Trader service.
The problem I've always seen with this solution, is that it
is simply a
mechanism of indirection. You still need to know were the
service is and
find it directly. It may limit the number of Internet
addresses and/or
naming bindings you need to deal with but it is not location
transparent.
A JNDI driver may provide this type of global service. LDAP
implementations
come to mind. In addition to providing a naming service LDAP
is also a
directory service. This means you can do searching on the a
entries by
properties. List all the color printers in building A or
list all the beans
that provide access to employee data.
Richard
-----Original Message-----
From: Bob Pecor
To: [EMAIL PROTECTED]
Sent: 3/16/99 10:42 AM
Subject: Re: Bean access to server info
Still, these are all work-arounds for the fundamental
problem:
EJB provides no way to get info about the container or
server
at bean class initialization time. There is some context
info
available to a bean instance, but this doesn't help.
Richard, I had in fact already implement just what you
suggested but as you say, "ugly, ugly, ugly."
This is actually part of a larger problem concerning object
location transparency. How does a client use the object if
neither the server nor object class publicizes its location.
I realize that the location is published via to a local
service but the problem of finding hosts on the network that
may serve up the required object is problematic: either you
know a priori where an object is or you are out of luck.
If, however, the Bean class (or better yet the EJB server)
were able to publish the location of the bean to a
well-known
service (that by convention all clients would query) we
might
get a step closer to "object location transparency" since
the
object lookup code could be written once (robustly) and used
by clients.
Just an idea:-)
Bob
Bob Pecor
Vanguard Cellular Systems, Inc.
336.286.1742 (Voice) 336.286.1881 (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Constantine Plotnikov
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 16, 1999 10:53 AM
To: [EMAIL PROTECTED]
Subject: Re: Bean access to server info
Hi!
Another variant is to have an object on JNDI or
RMINaming which
contains
properties needed for you object and just lookup it
and use. The
only
property you will need is where to get the object.
You can also initialize settengs from plain text
read from some
URL.
The problem is that it is unspecified if how you can
add object
to
JNDI
namespace before use of any related object. I think
that we
maybe
need
something like "EJB Service deployment descriptor"
for protable
way
of doing things like this.
Constantine
Rickard ?berg wrote:
>
> Hey
>
> Bob Pecor wrote:
> > I understand that I could manually put the info
I want in a
number
> > of places but that is not an
implementation-independent
> > approach: if I change vendors I must change the
hard-coded
> > info. I would rather "discover" the info
dynamically at
class
> > initialization time.
>
> I understand, and agree. A workaround would be to
create a
number
of
> properties-files which contains the various info
for the
servers
that
> the EJB:s could be deployed with. Upon runtime you
could try
them
out in
> sequence to determine which is the right one.
(ugly ugly ugly,
but
might
> actually work and requires less work than manual
hardcoding).
>
> /Rickard
>
> --
> Rickard ?berg
>
> Computer Science student@LiTH
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
>
========================================================================
===
> 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".
