10, 2002 8:25 PM
Subject: RE: [JBoss-dev] JMX on the client side?
Hiram, I think you missed the point. Of course we could do this with
out requiring JMX; anything is possible. The point is if we agree that
JMX is always on the client side then entire system is simplified.
I guess
: Sunday, November 10, 2002 8:25 PM
Subject: RE: [JBoss-dev] JMX on the client side?
Hiram, I think you missed the point. Of course we could do this with
out requiring JMX; anything is possible. The point is if we
agree that
JMX is always on the client side then entire system
Holger Engels wrote:
Without even understanding, what the specifics of detyped invocation, ..
are, I _can_ say, that using the microkernel on the client side is the
way to go. It's aspect oriented programming, what the EJB spec is all
about (although most people seem to ignore it). Only the
+1. This all came about because I was thinking about client side caches
with server invalidation. Without the JMX kernel it is a pain because
we have invent a totally new architecture to handle server to client
invocations. If we have the kernel, we quickly prototype this by
reusing the
JMX on the client side and JBoss on the client side are two different
things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't
require the service deployer. If it does, that's another thing...
Agreed. All I am talking about is an MBean server. If someone wants
more
: RE: [JBoss-dev] JMX on the client side?
Scott,
Interesting.. Do you have this scoped in your mind yet? I mean, Jboss (I
hate how outlook fixes the b in jboss) currently uses JavaGroups,
which assumes a multicast-enabled network. When you get to true
peer-to-peer, you may have a double firewall
Hiram, I think you missed the point. Of course we could do this with
out requiring JMX; anything is possible. The point is if we agree that
JMX is always on the client side then entire system is simplified.
I guess the disconnect is happening right here. IMO JMX does not always
make
Let me give you my example of why I want it.
I worked over the trunk invoker so it would do distributed transactions.
This requires at least a source of xid's on the calling side, and
preferably a TransactionManager. Well, they are already there if the
calling side is a jboss instance. If it's
]On Behalf Of David
Jencks
Sent: Monday, November 11, 2002 12:45 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
Let me give you my example of why I want it.
I worked over the trunk invoker so it would do distributed transactions.
This requires at least a source
On Mon, 2002-11-11 at 07:13, Dain Sundstrom wrote:
Hiram Chirino wrote:
Hiram, I think you missed the point. Of course we could do this with
out requiring JMX; anything is possible. The point is if we agree that
JMX is always on the client side then entire system is simplified.
I guess
David,
I'm thinking of a minimal that is perhaps smaller than that. I think
that
the MBean API + proxies should be sufficient for many clients.
Currently setting up the sar deployer is done in the jboss startup code,
and the minimal jboss-service.xml is then read in. Without this, how do
Matt Munz wrote:
What's wrong with mbeanServer().registerMBean(mmb, name) ?
Thank you matt. That is exactly what I am thinking.
The first time you lookup an EJB or JMS connection, we we lazily force
the client side to have an MBeanServer. Then we register only the
mbeans required to
On 2002.11.09 12:10:20 -0500 Dain Sundstrom wrote:
Matt Munz wrote:
What's wrong with mbeanServer().registerMBean(mmb, name) ?
Thank you matt. That is exactly what I am thinking.
The first time you lookup an EJB or JMS connection, we we lazily force
the client side to have an
, LLC
- Original Message -
From: Dain Sundstrom [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 09, 2002 9:10 AM
Subject: Re: [JBoss-dev] JMX on the client side?
Matt Munz wrote:
What's wrong with mbeanServer().registerMBean(mmb, name
-Original Message-
From: Scott M Stark [mailto:scottmstark;attbi.com]
Sent: Saturday, November 09, 2002 12:54 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
A JMX microkernel on the client is an avenue to explore. The
focus should be extending the current
David Jencks wrote:
Agreed. All I am talking about is an MBean server. If someone wants
more JBoss services on the client side they can do that, but it
shouldn't be required.
Conceptually I like this, but...
Are you thinking that these mbeans won't have any attributes? Or do you
plan to
Interesting.. Are you guys talking about a small JMX container on the
client invoker side? Or something else?
-Original Message-
From: David Jencks [mailto:davidjencks;directvinternet.com]
Sent: Thursday, November 07, 2002 10:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX
: [JBoss-dev] JMX on the client side?
+1000
This will greatly simplify many things, such as the trunk
invoker client.
I'd like to suggest that we also consider basing
UserTransaction on a transaction manager instance on the
client: this would allow UserTransaction to use the same
propagation
, 2002 10:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
+1000
This will greatly simplify many things, such as the trunk
invoker client.
I'd like to suggest that we also consider basing
UserTransaction on a transaction manager instance on the
client
end up with 2 kernels in the same VM? Just a thought..
This would rock!
James
-Original Message-
From: Dain Sundstrom [mailto:dain;daingroup.com]
Sent: Friday, November 08, 2002 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
Yes that is exactly what I
]On Behalf Of Dain
Sundstrom
Sent: Friday, November 08, 2002 3:29 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
Yep, these are the technical issues. We should be able to code around
them, but it may be challenging. I am really interested in what
everyone else thinks
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
+1000
This will greatly simplify many things, such as the trunk
invoker client.
I'd like to suggest that we also consider basing
UserTransaction on a transaction manager instance on the client:
this would allow UserTransaction
Matt Munz wrote:
Is this a good idea? Should we look at it for 4.0?
Great idea, Dain. Once you get that far, building client container
functionality should be pretty simple...
It makes sense to me. The closer a client environment models the server,
the better, IMO. Of course, the client
I think James had more esoteric plans...
-danch
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service arch kernel. Imagine a
world where jboss is installed everywhere - client and server. ;)
James
: RE: [JBoss-dev] JMX on the client side?
I think James had more esoteric plans...
-danch
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service arch kernel. Imagine a
world where jboss is installed everywhere - client and server
:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JMX on the client side?
I think James had more esoteric plans...
-danch
Right.. I'm not talking about Jboss proper, I'm speaking of a
rich client platform that uses jboss as its service arch
kernel. Imagine a world where
On Fri, 8 Nov 2002, James Higginbotham wrote:
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service arch kernel. Imagine a
world where jboss is installed everywhere - client and server. ;)
JBoss Unlimited.
JBoss Unleashed.
Infinite
JBoss Unlimited.
JBoss Unleashed.
Infinite JBoss.
This is the kind of thing that makes suits giddy with joy.
Right! Or:
JBoss Web Service Platform
JBoss: Web Service Edition
JBossXML
In fact, if you change the tagline from WebOS to WebServiceOS, you can
charge more consulting bucks on
Sent: Friday, November 08, 2002 4:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JMX on the client side?
I think James had more esoteric plans...
-danch
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service arch kernel
David,
Hard to know. We do have the minimal jboss configuration, which is a good
starting place: as I recall basically all it can do is deploy .sars.
AFAIK
I'm thinking of a minimal that is perhaps smaller than that. I think that
the MBean API + proxies should be sufficient for many clients.
On 2002.11.08 23:33:50 -0500 Matt Munz wrote:
David,
Hard to know. We do have the minimal jboss configuration, which is a
good
starting place: as I recall basically all it can do is deploy .sars.
AFAIK
I'm thinking of a minimal that is perhaps smaller than that. I think
that
the
Why don't we require jmx on the client side?
I bet it takes almost no memory and it has a small jar size. If do
require it on the client side, we can reuse all the services we are
building on the server, like a jcache mbean. It would also simply
server to client messages, which will be used
+1000
This will greatly simplify many things, such as the trunk invoker client.
I'd like to suggest that we also consider basing UserTransaction on a
transaction manager instance on the client: this would allow
UserTransaction to use the same propagation mechanism as distributed
transactions
33 matches
Mail list logo
