[Forwarding to the list. %#¤%& missing Reply-To: header]
Original Message
Subject: Re: [JBoss-dev] JMX service architecture: next gen++ [davidje
[EMAIL PROTECTED]]
Date: Wed, 03 Oct 2001 22:15:28 +0200
From: Ole Husgaard <[EMAIL PROTECTED]>
Organization: Sparre S
esn't have to remember to do the copy - it just happens. I imagine this
> is
> why the model of a database that just does it, is appealing.
>
> Cheers
>
> -Original Message-
> From: David Jencks
> To: jboss-dev
> Sent: 10/2/01 6:38 PM
> Subject: Fwd: Re: [
l of a database that just does it, is appealing.
Cheers
-Original Message-
From: David Jencks
To: jboss-dev
Sent: 10/2/01 6:38 PM
Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++
[[EMAIL PROTECTED]]
(Maybe this time I will get this to the list-third try is the charm?)
O
(Maybe this time I will get this to the list-third try is the charm?)
On 2001.10.02 15:07:05 -0400 David Jencks wrote:
(forwarding to list, hope this is ok with you)
This is exactly what I was thinking, and what the firebird-style versioning
does for you.
I am not suggesting storing much of any
|momentary service disruptions. Also, you don't want half-completed
|configuration changes to start getting used - you want them to finish
|first. I'm just saying this point of view on requirements (if they are
Yes, the transactional nature of the distributed administration operation
might be r
Don't panic marc, even I don't plan to implement this this week ;-)
Here's the context I'm thinking about, and please note IANASA (I am not a
system administrator)... but if I were running the jboss cluster at
Megacorp Conglomerates, I expect my audit trail requirements would include
knowing exac
Definitely a much simpler idea to just build the new stack and replace the
old one atomically than to try and build a database for the MBeans.
Cheers
-Original Message-
From: Rickard Öberg
To: [EMAIL PROTECTED]
Sent: 10/2/01 12:33 PM
Subject: Re: [JBoss-dev] JMX service architecture
"Rickard Öberg" wrote:
>
> Hiram Chirino wrote:
>
> > Since it seems like the configuration would define a static stack of
> > interceptors, MGMT could build a java.util.Stack containing the
> > interceptors and pass that down. Avoiding the delegation back to it.
>
> Yes, pass it down along wi
|I would like this best if the jmx server state were transactional with
|versioning optimistic concurrency control, like the firebird/interbase db.
|In this kind of scheme, an invocation to a mbean would get a jmx
|"transactional" view of all the mbeans in the jmx server as of the start of
|the i
David Jencks wrote:
> I would like this best if the jmx server state were transactional with
> versioning optimistic concurrency control, like the firebird/interbase db.
> In this kind of scheme, an invocation to a mbean would get a jmx
> "transactional" view of all the mbeans in the jmx server
On 2001.10.02 11:18:00 -0400 Rickard Öberg wrote:
> marc fleury wrote:
>
> > |So many MI's would be sharing the same list, but with different
> indices
> > |into it.
> >
> > right that is even better the only state that is in the MI is the index
> and
> > a (static) reference to the type of flow
|It is indeed (and I would not want to get credit for this idea. You
Don't want to take credit for your own ideas? my god, you are ready for the
space program kid, the man in black will be coming for you soon.
|already said it, you just didn't know it :-).
yeah...
|You get around this by using
Vinay Menon wrote:
> What if an interceptor in the stack has a call back to a previous
> interceptor that was removed as a result of the update? Maintain multiple
> version of the stack until all old references complete?
I think the point is that you never change a stack. Only replace them.
S
IL PROTECTED]>
Sent: Tuesday, October 02, 2001 3:20 PM
Subject: Re: [JBoss-dev] JMX service architecture: next gen++
> marc fleury wrote:
>
> > a stack of ObjectNames and in each "message interceptor mbean" there is
a
> >
> > ObjectName name = message
marc fleury wrote:
> |So many MI's would be sharing the same list, but with different indices
> |into it.
>
> right that is even better the only state that is in the MI is the index and
> a (static) reference to the type of flow he will see (ejb), pretty cool
> rickard.
It is indeed (and I wou
then you are on top of it David?
go ahead kid!
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Jencks
|Sent: Tuesday, October 02, 2001 11:13 AM
|To: jboss-dev
|Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++
|[[EMAIL
|So many MI's would be sharing the same list, but with different indices
|into it.
right that is even better the only state that is in the MI is the index and
a (static) reference to the type of flow he will see (ejb), pretty cool
rickard.
|Updating the list would be to simply replace it at the
Grr, can someone set the reply to back to the list? I sent this originally
just to Rickard. I'm reposting because of the comments about mbean config:
lots of people suggested the iterator by now.
On 2001.10.02 10:09:01 -0400 David Jencks wrote:
I'm not sure if this is the same as what you guys
marc fleury wrote:
> a stack of ObjectNames and in each "message interceptor mbean" there is a
>
> ObjectName name = message.getNextInterceptorInStack();
> server.invoke(name, mi) // equivalent dynamic invocation
> ...
>
> whatever there are tons of ways to do that (maybe self contained in MI)
|Let's see if I understand this right. Do you send the list of
|interceptors as part of the MI? I.e. the list contains the MI and an
|index, and each interceptor just increases the index and delegates to
|the next? Or how is the stack controlled? What is the driver of the
|interceptor delegation?
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Tuesday, October 02, 2001 9:15 AM
|To: Rickard Öberg; [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] JMX service architecture: next gen++
|
|
||Well, the only thing the incoming gates
(Seems like the lists need to change the reply-to. it's to the sender
and not the list)
Hiram Chirino wrote:
> Since it seems like the configuration would define a static stack of
> interceptors, MGMT could build a java.util.Stack containing the
> interceptors and pass that down. Avoiding th
For logging purposes ;)
need...early... coffee.
marcf
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Tuesday, October 02, 2001 9:13 AM
|To: Rickard Öberg
|Subject: RE: [JBoss-dev] JMX service architecture: next gen++
|
|
||It should be. So then you will
marc fleury wrote:
> |Well, the only thing the incoming gates would have to know is to
> |immediately delegate to the stack configuration MBean. After that it can
> |take care of the stack config.
> |
> |*But this will only work if the interceptor/config interleaving is done
> |as outlined in pre
>From: Rickard Öberg <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [Fwd: [JBoss-dev] JMX service architecture: next gen++]
>Date: Tue, 02 Oct 2001 10:07:23 +0200
>
>Example: MBean XYZ wants the interceptor chain A,B,C (where C handles the
>call). Somehow th
|Well, the only thing the incoming gates would have to know is to
|immediately delegate to the stack configuration MBean. After that it can
|take care of the stack config.
|
|*But this will only work if the interceptor/config interleaving is done
|as outlined in previous post*. Otherwise it will b
09:57
>An: marc fleury
>Betreff: Re: [JBoss-dev] JMX service architecture: next gen++
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Wrong reply-to.. here it is.
--- Begin Message ---
marc fleury wrote:
> |I'll rephrase myself. Interceptors could be done as a series of JMX
> |MBeans implementing DynamicMBean, i.e. they don't do anything with the
> |call except delegate to other DynamicMBeans, with the last one actually
> |do
marc fleury wrote:
> We would create the interceptors independently of each other. And then
> "creating a stack" is nothing more than instructing incoming gates (.net,
> rmi, whatever) that the messages requesting "EJB-style" fielding should go
> through this stack of ObjectName interceptors. s
|However, if you put
|the interceptors in the bus you then have two ways of writing
|components: as MBeans and as JMX server interceptor plugins.
|
|Any thoughts on that?
The price you pay for the invocation "on the bus" on the bus isn't
significant. Therefore the advantage of the MBean approac
|I'll rephrase myself. Interceptors could be done as a series of JMX
|MBeans implementing DynamicMBean, i.e. they don't do anything with the
|call except delegate to other DynamicMBeans, with the last one actually
|doing something. This would work, and it would make it simple to
|configure each in
marc fleury wrote:
> the ejb behavior is implemented in the actual linked list of interceptors
> that we put there, exactly what we do today from the ContainerFactory but
> completely and **genericaly** at the JMX layer. Building the EJB will be
> nothing more than passing standardjboss.xml topo
|Yes, if the EJB's are exposed as MBeans it is more of a special case
|than anything else. (And not so special anyway, which is the whole point)
exactly, EJB's are not special from the container (JMX) point of view they
use
remoteness
indirection
invocation
just as any other mbean
the ejb beha
marc fleury wrote:
> Well the more I think about what we are doing and the more I see the future
> of the webOS starting with the management of modules invocation stacks that
> are put in it. This is the magic of the detyped invocation chains it allows
> for arbitrary stacks of interceptors, even
|>Either that or you control the JMX infrastructure, a JMX server that
|>includes the externalization of stacks of JBoss would do just that.
|
|That's true. So, you want to replace the RI then?
Well the more I think about what we are doing and the more I see the future
of the webOS starting with
>|>You just mean that "invoke()" is a more natural way to String together
>|>detyped services but you could argue that for the price of putting the
>|>Dynamic Proxies right behind the standard MBean interface you can
generate
>|>the same invoke() call and thus string a stack behind it.
>|
>|You ca
|>You just mean that "invoke()" is a more natural way to String together
|>detyped services but you could argue that for the price of putting the
|>Dynamic Proxies right behind the standard MBean interface you can generate
|>the same invoke() call and thus string a stack behind it.
|
|You can only
>|Implementation model
>|
>|Let's start with the basics. The JMX MBeans in JBoss are all based upon
>|the Standard MBean model. This has worked well, and is especially a very
>|lightweight and simple way to make components manageable. The downside
>|is that you can't add very i
38 matches
Mail list logo
