You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/03 22:39:52 UTC
Baxter VS Modeler (was Re: How do we use Baxter?)
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>Take a look at phoenix, which integrates it. You can run it
>>with the option '-manager' and this will give you the http
>>interface (I think, dunno whether the setup has changed
>>recently). Also see recent threads on phoenix-dev; a GUI
>>client is in the works.
>>
>>I suspect by the time your book is published the GUI will be
>>something that is easy enough to install and look at for end users.
>>
>>IMO (and the O of some others), all you want to do is declare
>>"export this for management" in some policy file and then
>>have all the JMX stuff handled for you automagically.
I've been recently been contacted privately about Baxter in the
scope of the Avalon->Commons repositioning of some Excalibur packages.
I don't know a zip about it (yet), but it seems to overlap somehow with
Modeler http://jakarta.apache.org/commons/modeler.html
Any advice?
--
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: Baxter VS Modeler (was Re: How do we use Baxter?)
Posted by Leo Simons <le...@apache.org>.
> > I don't know a zip about it (yet), but it seems to overlap somehow with
> > Modeler http://jakarta.apache.org/commons/modeler.html
> >
> > Any advice?
>
> They are probably very similar. Baxter deals with DynamicMBeans atm rather
> than ModelMBeans but will deal with ModelMBeans when we end up moving Huws
> work back into it.
my understanding as well.
IMO, priority is getting JMX support within phoenix working like we want
it to. When we do that (Huw, Peter et al are doing nice things), we
probably want to look into merging with existing efforts.
The thing is that there will probably always be parts specific to
avalon. If an avalon component provides an initialize() methods, we can
tie meaning to it that modeller can't (as it is not avalon-specific).
So baxter will stay; it could probably be refactored to work with
modeller though.
Modeller seems stable now and the docs are neat so who knows....
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Baxter VS Modeler (was Re: How do we use Baxter?)
Posted by Peter Donald <pe...@apache.org>.
On Sun, 4 Aug 2002 06:39, Nicola Ken Barozzi wrote:
> >>From: Leo Simons [mailto:leosimons@apache.org]
> >>
> >>Take a look at phoenix, which integrates it. You can run it
> >>with the option '-manager' and this will give you the http
> >>interface (I think, dunno whether the setup has changed
> >>recently). Also see recent threads on phoenix-dev; a GUI
> >>client is in the works.
> >>
> >>I suspect by the time your book is published the GUI will be
> >>something that is easy enough to install and look at for end users.
> >>
> >>IMO (and the O of some others), all you want to do is declare
> >>"export this for management" in some policy file and then
> >>have all the JMX stuff handled for you automagically.
>
> I've been recently been contacted privately about Baxter in the
> scope of the Avalon->Commons repositioning of some Excalibur packages.
>
> I don't know a zip about it (yet), but it seems to overlap somehow with
> Modeler http://jakarta.apache.org/commons/modeler.html
>
> Any advice?
They are probably very similar. Baxter deals with DynamicMBeans atm rather
than ModelMBeans but will deal with ModelMBeans when we end up moving Huws
work back into it.
However I haven't looked at Modeller properly (at all) yet, will try to do so
some time soon.
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>