> And, no Marc, this isn't relegated to just JMX as Bill
> demonstrates with AOP Remoting. This should be used for JMS,
> EJB and all the other subsystem layers. ;)
That is great, the AOP remoting part is the future. But the best of
this will come as the invoker layer for proxies of EJB (
Scott M Stark eloquently wrote the following on 1/6/2004 1:44 PM:
The MBeanTracker appears to be a composite of the proxy factory and
lookup
services currently used and is where the NAT configuration would have to
be I would guess. Does this layer support:
- A client side interceptor stack
- Speci
]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 7:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Remoting and NAT traversal, advanced network
In the remoting framework, there are three main components: a transport,
a detector and a network registry. (among others
Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT traversal, advanced network
We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic /
.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT traversal
We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic / NAT traversals for remoting
either in detection or transport. We basically send the local machines
address (which bind
