Re: [JBoss-dev] JMX on the client side?

[Michael Bartmann]

In my company we have the requirement for client pcs doing
accounting in production environments. They could sample their
data to a local jboss server with a hypersonic db and an
message driven data synchronization mechanism.

Some months ago somebody posted on jboss-dev about his success
starting even the swing dialogs as mbeans under 3.0.

I think that even a normal swing gui client is as ressource
consuming as a small jboss server installation "out of the box",
so this should not be a problem for most of our use cases.

Isn't "a jboss for every client" the ultimate HA environment?

Regards,
Michael Bartmann
www.4production.de

Dain Sundstrom wrote:

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. Is this a good idea? Should we look at it for 4.0?

-dain

James Higginbotham wrote:

That would be interesting. I've really wanted to put together a rich
client framework using jboss as the kernel for adding services and
hotdeploying client functionality, but haven't had the time. Just
something to think about: what happens if you do this and I want my app
to start a kernel - what sort of classloader implications are there -
could I 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 am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day.

-dain

James Higginbotham wrote:

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 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 mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult.

david jencks

On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote:

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 for cache

invalidations

and jms messages. This is because we can reuse the invoker
architecture. There will still be a problem with socket

back channels

to clients on the other side of a firewall, but we would

get a ton of

reuse and simplification.

-dain



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!

http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list

[EMAIL PROTECTED]

https://lists.sourceforge.net/lists/listinfo/jboss-development


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

--
xxxxxxxxxxxxxxxxxxxxxxxx
Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development