Resending due to my messed up sendmail config...

----------  Forwarded Message  ----------

Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
Date: Mon, 13 May 2002 19:58:16 +0000
From: Jason Dillon <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTED]>, 
<[EMAIL PROTECTED]>

> Because otherwise no client can find the JMX RMI-Adapter except for the
> local client.

Under what circumstances would more than one adapter be bound into JNDI?

> Aggreed that is a problem. The reason to do so is that I wanted a way to
> bind
> multiple JMX-RMI Adaptor on the JNDI server.
> The REAL problem pops up when we have two JVMs with a JMX RMI Adaptor
> running !!!

How and when is this a problem?  The two servers will be sharing a JNDI
 server then?  When does this happen and who uses JBoss in this fashion.  It
 seems like there might be more snags than just the placement of the RMI
 adapter.

> > Assuming that deployer.sh did make up a Context.URL from --server (which
>
> it does
>
> > not) this would not work due to a lookup failure, as there will be no
> > "jmx:www.mydomain.com:rmi" bound.
>
> The client is supposed to look up the right JNDI name but I created a
> pattern he
> can easier guess the right name.

Ic.  I was confused because the javadoc mention that this is done because of
the JMX spec (hence the first part of my mail wanting to know what the spec
was).

If that is the case and there is no spec then we should default to a scheme
which is easier for us to work with and which will be acceptable for most of
our users.  For the small subset that need RMI Adapters bound into JNDI for
more than one server we can let them decide how to arrange them by making the
name bound under configurable (as it is currently hard coded to this pattern
with the local hostname).

> > The point is that we can not reliably use any resolvable address.
>
> As I said the bigger problem is with two JVMs.

Yes but again, what percentage of our users will be running two vms with one
JNDI server?  Why are you designing for the few and complicating the usage of
the many?

> The current spec. says nothing and the current JNDI name was my idea. We
> could
> add a second name called "jmx:localhost:rmi" which does not help when we
> have
> 2 JVMs. Assuming that the JNDI server is running on another box this name
> has
> not meaning anymore.

Why don't we just drop the hostname stuff and use a generic mapping?  If some
clients want to bind the adapters of multipule remote servers into their
JNDI, and the spec says nothing about how this should be done, then the
location will be specific to that application.  Any attempt for use to
organize this for them will only result in added complexity for the clients
configuration... take the topic/ and queue/ hardcoded prefixes for JMS as an
example.

If the spec does not say how we should do this, then lets make it
 configurable so the user can decide how it should work then use defaults
 which place these objects in generic locations so that our tools and get at
 them.

--jason

-------------------------------------------------------

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to