ust 13, 2003 3:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Dynamic MBeans. Was: Kernel Architecture
>
>
> Hi,
>
> At least I'm in favour of model MBeans. They can be
described
> in XML (which I think is a good idea) and they can
have
> annotations. What does it say t
On Wednesday, August 13, 2003, at 03:19 pm, David Jencks wrote:
On Wednesday, August 13, 2003, at 08:06 AM, James Strachan wrote:
On Wednesday, August 13, 2003, at 05:15 am, David Jencks wrote:
On Tuesday, August 12, 2003, at 03:13 PM, Bordet, Simone wrote:
Hi,
Using model mbeans instead of stand
On Wednesday, August 13, 2003, at 08:06 AM, James Strachan wrote:
On Wednesday, August 13, 2003, at 05:15 am, David Jencks wrote:
On Tuesday, August 12, 2003, at 03:13 PM, Bordet, Simone wrote:
Hi,
Using model mbeans instead of standard mbeans has many
advantages.
Uhm, I admit to have little knowl
Title: RE: Dynamic MBeans. Was: Kernel Architecture
Does anyone other than me see the irony here? :)
>> [EMAIL PROTECTED]
Les Hazlewood
> -Original Message-
> From: Pasi Salminen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 13, 2003 3:36 AM
> To
On Wednesday, August 13, 2003, at 05:15 am, David Jencks wrote:
On Tuesday, August 12, 2003, at 03:13 PM, Bordet, Simone wrote:
Hi,
Using model mbeans instead of standard mbeans has many
advantages.
Uhm, I admit to have little knowledge of JBoss' XMBean, but what are
the real advantages of using
On Wednesday, Aug 13, 2003, at 08:35 Europe/London, Pasi Salminen wrote:
At least I'm in favour of model MBeans. They can be described in XML
(which I think is a good idea) and they can have annotations. What
does it say to an administrator if he can see an operation stop? For
us (being professi
Hi,
At least I'm in favour of model MBeans. They can be described in XML (which I
think is a good idea) and they can have annotations. What does it say to an
administrator if he can see an operation stop? For us (being professional J2EE
propeller heads) it may be obvious but
for an administrato
On Tuesday, August 12, 2003, at 03:13 PM, Bordet, Simone wrote:
Hi,
Using model mbeans instead of standard mbeans has many
advantages.
Uhm, I admit to have little knowledge of JBoss' XMBean, but what are
the real advantages of using ModelMBeans (and all the stuff they
carry) ?
-- you can deploy a
Another point worth to discuss is invocation performance: remember
that calling via JMX is waay slower than with reflection: the
MBeanServer must perform a lot of additional checks to ensure the JMX
specification is respected.
I think using it in the container invocation chain (which should
Hi,
> Using model mbeans instead of standard mbeans has many
> advantages.
Uhm, I admit to have little knowledge of JBoss' XMBean, but what are the real
advantages of using ModelMBeans (and all the stuff they carry) ?
I think it can be useful to have DescriptorAccessible MBean*Info, but once
Using model mbeans instead of standard mbeans has many advantages. As
I recall someone (Simone?) offered to write an xmbean model mbean for
mx4j. We can use the xdoclet JBoss xmbean template as a starting point
and generate the xml descriptor from the source.
For now we can generate standard
On 8/12/03 06:10 PM Berin Loritsch <[EMAIL PROTECTED]> wrote:
> Jens Schumann wrote:
>
>> I agree with you. However I still don't get the point why relying on JMX is
>> a critical factor, and usage of jakarta-commons* is considered harmful. JMX
>> is a specification and it is up to you to implemen
Jens Schumann wrote:
Von: Berin Loritsch <[EMAIL PROTECTED]>
Antworten an: [EMAIL PROTECTED]
Datum: Tue, 12 Aug 2003 11:39:44 -0400
An: [EMAIL PROTECTED]
Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
Jens Schumann wrote:
The thing is that there are certain compromises in the all-in-o
> Von: Berin Loritsch <[EMAIL PROTECTED]>
> Antworten an: [EMAIL PROTECTED]
> Datum: Tue, 12 Aug 2003 11:39:44 -0400
> An: [EMAIL PROTECTED]
> Betreff: Re: Dynamic MBeans. Was: Kernel Architecture
>
> Jens Schumann wrote:
>
> The thing is that there are certain
Jens Schumann wrote:
MBean != interface, and we should never use them as such. By following that
mantra, dynamic MBeans becomes a viable tool with few drawbacks.
Well, this is true if you talk about the instrumentation level only. But if
you trust in JMX agents for application management you are
> Von: Berin Loritsch <[EMAIL PROTECTED]>
>
>
> Consider for a moment the purpose of MBeans. They are to allow a management
> console to control aspects of your software. So they were originally created
> to provide an end user a way to control the guts of software. They were not
> created to p
On Tuesday, Aug 12, 2003, at 14:42 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 02:17 pm, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan
wrote:
On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
But by creating (and calling
Jens Schumann wrote:
Von: Greg Wilkins <[EMAIL PROTECTED]>
Why can't we go for a totally dynamic MBean model?
Just a few thoughts:
- With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
introduced) you get meta data for SimpleMBeans.
- With dynamic Mbeans you loose your concrete in
James Strachan wrote:
Why can't we go for a totally dynamic MBean model?
We absolutely could. I was trying to just come up with a simple
convention component authors could follow - though we should be flexible.
Ie - for a given FooService, why do we need to write a FooServiceMBean
interface that
On Tuesday, Aug 12, 2003, at 14:20 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
But by creating (and calling) them MBeans, you are tying it down to
a naming convention expected by JMX which may confuse the issue
later.
Why? Whats confusing ab
On Tuesday, August 12, 2003, at 02:17 pm, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan
wrote:
On Tuesday, August 12, 2003,
> Von: Greg Wilkins <[EMAIL PROTECTED]>
>
>
> Why can't we go for a totally dynamic MBean model?
>
Just a few thoughts:
- With JMX 1.2 (maybe with 1.1, can't remember when SimpleMBeans where
introduced) you get meta data for SimpleMBeans.
- With dynamic Mbeans you loose your concrete interface
On Tuesday, August 12, 2003, at 02:07 pm, Greg Wilkins wrote:
James Strachan wrote:
An interface based MBean is just a naming convention. There is no
tying to anything. Indeed there's not even a dependency on JMX
never mind any other container API. Then the container is totally
free to go in wh
On Tuesday, Aug 12, 2003, at 14:07 Europe/London, Greg Wilkins wrote:
James Strachan wrote:
An interface based MBean is just a naming convention. There is no
tying to anything. Indeed there's not even a dependency on JMX
never mind any other container API. Then the container is totally
free to g
On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan
wrote:
On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson
wrote:
I like the sugge
James Strachan wrote:
An interface based MBean is just a naming convention. There is no
tying to anything. Indeed there's not even a dependency on JMX never
mind any other container API. Then the container is totally free to
go in whatever direction it wishes.
But by creating (and calling) the
On Tuesday, August 12, 2003, at 12:27 pm, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson
wrote:
I like the suggestion that even if we decide to go with the MBean
model, a
layer be creat
micro
kernel architectures too aren't they?
I can't say for Pico, but JMX is a management extension, not a kernel
architecture.
That doesn't mean you can't have a JMX based micro-kernel
So it couldn't really be called a micro kernel, no.
So you're saying JBoss, Tomcat, Jet
On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan wrote:
On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson wrote:
I like the suggestion that even if we decide to go with the MBean
model, a
layer be created, possibly via an interface so this software isn't
tightly
cou
I can't say for Pico, but JMX is a management extension, not a kernel
architecture. So it couldn't really be called a micro kernel, no.
Alex.
On Tuesday, August 12, 2003, at 11:36 am, James deGraft-Johnson wrote:
Hi,
I like the suggestion that even if we decide to go with the MBean
model, a
layer be created, possibly via an interface so this software isn't
tightly
coupled to MBeans.
An interface based MBean is just a naming convention
On Tuesday, August 12, 2003, at 11:06 am, Alex Blewitt wrote:
I'd recommend having separate pages for each type, rather than
everything in one page.
Its a wiki - just add pages :)
I'd also like to suggest that there are different groups of
architectures, such as a MicroKernel architecture (of wh
PROTECTED]
Sent: Tuesday, August 12, 2003 6:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Kernel Architecture (was [Re: JMX as a kernel ...])
I'd recommend having separate pages for each type, rather than
everything in one page.
I'd also like to suggest that there are different groups o
I'd recommend having separate pages for each type, rather than
everything in one page.
I'd also like to suggest that there are different groups of
architectures, such as a MicroKernel architecture (of which Avalon and
HiveMind may be examples).
Alex.
On Tuesday, Aug 12, 2003, at 12:58 Europe/L
-Original Message-
From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]
Sent: 12 August 2003 12:59
To: [EMAIL PROTECTED]
Subject: Kernel Architecture (was [Re: JMX as a kernel ...])
I've put the the skeleton of a new Wiki page to discuss the different
kernel solutions proposed. It w
I've put the the skeleton of a new Wiki page to discuss the different
kernel solutions proposed. It would be very helpful if supporters of
each solution could post a description (plain english please) as well
as pros and cons for any solution ... please add any solutions that
I've missed. This
36 matches
Mail list logo
