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 notati
ge -
> From: "Hiram Chirino" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: 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
CTED]>
Sent: 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 th
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.
> >
forge.net]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 tran
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 the disconnect is happening right here. IMO JMX does not
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
>
> 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 t
Hiram Chirino wrote:
What I would like to know, is: what are the features that JMX provides that
you need on the client side??
(1) Is it the interceptor architecture built around JMX?
(2) Is it the ability to look up other services via JMX?
I want to know because I think that we can provide clien
November 09, 2002 12:00 PM
Subject: 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 tru
> > > 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 wa
> +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
Scott M Stark wrote:
> A JMX microkernel on the client is an avenue to explore. The focus
> should be extending the current dynamic proxy and detached invokers
> to a kernel for peer-peer type of computing: agents, grid computing,
> JMS, RMI callbacks, distributed caches, and whatever P2P is going
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 se
ou must be envisioning more?
James
> -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
, 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 m
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 MB
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 service
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, h
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
> th
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
#x27;s idea right?
Any other ideas?
thanks
david jencks
> :) ...
>
> - Matt
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of James
> Higginbotham
> Sent: Friday, November 08, 2002 4:42 PM
> T
> 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
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
ay, 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
&
riday, 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 ar
> 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
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 s
: 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 i
ent-admin@;lists.sourceforge.net]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
ever
-
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 ex
;-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?
> >>
> >>
> >
: [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
propag
ect: 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
+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 (shi
35 matches
Mail list logo
