You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/08/13 07:35:11 UTC
MBean suffixed classes
Huw, Peter, Folks,
I have to say I dislike the MBean suffix for JMX enabled beans. In fact
it is my principle objection to JMX (yes I know it is anal).
Would it be possible to generate them?
Consider that a simple Service could be :
interface MyThing {
/** @phoenix:manage-me */
void hello();
}
And its class could be :
class MyThingImpl implements MyImpl, Startable {
public MyThingImpl() {
}
public void start() {}
public void stop() {}
// etc.
}
Perhaps, we could use xdoclet to make :
interface MyThingMBean {
void hello();
}
And :
class MyThingImplMBean extends MyThingImpl implements MyThingMBean {
}
Thus we could hide the MBean stuff. This could either be done as part
of the regular Ant compile target, or be done at runtime by Phoenix
using BCEL.
It would also be possible to model some nice things like a state machine
for blocks. For example start() and stop() hint at a state change. BCEL
could generate
class GeneratedBlockNNNN extends MyThingImpl {
boolean blockStarted;
public void start() {
super.start();
blockStarted = true;
}
public void stop() {
super.stop();
blockStarted = false;
}
public isStarted() {
return blockStarted;
}
}
It would be useful for the BeanShell enabled kernel which can traverse
objects without constraint.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: MBean suffixed classes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 13 Aug 2002 15:35, Paul Hammant wrote:
>
>>Huw, Peter, Folks,
>>
>>I have to say I dislike the MBean suffix for JMX enabled beans. In fact
>>it is my principle objection to JMX (yes I know it is anal).
>
>
> JMX does not require it - its just convention. What do you object to exactly -
> a separate interface or just the suffix. You can quite easily name the
> interface anything you want and phoenix will handle it gracefully.
>
> If it is the interface itselfyou don't like then it would seem I am the only
> one that likes em ;)
;-)
>>Would it be possible to generate them?
>
> yep. I believe many projects do.
Yes, they do, but please don't.
I strongly think that the code should never use a preprocessor, except
when it's part of the language semantics (template-based programming).
It's useless, anal and confusing.
Overall, I usually use very descriptive names for my stuff; it makes
them usually quite long, but I understand them better, ie if I have a
String that holds an URL, I call it something like
userDefinedTargetURLString. The last part is always about the behaviour
of the object.
So MBean for Mbeans is not so bad after all IMHO.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: MBean suffixed classes
Posted by Peter Donald <pe...@apache.org>.
On Tue, 13 Aug 2002 15:35, Paul Hammant wrote:
> Huw, Peter, Folks,
>
> I have to say I dislike the MBean suffix for JMX enabled beans. In fact
> it is my principle objection to JMX (yes I know it is anal).
JMX does not require it - its just convention. What do you object to exactly -
a separate interface or just the suffix. You can quite easily name the
interface anything you want and phoenix will handle it gracefully.
If it is the interface itselfyou don't like then it would seem I am the only
one that likes em ;)
> Would it be possible to generate them?
yep. I believe many projects do.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: MBean suffixed classes
Posted by Alexis Agahi <al...@users.sourceforge.net>.
Paul Hammant wrote:
> Huw, Peter, Folks,
>
> I have to say I dislike the MBean suffix for JMX enabled beans. In fact
> it is my principle objection to JMX (yes I know it is anal).
I agree
> Would it be possible to generate them?
>
> Consider that a simple Service could be :
>
> interface MyThing {
> /** @phoenix:manage-me */
> void hello();
> }
>
> And its class could be :
>
> class MyThingImpl implements MyImpl, Startable {
> public MyThingImpl() {
> }
> public void start() {}
> public void stop() {}
> // etc.
> }
>
> Perhaps, we could use xdoclet to make :
>
> interface MyThingMBean {
> void hello();
> }
>
> And :
>
> class MyThingImplMBean extends MyThingImpl implements MyThingMBean {
> }
>
> Thus we could hide the MBean stuff. This could either be done as part
> of the regular Ant compile target, or be done at runtime by Phoenix
> using BCEL.
Lets face it, java need a preprocessor ;)
remember, the good old #define 0 ;))
> It would also be possible to model some nice things like a state machine
> for blocks. For example start() and stop() hint at a state change. BCEL
> could generate
>
> class GeneratedBlockNNNN extends MyThingImpl {
> boolean blockStarted;
> public void start() {
> super.start();
> blockStarted = true;
> }
> public void stop() {
> super.stop();
> blockStarted = false;
> }
> public isStarted() {
> return blockStarted;
> }
> }
>
> It would be useful for the BeanShell enabled kernel which can traverse
> objects without constraint.
BCEL or ant are good.
Just to suggest another way, I would propose that a componant
could implement an interface, let say "Managable" that require a
method such as getManagedMethod() returning all managed method.
class MyThingImpl implements MyImpl, Managable {
void Hello(){
}
... getManagedMethod(){
something.add( ... "Hello"... )
return something;
}
}
so this could maybe validated at compile time.
Also some componant implementing some interface such as Startable
or Configurable (or whatever) could be managed "defacto".
As you suggested, Startable could have start/stop managed.
Configurable componant could have its configuration writable thru
JMX (ok this is not obvious considering the configuration hierarchy).
And so
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>