You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by James Strachan <ja...@gmail.com> on 2013/01/25 10:59:39 UTC

[ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

For the impatient just look here :) http://hawt.io/

Background
==========
We've had numerous consoles all over the place for some time in
various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
Fabric to name but a few. Many of them quite heavy weight requiring a
custom web app to be deployed (which often is quite large); none
particularly working together.

We've been working on Fuse Fabric and its management console to
provide a more consolidated view of a cluster of Apache integration &
middleware technologies. Increasingly we're seeing our users and
customers using different combinations of technologies in different
containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
Karaf + ActiveMQ + Camel or whatever).

So for a few months a few of us have been working on trying to make
the various web consoles for things like Apache Camel, ActiveMQ,
Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
& OSGi) available as lightweight HTML5 plugins so they can be mixed
and matched together to suite any container and combination of
technologies that folks deploy in a JVM.


hawtio
=====
The result so far is hawtio: http://hawt.io/

You can deploy it as a WAR in any JVM (or feature in karaf) and it
provides a UI console for whatever it finds in the JVM. So it works
with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
way.

The nice thing is its pretty small (about 1Mb WAR containing all the
server side code, HTML, JS, images, CSS etc). The only real server
side component is jolokia which is a small (about 300K) REST connector
for JMX (which is awesome BTW!) - the rest is static content (which
could be served from anywhere so doesn't need to be deployed in each
JVM).

Its based around a plugin architecture:
http://hawt.io/developers/plugins.html

so its easy to add new plugins for any kind of technology. A plugin is
pretty much anything that runs in a browser.

The nice thing is hawtio can discover UI plugins at runtime by
examining the contents of the JVM or querying REST endpoints; so the
UI can update in real time as you deploy new things into a JVM!


hawtio, the hawt camel rider
======================
A quick summary of the current features for camel folks:

* If you have any camel contexts running in a JVM when hawtio starts
up it adds an Integration tab which shows all the camel contexts
running.

* You can start/stop/suspend/resume the context and its routes; then
look at all the metrics for routes/endpoints/processors. The Charts
tab lets you visualise the real time metrics.

* You can create new endpoints; browse endpoints which are browsable &
send messages to endpoints (with syntax editing support for JSON / XML
/ YAML / properties)

* You can visualise all the camel routes or a specific camel route for
a context in the Diagram tab and see real time metrics of how many
messages are passing through each step on the diagram. e.g.
https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png

* Clicking on a Route allows you to Trace it; when tracing if you send
a message into a route then it captures a copy of the message at each
point through the route. So you can step through (scroll/click through
the table) a route and see the message contents and how the message
flows through the EIPs - highlighting where on the diagram each
message is. This is very handy for figuring out why your route doesn't
work :) Spot where the heading disappears! Or see why the CBR doesn't
go where you expected.

In general most of the runtime features of the open source Fuse IDE
eclipse tooling are now supported in the camel hawtio plugin; so
available in a web browser.


Summary
=======
So if you're vaguely interested in web consoles for Apache Camel I
urge you to give it a try. We love contributions and feedback!
http://hawt.io/contributing/index.html

or feel free to raise new issues for how to improve the camel plugin:
https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open

or if you've an itch for a new kind of plugin please dive in! We
should be able to expose existing web apps/consoles as links inside
hawtio too BTW.

Feedback appreciated! Its hawt, but stay cool! ;)

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, I think I first mentioned hawtio in the Camel 3.0 thread (message
from 8:27 am)  when you asked Lukasz to look at the lightweight web
console, only saying we should look at it.  James started this different
thread to actually not pollute the Camel 3 discussion with hawtio details.
So I think we're on the same page.



On Fri, Jan 25, 2013 at 4:58 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:

> Ok, that is a different discussion I would rather have in the context of
> Camel 3.0. I will start a separate thread for this. Having the conversation
> in the context of the subject of this thread may be confusing. Sorry for
> the misunderstanding.
>
> Cheers,
> Hadrian
>
>
>
> On 01/25/2013 10:42 AM, Guillaume Nodet wrote:
>
>> You misunderstood me.  So I rephrase.
>>
>> Camel and ActiveMQ community needs a versatile console which can run in a
>> non OSGi environement, so they can't drop their current web console in
>> favor of the karaf one.
>>
>> This discussion is imho totally relevant for the camel community, as it is
>> for all other projects.  I already forwarded the email to the karaf
>> community and other projects may be involved too.
>>
>>
>>
>> On Fri, Jan 25, 2013 at 4:24 PM, Hadrian Zbarcea <hz...@gmail.com>
>> wrote:
>>
>>  This is one more reason why the hawt.io discussions should take place in
>>> the hawt.io communities. Not here.
>>>
>>> Thanks,
>>> Hadrian
>>>
>>>
>>> On 01/25/2013 08:08 AM, Guillaume Nodet wrote:
>>>
>>>  Lukasz, I'm sorry you're angry, but you're missing the point that the
>>>> Karaf
>>>> web console is bound to OSGi even if it can be reused with Camel or
>>>> ActiveMQ.
>>>> So the Camel and ActiveMQ community will never drop their own console,
>>>> because the OSGi users is only a fraction of the user base.  Hawtio
>>>> enable
>>>> all projects to cooperate on a single web console, at last.
>>>> So it serves a more general purpose imnsho.
>>>>
>>>>
>>>>
>>
>>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Hadrian Zbarcea <hz...@gmail.com>.
Ok, that is a different discussion I would rather have in the context of 
Camel 3.0. I will start a separate thread for this. Having the 
conversation in the context of the subject of this thread may be 
confusing. Sorry for the misunderstanding.

Cheers,
Hadrian


On 01/25/2013 10:42 AM, Guillaume Nodet wrote:
> You misunderstood me.  So I rephrase.
>
> Camel and ActiveMQ community needs a versatile console which can run in a
> non OSGi environement, so they can't drop their current web console in
> favor of the karaf one.
>
> This discussion is imho totally relevant for the camel community, as it is
> for all other projects.  I already forwarded the email to the karaf
> community and other projects may be involved too.
>
>
>
> On Fri, Jan 25, 2013 at 4:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
>> This is one more reason why the hawt.io discussions should take place in
>> the hawt.io communities. Not here.
>>
>> Thanks,
>> Hadrian
>>
>>
>> On 01/25/2013 08:08 AM, Guillaume Nodet wrote:
>>
>>> Lukasz, I'm sorry you're angry, but you're missing the point that the
>>> Karaf
>>> web console is bound to OSGi even if it can be reused with Camel or
>>> ActiveMQ.
>>> So the Camel and ActiveMQ community will never drop their own console,
>>> because the OSGi users is only a fraction of the user base.  Hawtio enable
>>> all projects to cooperate on a single web console, at last.
>>> So it serves a more general purpose imnsho.
>>>
>>>
>
>

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
You misunderstood me.  So I rephrase.

Camel and ActiveMQ community needs a versatile console which can run in a
non OSGi environement, so they can't drop their current web console in
favor of the karaf one.

This discussion is imho totally relevant for the camel community, as it is
for all other projects.  I already forwarded the email to the karaf
community and other projects may be involved too.



On Fri, Jan 25, 2013 at 4:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:

> This is one more reason why the hawt.io discussions should take place in
> the hawt.io communities. Not here.
>
> Thanks,
> Hadrian
>
>
> On 01/25/2013 08:08 AM, Guillaume Nodet wrote:
>
>> Lukasz, I'm sorry you're angry, but you're missing the point that the
>> Karaf
>> web console is bound to OSGi even if it can be reused with Camel or
>> ActiveMQ.
>> So the Camel and ActiveMQ community will never drop their own console,
>> because the OSGi users is only a fraction of the user base.  Hawtio enable
>> all projects to cooperate on a single web console, at last.
>> So it serves a more general purpose imnsho.
>>
>>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Hadrian Zbarcea <hz...@gmail.com>.
This is one more reason why the hawt.io discussions should take place in 
the hawt.io communities. Not here.

Thanks,
Hadrian

On 01/25/2013 08:08 AM, Guillaume Nodet wrote:
> Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf
> web console is bound to OSGi even if it can be reused with Camel or
> ActiveMQ.
> So the Camel and ActiveMQ community will never drop their own console,
> because the OSGi users is only a fraction of the user base.  Hawtio enable
> all projects to cooperate on a single web console, at last.
> So it serves a more general purpose imnsho.
>

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jan 25, 2013 at 2:36 PM, Łukasz Dywicki <lu...@code-house.org> wrote:

> I'm not angry. I'm just telling the truth. Nobody told to you yet.


Thx for that,  I think I was really erring on the dark side before ;-)


> Why you think it's bound to OSGi? We have WAR packaging.  Overall
> destination was always to support other runtimes.


The war packaging does start an OSGi framework inside the war.  In addition
the console heavily depends on pax-wicket, which afaik, does need OSGi.  As
you said, injection is done through OSGi services.  My understanding (feel
free to correct me if I'm wrong) is that the camel plugins is injected with
a list of CamelContext coming from OSGi.  Which kinda means to me, that you
need to deploy your camel contexts in OSGi, next to the console itself.


> Charles was talking about that and he found even a name for it once it
> will get TLP (Orion). But it was so long ago you propably don't remember.


Maybe I missed something, but when the Orion proposal was raised, Karaf web
console did not really exist yet.

The proposal was to create a TLP for an OSGi web console with a real web
framework.   None of these ideas did sound good to me at that time (having
a TLP for an OSGi web console and rewriting the existing webconsole with a
web framework).  We disagree, but these 2 years did not really changed my
mind.
Now, a few people went ahead and rewrote an OSGi based web console, which
is nice, but it's still is an OSGi web console and I still don't like the
technical design decisions that were taken.

And more importantly, this console does not really help half of our camel
users which do not use OSGi.


>
> Cheers, :)
>

Np.  We've been trying to get the webconsole problems fixed since the
beginning with ServiceMix 3, so that's almost 6 years ago now.  it became
even more complicated with ServiceMix 4 switching to OSGi.  I think we have
a clean solution now that can work for all projects with hawtio.
Will the project last and pick up ? No one knows yet.  Not all projects are
bound to suceed.  The one that do usually solves real problems in a clean
way.  I think hawtio is a good bet now ... until someone comes up with a
better project.  That's how it works.


> Lukasz
>
>
> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25 sty
> 2013, o godz. 14:08:
>
> > Lukasz, I'm sorry you're angry, but you're missing the point that the
> Karaf
> > web console is bound to OSGi even if it can be reused with Camel or
> > ActiveMQ.
> > So the Camel and ActiveMQ community will never drop their own console,
> > because the OSGi users is only a fraction of the user base.  Hawtio
> enable
> > all projects to cooperate on a single web console, at last.
> > So it serves a more general purpose imnsho.
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Łukasz Dywicki <lu...@code-house.org>.
I'm not angry. I'm just telling the truth. Nobody told to you yet. Why you think it's bound to OSGi? We have WAR packaging. Overall destination was always to support other runtimes. Charles was talking about that and he found even a name for it once it will get TLP (Orion). But it was so long ago you propably don't remember.

Cheers, :)
Lukasz


Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25 sty 2013, o godz. 14:08:

> Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf
> web console is bound to OSGi even if it can be reused with Camel or
> ActiveMQ.
> So the Camel and ActiveMQ community will never drop their own console,
> because the OSGi users is only a fraction of the user base.  Hawtio enable
> all projects to cooperate on a single web console, at last.
> So it serves a more general purpose imnsho.


Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf
web console is bound to OSGi even if it can be reused with Camel or
ActiveMQ.
So the Camel and ActiveMQ community will never drop their own console,
because the OSGi users is only a fraction of the user base.  Hawtio enable
all projects to cooperate on a single web console, at last.
So it serves a more general purpose imnsho.

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Hadrian Zbarcea <hz...@gmail.com>.
I personally find the tone of this exchange very distasteful and I would 
much appreciate you continuing it on other media channels than the 
@camel user lists.

FWIW, Lukasz made some valid points. However, you saw a need for a new 
project, created it, great. Hawt.io is nice, please continue to drive 
its development there.

Thanks,
Hadrian



On 01/25/2013 07:36 AM, James Strachan wrote:
> On 25 January 2013 11:51, Łukasz Dywicki <lu...@code-house.org> wrote:
>> Gentelmans,
>> Especially from Fuse. We have something similar already in Karaf repository and it's called WebConsole. It been there since 2011. I'm sure you was aware of that, especially Guilliaume.
>
> I'm aware of most of the consoles at Apache yes.
>
>
>> There was example how to use it together with Camel and ServiceMix. But you never took time to take a look on that.
>
> How do you know? I did as it happens.
>
>
>> You decided to create another project instead of supporting existing Apache community project. Or, I should be happy that you did not fork it?
>
> I created another project. You got me there! I apologise for having
> the cheek to create a project - I hope you will find it in your heart
> to forgive me one day.
>
> The main reason I did is the idea behind hawtio is to be make a
> technology agnostic plugin based console. So its not OSGi specific or
> Karaf specific; or Tomcat or Fuse Fabric or Camel or ActiveMQ
> specific. Its a generic way to plug consoles together in a technology
> agnostic way.
>
> Thats why I didn't put it inside Apache Camel or Apache Karaf which
> are specific frameworks and containers.
>
> Though there's nothing stopping any project anywhere; inside Apache or
> outside - of making a plugin for hawtio; or reusing hawtio inside its
> own console, or exposing an existing console to hawtio.
>
>
>> We had the same problems with different web consoles, we saw that two years ago when you started working on Fabric. Now you came here and rescue us.
>
> Remember this is the camel list. Karaf web console doesn't really help
> Camel folks terribly much. I created the original camel-web console;
> the reason I'm back here is to say I've figured out a better way to do
> the Camel console; thats way better & way smaller.
>
>
>> If I remember correctly that's third console you produced for Fabric (I don't count previous Fuse consoles).
>
> There is 1 console for Fuse Fabric; called FMC - which we're migrating
> to be a plugin for hawtio; so that Fabric has 1 modular console which
> anyone can extend. With anything. Like, oh I don't know, the Karaf web
> console if anyone fancies. I hear its quite good.
>
>
>> I hope it will be latest and you will not drop the idea and continue supporting it.
>
> Gee thanks for your vote of confidence. We'll definitely be supporting
> it & using it heavily.
>
>
>> Hawt.io structure (because is has no architecture) is same as Felix WebConsole.
>
> if you're interested, the architecture is described here
> http://hawt.io/developers/index.html
> http://hawt.io/developers/plugins.html
>
>
>> In comparision Felix console uses OSGi services, your uses JMX.
>
> A hawtio plugin can use REST / OSGi / JMX / whatever. But yeah, we're
> using JMX by default for discovery as its the lowest common
> denominator so we can point at any JVM and do something useful. e.g. a
> stand alone JVM / Tomcat / Jetty/ JBoss / Karaf / Fuse Fabric.
>
>
>> Please consider donating it as Felix WebConsole 5.
>
> Felix can easily reuse it if it wants. Its not Felix / OSGi / Karaf
> specific though.
>
>
>> You will change jQuery to Angular.
>
> The default plugins use jQuery and angularjs; though plugins can use
> anything they want...
>
>
>> I think hawt.io will finish same as ActiveMQ webconsole. With minimal set of functionality and problems with security.
>
> Its already got more functionality than the ActiveMQ console & when
> deployed in Karaf can reuse the same HTTP security.
>
> Thanks for your feedback!
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 25 January 2013 11:51, Łukasz Dywicki <lu...@code-house.org> wrote:
> Gentelmans,
> Especially from Fuse. We have something similar already in Karaf repository and it's called WebConsole. It been there since 2011. I'm sure you was aware of that, especially Guilliaume.

I'm aware of most of the consoles at Apache yes.


> There was example how to use it together with Camel and ServiceMix. But you never took time to take a look on that.

How do you know? I did as it happens.


> You decided to create another project instead of supporting existing Apache community project. Or, I should be happy that you did not fork it?

I created another project. You got me there! I apologise for having
the cheek to create a project - I hope you will find it in your heart
to forgive me one day.

The main reason I did is the idea behind hawtio is to be make a
technology agnostic plugin based console. So its not OSGi specific or
Karaf specific; or Tomcat or Fuse Fabric or Camel or ActiveMQ
specific. Its a generic way to plug consoles together in a technology
agnostic way.

Thats why I didn't put it inside Apache Camel or Apache Karaf which
are specific frameworks and containers.

Though there's nothing stopping any project anywhere; inside Apache or
outside - of making a plugin for hawtio; or reusing hawtio inside its
own console, or exposing an existing console to hawtio.


> We had the same problems with different web consoles, we saw that two years ago when you started working on Fabric. Now you came here and rescue us.

Remember this is the camel list. Karaf web console doesn't really help
Camel folks terribly much. I created the original camel-web console;
the reason I'm back here is to say I've figured out a better way to do
the Camel console; thats way better & way smaller.


> If I remember correctly that's third console you produced for Fabric (I don't count previous Fuse consoles).

There is 1 console for Fuse Fabric; called FMC - which we're migrating
to be a plugin for hawtio; so that Fabric has 1 modular console which
anyone can extend. With anything. Like, oh I don't know, the Karaf web
console if anyone fancies. I hear its quite good.


> I hope it will be latest and you will not drop the idea and continue supporting it.

Gee thanks for your vote of confidence. We'll definitely be supporting
it & using it heavily.


> Hawt.io structure (because is has no architecture) is same as Felix WebConsole.

if you're interested, the architecture is described here
http://hawt.io/developers/index.html
http://hawt.io/developers/plugins.html


> In comparision Felix console uses OSGi services, your uses JMX.

A hawtio plugin can use REST / OSGi / JMX / whatever. But yeah, we're
using JMX by default for discovery as its the lowest common
denominator so we can point at any JVM and do something useful. e.g. a
stand alone JVM / Tomcat / Jetty/ JBoss / Karaf / Fuse Fabric.


> Please consider donating it as Felix WebConsole 5.

Felix can easily reuse it if it wants. Its not Felix / OSGi / Karaf
specific though.


> You will change jQuery to Angular.

The default plugins use jQuery and angularjs; though plugins can use
anything they want...


> I think hawt.io will finish same as ActiveMQ webconsole. With minimal set of functionality and problems with security.

Its already got more functionality than the ActiveMQ console & when
deployed in Karaf can reuse the same HTTP security.

Thanks for your feedback!

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Łukasz Dywicki <lu...@code-house.org>.
Gentelmans,
Especially from Fuse. We have something similar already in Karaf repository and it's called WebConsole. It been there since 2011. I'm sure you was aware of that, especially Guilliaume. There was example how to use it together with Camel and ServiceMix. But you never took time to take a look on that. You decided to create another project instead of supporting existing Apache community project. Or, I should be happy that you did not fork it?

We had the same problems with different web consoles, we saw that two years ago when you started working on Fabric. Now you came here and rescue us. If I remember correctly that's third console you produced for Fabric (I don't count previous Fuse consoles). I hope it will be latest and you will not drop the idea and continue supporting it.
Hawt.io structure (because is has no architecture) is same as Felix WebConsole. In comparision Felix console uses OSGi services, your uses JMX. Please consider donating it as Felix WebConsole 5. You will change jQuery to Angular. I think hawt.io will finish same as ActiveMQ webconsole. With minimal set of functionality and problems with security.

Cheers,
Lukasz
--
Small discamler: it's my personal opinion. I do not represent any company here.

Wiadomość napisana przez James Strachan <ja...@gmail.com> w dniu 25 sty 2013, o godz. 10:59:

> For the impatient just look here :) http://hawt.io/
> 
> Background
> ==========
> We've had numerous consoles all over the place for some time in
> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> Fabric to name but a few. Many of them quite heavy weight requiring a
> custom web app to be deployed (which often is quite large); none
> particularly working together.
> 
> We've been working on Fuse Fabric and its management console to
> provide a more consolidated view of a cluster of Apache integration &
> middleware technologies. Increasingly we're seeing our users and
> customers using different combinations of technologies in different
> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> Karaf + ActiveMQ + Camel or whatever).
> 
> So for a few months a few of us have been working on trying to make
> the various web consoles for things like Apache Camel, ActiveMQ,
> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> and matched together to suite any container and combination of
> technologies that folks deploy in a JVM.
> 
> 
> hawtio
> =====
> The result so far is hawtio: http://hawt.io/
> 
> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> provides a UI console for whatever it finds in the JVM. So it works
> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> way.
> 
> The nice thing is its pretty small (about 1Mb WAR containing all the
> server side code, HTML, JS, images, CSS etc). The only real server
> side component is jolokia which is a small (about 300K) REST connector
> for JMX (which is awesome BTW!) - the rest is static content (which
> could be served from anywhere so doesn't need to be deployed in each
> JVM).
> 
> Its based around a plugin architecture:
> http://hawt.io/developers/plugins.html
> 
> so its easy to add new plugins for any kind of technology. A plugin is
> pretty much anything that runs in a browser.
> 
> The nice thing is hawtio can discover UI plugins at runtime by
> examining the contents of the JVM or querying REST endpoints; so the
> UI can update in real time as you deploy new things into a JVM!
> 
> 
> hawtio, the hawt camel rider
> ======================
> A quick summary of the current features for camel folks:
> 
> * If you have any camel contexts running in a JVM when hawtio starts
> up it adds an Integration tab which shows all the camel contexts
> running.
> 
> * You can start/stop/suspend/resume the context and its routes; then
> look at all the metrics for routes/endpoints/processors. The Charts
> tab lets you visualise the real time metrics.
> 
> * You can create new endpoints; browse endpoints which are browsable &
> send messages to endpoints (with syntax editing support for JSON / XML
> / YAML / properties)
> 
> * You can visualise all the camel routes or a specific camel route for
> a context in the Diagram tab and see real time metrics of how many
> messages are passing through each step on the diagram. e.g.
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
> 
> * Clicking on a Route allows you to Trace it; when tracing if you send
> a message into a route then it captures a copy of the message at each
> point through the route. So you can step through (scroll/click through
> the table) a route and see the message contents and how the message
> flows through the EIPs - highlighting where on the diagram each
> message is. This is very handy for figuring out why your route doesn't
> work :) Spot where the heading disappears! Or see why the CBR doesn't
> go where you expected.
> 
> In general most of the runtime features of the open source Fuse IDE
> eclipse tooling are now supported in the camel hawtio plugin; so
> available in a web browser.
> 
> 
> Summary
> =======
> So if you're vaguely interested in web consoles for Apache Camel I
> urge you to give it a try. We love contributions and feedback!
> http://hawt.io/contributing/index.html
> 
> or feel free to raise new issues for how to improve the camel plugin:
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
> 
> or if you've an itch for a new kind of plugin please dive in! We
> should be able to expose existing web apps/consoles as links inside
> hawtio too BTW.
> 
> Feedback appreciated! Its hawt, but stay cool! ;)
> 
> --
> James
> -------
> Red Hat
> 
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
> 
> Open Source Integration


Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 25 January 2013 12:58, Preben.Asmussen <pr...@dr.dk> wrote:
> Gave it a ride to test it and it looks awesome.
> <http://camel.465427.n5.nabble.com/file/n5726252/hawt.io.png>

Thanks!


> Still prefer VisualVM when it comes to monitoring though. Besides JMX
> threads, CPU and mem can be accessed here too.

Yeah, am sure we can improve the JMX monitoring some more with some
nicer views. We maybe need a kinda 'system' view showing CPU / memory
/ threads / disk in a simpler single view.

FWIW the JMX tab if you select "java.lang" you can view/chart metrics
on OperationSystem / Threading though the Memory stuff could use some
work though.


> More feedback to come later when I get some more time.

Thanks!

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by "Preben.Asmussen" <pr...@dr.dk>.
Gave it a ride to test it and it looks awesome. 
<http://camel.465427.n5.nabble.com/file/n5726252/hawt.io.png> 

Still prefer VisualVM when it comes to monitoring though. Besides JMX
threads, CPU and mem can be accessed here too.

More feedback to come later when I get some more time.

/Preben




--
View this message in context: http://camel.465427.n5.nabble.com/ANN-hawtio-a-new-lightweight-HTML5-console-for-Apache-Camel-ActiveMQ-JMX-OSGi-Fuse-Fabric-tp5726244p5726252.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
If the feature file doesn't work you could just try this:

* add this line to your etc/org.ops4j.pax.url.mvn.cfg (which won't be
needed once we've released 1.0 soon ;)

org.ops4j.pax.url.mvn.repositories= \
     https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo
\

* then in the Karaf / Fuse ESB console try:

   features:install war
   install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war


On 25 January 2013 11:32, Martin Stiborský <ma...@gmail.com> wrote:
> Hello,
> it looks really nice…I just give it a try, trying to install it in Karaf,
> where is my Camel project running, but after ~50 minut I wasn't succesfull.
> I was trying to utilize Fuse features.xml, to install hawtio, but that
> wasn't probably good idea :)
> I'll come back to it later, but if there is a easy way how to install
> hawtio as OSGi bundle into Apache Karaf, let me know, please.
> I'm still new in those things, so most probably I just did something wrong,
> or over-complicated :)
>
>
> On Fri, Jan 25, 2013 at 10:59 AM, James Strachan
> <ja...@gmail.com>wrote:
>
>> For the impatient just look here :) http://hawt.io/
>>
>> Background
>> ==========
>> We've had numerous consoles all over the place for some time in
>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>> Fabric to name but a few. Many of them quite heavy weight requiring a
>> custom web app to be deployed (which often is quite large); none
>> particularly working together.
>>
>> We've been working on Fuse Fabric and its management console to
>> provide a more consolidated view of a cluster of Apache integration &
>> middleware technologies. Increasingly we're seeing our users and
>> customers using different combinations of technologies in different
>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>> Karaf + ActiveMQ + Camel or whatever).
>>
>> So for a few months a few of us have been working on trying to make
>> the various web consoles for things like Apache Camel, ActiveMQ,
>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>> and matched together to suite any container and combination of
>> technologies that folks deploy in a JVM.
>>
>>
>> hawtio
>> =====
>> The result so far is hawtio: http://hawt.io/
>>
>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>> provides a UI console for whatever it finds in the JVM. So it works
>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>> way.
>>
>> The nice thing is its pretty small (about 1Mb WAR containing all the
>> server side code, HTML, JS, images, CSS etc). The only real server
>> side component is jolokia which is a small (about 300K) REST connector
>> for JMX (which is awesome BTW!) - the rest is static content (which
>> could be served from anywhere so doesn't need to be deployed in each
>> JVM).
>>
>> Its based around a plugin architecture:
>> http://hawt.io/developers/plugins.html
>>
>> so its easy to add new plugins for any kind of technology. A plugin is
>> pretty much anything that runs in a browser.
>>
>> The nice thing is hawtio can discover UI plugins at runtime by
>> examining the contents of the JVM or querying REST endpoints; so the
>> UI can update in real time as you deploy new things into a JVM!
>>
>>
>> hawtio, the hawt camel rider
>> ======================
>> A quick summary of the current features for camel folks:
>>
>> * If you have any camel contexts running in a JVM when hawtio starts
>> up it adds an Integration tab which shows all the camel contexts
>> running.
>>
>> * You can start/stop/suspend/resume the context and its routes; then
>> look at all the metrics for routes/endpoints/processors. The Charts
>> tab lets you visualise the real time metrics.
>>
>> * You can create new endpoints; browse endpoints which are browsable &
>> send messages to endpoints (with syntax editing support for JSON / XML
>> / YAML / properties)
>>
>> * You can visualise all the camel routes or a specific camel route for
>> a context in the Diagram tab and see real time metrics of how many
>> messages are passing through each step on the diagram. e.g.
>>
>> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>>
>> * Clicking on a Route allows you to Trace it; when tracing if you send
>> a message into a route then it captures a copy of the message at each
>> point through the route. So you can step through (scroll/click through
>> the table) a route and see the message contents and how the message
>> flows through the EIPs - highlighting where on the diagram each
>> message is. This is very handy for figuring out why your route doesn't
>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>> go where you expected.
>>
>> In general most of the runtime features of the open source Fuse IDE
>> eclipse tooling are now supported in the camel hawtio plugin; so
>> available in a web browser.
>>
>>
>> Summary
>> =======
>> So if you're vaguely interested in web consoles for Apache Camel I
>> urge you to give it a try. We love contributions and feedback!
>> http://hawt.io/contributing/index.html
>>
>> or feel free to raise new issues for how to improve the camel plugin:
>>
>> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>>
>> or if you've an itch for a new kind of plugin please dive in! We
>> should be able to expose existing web apps/consoles as links inside
>> hawtio too BTW.
>>
>> Feedback appreciated! Its hawt, but stay cool! ;)
>>
>> --
>> James
>> -------
>> Red Hat
>>
>> Email: jstracha@redhat.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>>
>
>
>
> --
> S pozdravem / Best regards
> Martin Stiborský
>
> Jabber: stibi@njs.netlab.cz
> Twitter: http://www.twitter.com/stibi



-- 
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Martin Stiborský <ma...@gmail.com>.
Hello,
it looks really nice…I just give it a try, trying to install it in Karaf,
where is my Camel project running, but after ~50 minut I wasn't succesfull.
I was trying to utilize Fuse features.xml, to install hawtio, but that
wasn't probably good idea :)
I'll come back to it later, but if there is a easy way how to install
hawtio as OSGi bundle into Apache Karaf, let me know, please.
I'm still new in those things, so most probably I just did something wrong,
or over-complicated :)


On Fri, Jan 25, 2013 at 10:59 AM, James Strachan
<ja...@gmail.com>wrote:

> For the impatient just look here :) http://hawt.io/
>
> Background
> ==========
> We've had numerous consoles all over the place for some time in
> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> Fabric to name but a few. Many of them quite heavy weight requiring a
> custom web app to be deployed (which often is quite large); none
> particularly working together.
>
> We've been working on Fuse Fabric and its management console to
> provide a more consolidated view of a cluster of Apache integration &
> middleware technologies. Increasingly we're seeing our users and
> customers using different combinations of technologies in different
> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> Karaf + ActiveMQ + Camel or whatever).
>
> So for a few months a few of us have been working on trying to make
> the various web consoles for things like Apache Camel, ActiveMQ,
> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> and matched together to suite any container and combination of
> technologies that folks deploy in a JVM.
>
>
> hawtio
> =====
> The result so far is hawtio: http://hawt.io/
>
> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> provides a UI console for whatever it finds in the JVM. So it works
> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> way.
>
> The nice thing is its pretty small (about 1Mb WAR containing all the
> server side code, HTML, JS, images, CSS etc). The only real server
> side component is jolokia which is a small (about 300K) REST connector
> for JMX (which is awesome BTW!) - the rest is static content (which
> could be served from anywhere so doesn't need to be deployed in each
> JVM).
>
> Its based around a plugin architecture:
> http://hawt.io/developers/plugins.html
>
> so its easy to add new plugins for any kind of technology. A plugin is
> pretty much anything that runs in a browser.
>
> The nice thing is hawtio can discover UI plugins at runtime by
> examining the contents of the JVM or querying REST endpoints; so the
> UI can update in real time as you deploy new things into a JVM!
>
>
> hawtio, the hawt camel rider
> ======================
> A quick summary of the current features for camel folks:
>
> * If you have any camel contexts running in a JVM when hawtio starts
> up it adds an Integration tab which shows all the camel contexts
> running.
>
> * You can start/stop/suspend/resume the context and its routes; then
> look at all the metrics for routes/endpoints/processors. The Charts
> tab lets you visualise the real time metrics.
>
> * You can create new endpoints; browse endpoints which are browsable &
> send messages to endpoints (with syntax editing support for JSON / XML
> / YAML / properties)
>
> * You can visualise all the camel routes or a specific camel route for
> a context in the Diagram tab and see real time metrics of how many
> messages are passing through each step on the diagram. e.g.
>
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>
> * Clicking on a Route allows you to Trace it; when tracing if you send
> a message into a route then it captures a copy of the message at each
> point through the route. So you can step through (scroll/click through
> the table) a route and see the message contents and how the message
> flows through the EIPs - highlighting where on the diagram each
> message is. This is very handy for figuring out why your route doesn't
> work :) Spot where the heading disappears! Or see why the CBR doesn't
> go where you expected.
>
> In general most of the runtime features of the open source Fuse IDE
> eclipse tooling are now supported in the camel hawtio plugin; so
> available in a web browser.
>
>
> Summary
> =======
> So if you're vaguely interested in web consoles for Apache Camel I
> urge you to give it a try. We love contributions and feedback!
> http://hawt.io/contributing/index.html
>
> or feel free to raise new issues for how to improve the camel plugin:
>
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>
> or if you've an itch for a new kind of plugin please dive in! We
> should be able to expose existing web apps/consoles as links inside
> hawtio too BTW.
>
> Feedback appreciated! Its hawt, but stay cool! ;)
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>



-- 
S pozdravem / Best regards
Martin Stiborský

Jabber: stibi@njs.netlab.cz
Twitter: http://www.twitter.com/stibi

Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I would also like to see an update about a "merge" between HawtIO and 
Karaf WebConsole.
As reminder, Karaf WebConsole has been designed as a container hosting 
Karaf, ActiveMQ, Camel, etc, exactly the same purpose as HawtIO.
Of course HawtIO is not Apache or Karaf subproject now, but it could be 
interesting to see "overlap"/gaps and where the two projects have to 
move together (or not ;)).

Regards
JB

On 01/25/2013 12:08 PM, Guillaume Nodet wrote:
> FYI, I'm really excited about finally being able to have a unified web
> console for Karaf / ActiveMQ / Camel, especially the fact that the same web
> console can be used in a non OSGi-environment, so we can really leverage
> and work together on a single web console.
> I'd encourage everyone to have a look at it and eventually look at what's
> missing from a Karaf point of view so that we can discuss if/how we
> integrate it.
>
> ---------- Forwarded message ----------
> From: James Strachan <ja...@gmail.com>
> Date: Fri, Jan 25, 2013 at 10:59 AM
> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
> ActiveMQ, JMX, OSGi & Fuse Fabric
> To: "users@camel.apache.org" <us...@camel.apache.org>
>
>
> For the impatient just look here :) http://hawt.io/
>
> Background
> ==========
> We've had numerous consoles all over the place for some time in
> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> Fabric to name but a few. Many of them quite heavy weight requiring a
> custom web app to be deployed (which often is quite large); none
> particularly working together.
>
> We've been working on Fuse Fabric and its management console to
> provide a more consolidated view of a cluster of Apache integration &
> middleware technologies. Increasingly we're seeing our users and
> customers using different combinations of technologies in different
> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> Karaf + ActiveMQ + Camel or whatever).
>
> So for a few months a few of us have been working on trying to make
> the various web consoles for things like Apache Camel, ActiveMQ,
> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> and matched together to suite any container and combination of
> technologies that folks deploy in a JVM.
>
>
> hawtio
> =====
> The result so far is hawtio: http://hawt.io/
>
> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> provides a UI console for whatever it finds in the JVM. So it works
> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> way.
>
> The nice thing is its pretty small (about 1Mb WAR containing all the
> server side code, HTML, JS, images, CSS etc). The only real server
> side component is jolokia which is a small (about 300K) REST connector
> for JMX (which is awesome BTW!) - the rest is static content (which
> could be served from anywhere so doesn't need to be deployed in each
> JVM).
>
> Its based around a plugin architecture:
> http://hawt.io/developers/plugins.html
>
> so its easy to add new plugins for any kind of technology. A plugin is
> pretty much anything that runs in a browser.
>
> The nice thing is hawtio can discover UI plugins at runtime by
> examining the contents of the JVM or querying REST endpoints; so the
> UI can update in real time as you deploy new things into a JVM!
>
>
> hawtio, the hawt camel rider
> ======================
> A quick summary of the current features for camel folks:
>
> * If you have any camel contexts running in a JVM when hawtio starts
> up it adds an Integration tab which shows all the camel contexts
> running.
>
> * You can start/stop/suspend/resume the context and its routes; then
> look at all the metrics for routes/endpoints/processors. The Charts
> tab lets you visualise the real time metrics.
>
> * You can create new endpoints; browse endpoints which are browsable &
> send messages to endpoints (with syntax editing support for JSON / XML
> / YAML / properties)
>
> * You can visualise all the camel routes or a specific camel route for
> a context in the Diagram tab and see real time metrics of how many
> messages are passing through each step on the diagram. e.g.
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>
> * Clicking on a Route allows you to Trace it; when tracing if you send
> a message into a route then it captures a copy of the message at each
> point through the route. So you can step through (scroll/click through
> the table) a route and see the message contents and how the message
> flows through the EIPs - highlighting where on the diagram each
> message is. This is very handy for figuring out why your route doesn't
> work :) Spot where the heading disappears! Or see why the CBR doesn't
> go where you expected.
>
> In general most of the runtime features of the open source Fuse IDE
> eclipse tooling are now supported in the camel hawtio plugin; so
> available in a web browser.
>
>
> Summary
> =======
> So if you're vaguely interested in web consoles for Apache Camel I
> urge you to give it a try. We love contributions and feedback!
> http://hawt.io/contributing/index.html
>
> or feel free to raise new issues for how to improve the camel plugin:
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>
> or if you've an itch for a new kind of plugin please dive in! We
> should be able to expose existing web apps/consoles as links inside
> hawtio too BTW.
>
> Feedback appreciated! Its hawt, but stay cool! ;)
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 25 January 2013 17:22, Christian Schneider <ch...@die-schneider.net> wrote:
> I have not looked into HawtIO in detail but the idea of having a general
> console with plugins for each technology sounds good to me.
> I also think it is good to start such a console separately in github as
> it allows for fast progress to show it works.

Agreed. github has great tools as well; plus its got the lowest
barrier to entry which encourages participation.


> For the long term I think that the generic part of such a console should
> move into an apache project. As it makes sense to keep the console
> independent of OSGi a separate project may make sense.
> So why should we do this in apache? The reason is that currently HawtIO
> is just another console. Only at a big community like apache we can hope
> for a project to get enough acceptance that a lot of projects participate.
>
> So if we succeed in creating an accepted generic foundation for
> management consoles then each of the technology plugins could be
> developed in the respective projects.
>
> What do you think about this?

It could move to Apache one day. I'm much more keen though to get
folks contributing and writing plugins - those plugins could live at
github, eclipse, inside their respective Apache projects or in a new
Apache UI project or whatever. Though actually having the UI console
in a separate project kinda helps (e.g. hawtio works with all versions
of Camel).

Everything's Apache licensed so any project can reuse / embed / extend
hawtio wherever folks wish; plus folks can create their own stand
alone consoles in any project - or just write and release their own
plugins from any project anywhere.

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 27 January 2013 18:25, Christian Müller <ch...@gmail.com> wrote:
> ... and to make it precise. By writing "fighting for it" I mean:
> - add missing features to Karaf WebConsole
> - provide better documentation (for users and developers)
> - make it as easy as possible to install it
> -  and whatever you can do to improve Karaf WebConsole.

It doesn't have to be a fight :). There's no reason Karaf WebConsole
can't reuse any/all of hawtio's plugins (e.g. for Camel / ActiveMQ /
JMX) or for Karaf WebConsole to expose all its Karaf views as a plugin
to hawtio; so users get the best of both worlds.

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 27 January 2013 18:25, Christian Müller <ch...@gmail.com> wrote:
> ... and to make it precise. By writing "fighting for it" I mean:
> - add missing features to Karaf WebConsole
> - provide better documentation (for users and developers)
> - make it as easy as possible to install it
> -  and whatever you can do to improve Karaf WebConsole.

It doesn't have to be a fight :). There's no reason Karaf WebConsole
can't reuse any/all of hawtio's plugins (e.g. for Camel / ActiveMQ /
JMX) or for Karaf WebConsole to expose all its Karaf views as a plugin
to hawtio; so users get the best of both worlds.

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
... and to make it precise. By writing "fighting for it" I mean:
- add missing features to Karaf WebConsole
- provide better documentation (for users and developers)
- make it as easy as possible to install it
-  and whatever you can do to improve Karaf WebConsole.

Best,
Christian

On Sun, Jan 27, 2013 at 6:55 PM, Christian Müller <
christian.mueller@gmail.com> wrote:

> Hi Lukasz!
>
> I also do not see any issues with this announcement on the dev@ Camel
> mailing list.
> This announcement is relevant for the Camel users as it offers a awesome
> management user interface for Camel (and other frameworks/technologies).
> Even better, this product is also open source under Apache license 2.0.
> This announcement is NOT spam.
>
> Also the fact that this project is not an Apache project is NOT an issue
> at all. As the others already mentioned, we use multiple
> projects/frameworks which are developed outside the Apache community. What
> would we do if we couldn't use great frameworks/products like Spring,
> Jetty, JUnit, Pax-*, EasyMock, Quartz, ... or Jolokia?
>
> I share Guillaumes opinion that your post sounds angry. But I think there
> is really no reason for. If this product is in competition with an existing
> (Apache) project like Karaf WebConsole, this is a good thing from my point
> of view. Competition creates great products and is powering progress. And
> at the end, *IF* one of the projects will disappear because their user
> basis is getting to small, than because the user decided to use the other -
> better - tool. It's not nice to see dieing a project. It's even harder if
> it's a project you are involved with. But that's life and also has goods.
> But until now, Karaf WebConsole is alive and you can try to convince your
> users that this is the better web console for Karaf and Camel. Go out and
> fight for it!
>
> Have a nice - not so cold - week,
> Christian
>
>
> On Sat, Jan 26, 2013 at 3:11 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi Lukasz,
>>
>> I don't see any issue or spam in Guillaume's e-mail: he shared an
>> information with multiple communities, as it considers (and I think he's
>> right) that the information has value and interest for those communities.
>> Apache is not a technical project hosting, it's a set of project
>> communities. Like in all communities, we are here to share ideas and
>> discuss in a fair, smart, and kind way.
>> In Karaf (and other projects), we already discussed and use projects
>> coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc.
>> I remember to have send a couple of e-mails to inform Karaf community
>> about new projects that may interest us (Pax-CDI and Pax-JDBC for instance).
>>
>> Regards
>> JB
>>
>>
>> On 01/25/2013 08:12 PM, Łukasz Dywicki wrote:
>>
>>> Guillaume,
>>> If I'll send a mail with announcement about my amazing project, whatever
>>> it will be, to apache mailing lists I will be treat a spamer. If I will try
>>> doing that with more mailing lists - then I'll be treat as spamer - that's
>>> for sure. And that's what have you done. You have something which relates
>>> to Apache projects but it's not Apache project yet. Apache mailing lists
>>> are not for  announcement about products and projects which are not made
>>> under Apache Foundation. Please honor that.
>>>
>>> That's all in this topic from me and I don't going to discuss about any
>>> other Fuse project any more on Apache mailing lists. If you want donate
>>> hawt.io, that's fine - write incubator proposal (as it doesn't fit
>>> Karaf at all) or take it as part of other community. I don't care.
>>> For example you may wish use ServiceMix for that. You have most of
>>> commiters there. It will fit also SMX5, more over it will let you
>>> resuscitate it after two years of doing nothing.
>>>
>>> I hope I made it clear.
>>> --
>>> Cheers from cold Poland,
>>> Lukasz
>>>
>>> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25
>>> sty 2013, o godz. 19:22:
>>>
>>>  As I explained in the camel thread, I think the main benefit and
>>>> difference
>>>> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
>>>> or
>>>> linked to it in anyway.  It means the plugins can be reused for non OSGi
>>>> users, which still represent a big part of the camel and activemq user
>>>> base.
>>>> The idea would be to avoid having each project needing a different web
>>>> console at the end (and those projects can't really use the Karaf one I
>>>> think).
>>>> For Karaf, we don't really care, but the downstream projects do, and
>>>> aligning on something would help working together on the same code base.
>>>>
>>>> i don't honestly care about the location of the project itself.  We
>>>> depends
>>>> on lots of things that are not hosted at the ASF (all the pax stuff for
>>>> example) and that has never been a problem.    And I don't really think
>>>> this console belongs to Karaf at all because it's not OSGi related.   It
>>>> would actually be an adoption problem for hawtio if it would be in
>>>> Karaf as
>>>> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
>>>> James is willing to move it anywhere else atm.
>>>>
>>>> For now, given the project is not really mature, I think the best way
>>>> going
>>>> forward is to start hacking plugins inside that project itself and we'll
>>>> see over time how it evolves.  If there's a need to move each plugin
>>>> back
>>>> to the original project, it can be done, but today is really not the
>>>> day to
>>>> think about that imho, that's a minor issue, and as long as people are
>>>> able
>>>> to hack on plugins, it should be ok.   For this purpose,, github (with
>>>> forks and pull requests) is actually much easier than the ASF.
>>>>
>>>> If the hawtio project really picks up, then switching to it can be
>>>> considered, but we may want it to mature a bit more before.  Im sure
>>>> it's
>>>> still missing a lot of features we may need, and I only had a quick
>>>> look at
>>>> it, but I really like the underlying technology (a static html page,
>>>> REST
>>>> for accessing the backend, and the whole JMX tree being available
>>>> through
>>>> REST with jolokia).
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>>> >wrote:
>>>>
>>>>  AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>>>>> exactly the purpose of Karaf WebConsole: provide a kind of container
>>>>> for
>>>>> plugins/features extensions.
>>>>>
>>>>> That's my point: identify the overlap/gap between Karaf WebConsole and
>>>>> HawtIO to "communicate" and anticipate the adoption.
>>>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>>>>> projects, it would make sense to have the "Console" project at Apache.
>>>>> As a
>>>>> Karaf subproject, we can move forward and see later if it makes sense
>>>>> to
>>>>> promote as a TLP.
>>>>>
>>>>> My $0.02
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>>>>
>>>>>  I have not looked into HawtIO in detail but the idea of having a
>>>>>> general
>>>>>> console with plugins for each technology sounds good to me.
>>>>>> I also think it is good to start such a console separately in github
>>>>>> as
>>>>>> it allows for fast progress to show it works.
>>>>>>
>>>>>> For the long term I think that the generic part of such a console
>>>>>> should
>>>>>> move into an apache project. As it makes sense to keep the console
>>>>>> independent of OSGi a separate project may make sense.
>>>>>> So why should we do this in apache? The reason is that currently
>>>>>> HawtIO
>>>>>> is just another console. Only at a big community like apache we can
>>>>>> hope
>>>>>> for a project to get enough acceptance that a lot of projects
>>>>>> participate.
>>>>>>
>>>>>> So if we succeed in creating an accepted generic foundation for
>>>>>> management consoles then each of the technology plugins could be
>>>>>> developed in the respective projects.
>>>>>>
>>>>>> What do you think about this?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>>>>
>>>>>>  FYI, I'm really excited about finally being able to have a unified
>>>>>>> web
>>>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
>>>>>>> same
>>>>>>> web
>>>>>>> console can be used in a non OSGi-environment, so we can really
>>>>>>> leverage
>>>>>>> and work together on a single web console.
>>>>>>> I'd encourage everyone to have a look at it and eventually look at
>>>>>>> what's
>>>>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>>>>> integrate it.
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: James Strachan <ja...@gmail.com>
>>>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
>>>>>>> Camel,
>>>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>>>>
>>>>>>>
>>>>>>> For the impatient just look here :) http://hawt.io/
>>>>>>>
>>>>>>> Background
>>>>>>> ==========
>>>>>>> We've had numerous consoles all over the place for some time in
>>>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>>>>> custom web app to be deployed (which often is quite large); none
>>>>>>> particularly working together.
>>>>>>>
>>>>>>> We've been working on Fuse Fabric and its management console to
>>>>>>> provide a more consolidated view of a cluster of Apache integration &
>>>>>>> middleware technologies. Increasingly we're seeing our users and
>>>>>>> customers using different combinations of technologies in different
>>>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>>>>
>>>>>>> So for a few months a few of us have been working on trying to make
>>>>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like
>>>>>>> JMX
>>>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>>>>> and matched together to suite any container and combination of
>>>>>>> technologies that folks deploy in a JVM.
>>>>>>>
>>>>>>>
>>>>>>> hawtio
>>>>>>> =====
>>>>>>> The result so far is hawtio: http://hawt.io/
>>>>>>>
>>>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins
>>>>>>> for
>>>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>>>>> way.
>>>>>>>
>>>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>>>>> side component is jolokia which is a small (about 300K) REST
>>>>>>> connector
>>>>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>>>>> could be served from anywhere so doesn't need to be deployed in each
>>>>>>> JVM).
>>>>>>>
>>>>>>> Its based around a plugin architecture:
>>>>>>> http://hawt.io/developers/****plugins.html<http://hawt.io/developers/**plugins.html>
>>>>>>> <http://hawt.io/**developers/plugins.html<http://hawt.io/developers/plugins.html>
>>>>>>> >
>>>>>>>
>>>>>>> so its easy to add new plugins for any kind of technology. A plugin
>>>>>>> is
>>>>>>> pretty much anything that runs in a browser.
>>>>>>>
>>>>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>>>>> UI can update in real time as you deploy new things into a JVM!
>>>>>>>
>>>>>>>
>>>>>>> hawtio, the hawt camel rider
>>>>>>> ======================
>>>>>>> A quick summary of the current features for camel folks:
>>>>>>>
>>>>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>>>>> up it adds an Integration tab which shows all the camel contexts
>>>>>>> running.
>>>>>>>
>>>>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>>>>> tab lets you visualise the real time metrics.
>>>>>>>
>>>>>>> * You can create new endpoints; browse endpoints which are browsable
>>>>>>> &
>>>>>>> send messages to endpoints (with syntax editing support for JSON /
>>>>>>> XML
>>>>>>> / YAML / properties)
>>>>>>>
>>>>>>> * You can visualise all the camel routes or a specific camel route
>>>>>>> for
>>>>>>> a context in the Diagram tab and see real time metrics of how many
>>>>>>> messages are passing through each step on the diagram. e.g.
>>>>>>> https://raw.github.com/hawtio/****hawtio/master/website/src/**<https://raw.github.com/hawtio/**hawtio/master/website/src/**>
>>>>>>> images/screenshots/camelRoute.****png<https://raw.github.com/**
>>>>>>> hawtio/hawtio/master/website/**src/images/screenshots/**
>>>>>>> camelRoute.png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>>>> >
>>>>>>>
>>>>>>> * Clicking on a Route allows you to Trace it; when tracing if you
>>>>>>> send
>>>>>>> a message into a route then it captures a copy of the message at each
>>>>>>> point through the route. So you can step through (scroll/click
>>>>>>> through
>>>>>>> the table) a route and see the message contents and how the message
>>>>>>> flows through the EIPs - highlighting where on the diagram each
>>>>>>> message is. This is very handy for figuring out why your route
>>>>>>> doesn't
>>>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>>>>> go where you expected.
>>>>>>>
>>>>>>> In general most of the runtime features of the open source Fuse IDE
>>>>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>>>>> available in a web browser.
>>>>>>>
>>>>>>>
>>>>>>> Summary
>>>>>>> =======
>>>>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>>>>> urge you to give it a try. We love contributions and feedback!
>>>>>>> http://hawt.io/contributing/****index.html<http://hawt.io/contributing/**index.html>
>>>>>>> <http://hawt.io/**contributing/index.html<http://hawt.io/contributing/index.html>
>>>>>>> >
>>>>>>>
>>>>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>>>>> https://github.com/hawtio/****hawtio/issues?labels=camel&**<https://github.com/hawtio/**hawtio/issues?labels=camel&**>
>>>>>>> page=1&sort=updated&state=**open<https://github.com/**
>>>>>>> hawtio/hawtio/issues?labels=**camel&page=1&sort=updated&**state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>>>> >
>>>>>>>
>>>>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>>>>> should be able to expose existing web apps/consoles as links inside
>>>>>>> hawtio too BTW.
>>>>>>>
>>>>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>>>>
>>>>>>> --
>>>>>>> James
>>>>>>> -------
>>>>>>> Red Hat
>>>>>>>
>>>>>>> Email: jstracha@redhat.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: jstrachan, fusenews
>>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>>
>>>>>>> Open Source Integration
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
>
>


--

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
... and to make it precise. By writing "fighting for it" I mean:
- add missing features to Karaf WebConsole
- provide better documentation (for users and developers)
- make it as easy as possible to install it
-  and whatever you can do to improve Karaf WebConsole.

Best,
Christian

On Sun, Jan 27, 2013 at 6:55 PM, Christian Müller <
christian.mueller@gmail.com> wrote:

> Hi Lukasz!
>
> I also do not see any issues with this announcement on the dev@ Camel
> mailing list.
> This announcement is relevant for the Camel users as it offers a awesome
> management user interface for Camel (and other frameworks/technologies).
> Even better, this product is also open source under Apache license 2.0.
> This announcement is NOT spam.
>
> Also the fact that this project is not an Apache project is NOT an issue
> at all. As the others already mentioned, we use multiple
> projects/frameworks which are developed outside the Apache community. What
> would we do if we couldn't use great frameworks/products like Spring,
> Jetty, JUnit, Pax-*, EasyMock, Quartz, ... or Jolokia?
>
> I share Guillaumes opinion that your post sounds angry. But I think there
> is really no reason for. If this product is in competition with an existing
> (Apache) project like Karaf WebConsole, this is a good thing from my point
> of view. Competition creates great products and is powering progress. And
> at the end, *IF* one of the projects will disappear because their user
> basis is getting to small, than because the user decided to use the other -
> better - tool. It's not nice to see dieing a project. It's even harder if
> it's a project you are involved with. But that's life and also has goods.
> But until now, Karaf WebConsole is alive and you can try to convince your
> users that this is the better web console for Karaf and Camel. Go out and
> fight for it!
>
> Have a nice - not so cold - week,
> Christian
>
>
> On Sat, Jan 26, 2013 at 3:11 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi Lukasz,
>>
>> I don't see any issue or spam in Guillaume's e-mail: he shared an
>> information with multiple communities, as it considers (and I think he's
>> right) that the information has value and interest for those communities.
>> Apache is not a technical project hosting, it's a set of project
>> communities. Like in all communities, we are here to share ideas and
>> discuss in a fair, smart, and kind way.
>> In Karaf (and other projects), we already discussed and use projects
>> coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc.
>> I remember to have send a couple of e-mails to inform Karaf community
>> about new projects that may interest us (Pax-CDI and Pax-JDBC for instance).
>>
>> Regards
>> JB
>>
>>
>> On 01/25/2013 08:12 PM, Łukasz Dywicki wrote:
>>
>>> Guillaume,
>>> If I'll send a mail with announcement about my amazing project, whatever
>>> it will be, to apache mailing lists I will be treat a spamer. If I will try
>>> doing that with more mailing lists - then I'll be treat as spamer - that's
>>> for sure. And that's what have you done. You have something which relates
>>> to Apache projects but it's not Apache project yet. Apache mailing lists
>>> are not for  announcement about products and projects which are not made
>>> under Apache Foundation. Please honor that.
>>>
>>> That's all in this topic from me and I don't going to discuss about any
>>> other Fuse project any more on Apache mailing lists. If you want donate
>>> hawt.io, that's fine - write incubator proposal (as it doesn't fit
>>> Karaf at all) or take it as part of other community. I don't care.
>>> For example you may wish use ServiceMix for that. You have most of
>>> commiters there. It will fit also SMX5, more over it will let you
>>> resuscitate it after two years of doing nothing.
>>>
>>> I hope I made it clear.
>>> --
>>> Cheers from cold Poland,
>>> Lukasz
>>>
>>> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25
>>> sty 2013, o godz. 19:22:
>>>
>>>  As I explained in the camel thread, I think the main benefit and
>>>> difference
>>>> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
>>>> or
>>>> linked to it in anyway.  It means the plugins can be reused for non OSGi
>>>> users, which still represent a big part of the camel and activemq user
>>>> base.
>>>> The idea would be to avoid having each project needing a different web
>>>> console at the end (and those projects can't really use the Karaf one I
>>>> think).
>>>> For Karaf, we don't really care, but the downstream projects do, and
>>>> aligning on something would help working together on the same code base.
>>>>
>>>> i don't honestly care about the location of the project itself.  We
>>>> depends
>>>> on lots of things that are not hosted at the ASF (all the pax stuff for
>>>> example) and that has never been a problem.    And I don't really think
>>>> this console belongs to Karaf at all because it's not OSGi related.   It
>>>> would actually be an adoption problem for hawtio if it would be in
>>>> Karaf as
>>>> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
>>>> James is willing to move it anywhere else atm.
>>>>
>>>> For now, given the project is not really mature, I think the best way
>>>> going
>>>> forward is to start hacking plugins inside that project itself and we'll
>>>> see over time how it evolves.  If there's a need to move each plugin
>>>> back
>>>> to the original project, it can be done, but today is really not the
>>>> day to
>>>> think about that imho, that's a minor issue, and as long as people are
>>>> able
>>>> to hack on plugins, it should be ok.   For this purpose,, github (with
>>>> forks and pull requests) is actually much easier than the ASF.
>>>>
>>>> If the hawtio project really picks up, then switching to it can be
>>>> considered, but we may want it to mature a bit more before.  Im sure
>>>> it's
>>>> still missing a lot of features we may need, and I only had a quick
>>>> look at
>>>> it, but I really like the underlying technology (a static html page,
>>>> REST
>>>> for accessing the backend, and the whole JMX tree being available
>>>> through
>>>> REST with jolokia).
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>>> >wrote:
>>>>
>>>>  AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>>>>> exactly the purpose of Karaf WebConsole: provide a kind of container
>>>>> for
>>>>> plugins/features extensions.
>>>>>
>>>>> That's my point: identify the overlap/gap between Karaf WebConsole and
>>>>> HawtIO to "communicate" and anticipate the adoption.
>>>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>>>>> projects, it would make sense to have the "Console" project at Apache.
>>>>> As a
>>>>> Karaf subproject, we can move forward and see later if it makes sense
>>>>> to
>>>>> promote as a TLP.
>>>>>
>>>>> My $0.02
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>>>>
>>>>>  I have not looked into HawtIO in detail but the idea of having a
>>>>>> general
>>>>>> console with plugins for each technology sounds good to me.
>>>>>> I also think it is good to start such a console separately in github
>>>>>> as
>>>>>> it allows for fast progress to show it works.
>>>>>>
>>>>>> For the long term I think that the generic part of such a console
>>>>>> should
>>>>>> move into an apache project. As it makes sense to keep the console
>>>>>> independent of OSGi a separate project may make sense.
>>>>>> So why should we do this in apache? The reason is that currently
>>>>>> HawtIO
>>>>>> is just another console. Only at a big community like apache we can
>>>>>> hope
>>>>>> for a project to get enough acceptance that a lot of projects
>>>>>> participate.
>>>>>>
>>>>>> So if we succeed in creating an accepted generic foundation for
>>>>>> management consoles then each of the technology plugins could be
>>>>>> developed in the respective projects.
>>>>>>
>>>>>> What do you think about this?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>>>>
>>>>>>  FYI, I'm really excited about finally being able to have a unified
>>>>>>> web
>>>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
>>>>>>> same
>>>>>>> web
>>>>>>> console can be used in a non OSGi-environment, so we can really
>>>>>>> leverage
>>>>>>> and work together on a single web console.
>>>>>>> I'd encourage everyone to have a look at it and eventually look at
>>>>>>> what's
>>>>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>>>>> integrate it.
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: James Strachan <ja...@gmail.com>
>>>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
>>>>>>> Camel,
>>>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>>>>
>>>>>>>
>>>>>>> For the impatient just look here :) http://hawt.io/
>>>>>>>
>>>>>>> Background
>>>>>>> ==========
>>>>>>> We've had numerous consoles all over the place for some time in
>>>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>>>>> custom web app to be deployed (which often is quite large); none
>>>>>>> particularly working together.
>>>>>>>
>>>>>>> We've been working on Fuse Fabric and its management console to
>>>>>>> provide a more consolidated view of a cluster of Apache integration &
>>>>>>> middleware technologies. Increasingly we're seeing our users and
>>>>>>> customers using different combinations of technologies in different
>>>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>>>>
>>>>>>> So for a few months a few of us have been working on trying to make
>>>>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like
>>>>>>> JMX
>>>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>>>>> and matched together to suite any container and combination of
>>>>>>> technologies that folks deploy in a JVM.
>>>>>>>
>>>>>>>
>>>>>>> hawtio
>>>>>>> =====
>>>>>>> The result so far is hawtio: http://hawt.io/
>>>>>>>
>>>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins
>>>>>>> for
>>>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>>>>> way.
>>>>>>>
>>>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>>>>> side component is jolokia which is a small (about 300K) REST
>>>>>>> connector
>>>>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>>>>> could be served from anywhere so doesn't need to be deployed in each
>>>>>>> JVM).
>>>>>>>
>>>>>>> Its based around a plugin architecture:
>>>>>>> http://hawt.io/developers/****plugins.html<http://hawt.io/developers/**plugins.html>
>>>>>>> <http://hawt.io/**developers/plugins.html<http://hawt.io/developers/plugins.html>
>>>>>>> >
>>>>>>>
>>>>>>> so its easy to add new plugins for any kind of technology. A plugin
>>>>>>> is
>>>>>>> pretty much anything that runs in a browser.
>>>>>>>
>>>>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>>>>> UI can update in real time as you deploy new things into a JVM!
>>>>>>>
>>>>>>>
>>>>>>> hawtio, the hawt camel rider
>>>>>>> ======================
>>>>>>> A quick summary of the current features for camel folks:
>>>>>>>
>>>>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>>>>> up it adds an Integration tab which shows all the camel contexts
>>>>>>> running.
>>>>>>>
>>>>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>>>>> tab lets you visualise the real time metrics.
>>>>>>>
>>>>>>> * You can create new endpoints; browse endpoints which are browsable
>>>>>>> &
>>>>>>> send messages to endpoints (with syntax editing support for JSON /
>>>>>>> XML
>>>>>>> / YAML / properties)
>>>>>>>
>>>>>>> * You can visualise all the camel routes or a specific camel route
>>>>>>> for
>>>>>>> a context in the Diagram tab and see real time metrics of how many
>>>>>>> messages are passing through each step on the diagram. e.g.
>>>>>>> https://raw.github.com/hawtio/****hawtio/master/website/src/**<https://raw.github.com/hawtio/**hawtio/master/website/src/**>
>>>>>>> images/screenshots/camelRoute.****png<https://raw.github.com/**
>>>>>>> hawtio/hawtio/master/website/**src/images/screenshots/**
>>>>>>> camelRoute.png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>>>> >
>>>>>>>
>>>>>>> * Clicking on a Route allows you to Trace it; when tracing if you
>>>>>>> send
>>>>>>> a message into a route then it captures a copy of the message at each
>>>>>>> point through the route. So you can step through (scroll/click
>>>>>>> through
>>>>>>> the table) a route and see the message contents and how the message
>>>>>>> flows through the EIPs - highlighting where on the diagram each
>>>>>>> message is. This is very handy for figuring out why your route
>>>>>>> doesn't
>>>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>>>>> go where you expected.
>>>>>>>
>>>>>>> In general most of the runtime features of the open source Fuse IDE
>>>>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>>>>> available in a web browser.
>>>>>>>
>>>>>>>
>>>>>>> Summary
>>>>>>> =======
>>>>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>>>>> urge you to give it a try. We love contributions and feedback!
>>>>>>> http://hawt.io/contributing/****index.html<http://hawt.io/contributing/**index.html>
>>>>>>> <http://hawt.io/**contributing/index.html<http://hawt.io/contributing/index.html>
>>>>>>> >
>>>>>>>
>>>>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>>>>> https://github.com/hawtio/****hawtio/issues?labels=camel&**<https://github.com/hawtio/**hawtio/issues?labels=camel&**>
>>>>>>> page=1&sort=updated&state=**open<https://github.com/**
>>>>>>> hawtio/hawtio/issues?labels=**camel&page=1&sort=updated&**state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>>>> >
>>>>>>>
>>>>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>>>>> should be able to expose existing web apps/consoles as links inside
>>>>>>> hawtio too BTW.
>>>>>>>
>>>>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>>>>
>>>>>>> --
>>>>>>> James
>>>>>>> -------
>>>>>>> Red Hat
>>>>>>>
>>>>>>> Email: jstracha@redhat.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: jstrachan, fusenews
>>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>>
>>>>>>> Open Source Integration
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
>
>


--

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
Hi Lukasz!

I also do not see any issues with this announcement on the dev@ Camel
mailing list.
This announcement is relevant for the Camel users as it offers a awesome
management user interface for Camel (and other frameworks/technologies).
Even better, this product is also open source under Apache license 2.0.
This announcement is NOT spam.

Also the fact that this project is not an Apache project is NOT an issue at
all. As the others already mentioned, we use multiple projects/frameworks
which are developed outside the Apache community. What would we do if we
couldn't use great frameworks/products like Spring, Jetty, JUnit, Pax-*,
EasyMock, Quartz, ... or Jolokia?

I share Guillaumes opinion that your post sounds angry. But I think there
is really no reason for. If this product is in competition with an existing
(Apache) project like Karaf WebConsole, this is a good thing from my point
of view. Competition creates great products and is powering progress. And
at the end, *IF* one of the projects will disappear because their user
basis is getting to small, than because the user decided to use the other -
better - tool. It's not nice to see dieing a project. It's even harder if
it's a project you are involved with. But that's life and also has goods.
But until now, Karaf WebConsole is alive and you can try to convince your
users that this is the better web console for Karaf and Camel. Go out and
fight for it!

Have a nice - not so cold - week,
Christian

On Sat, Jan 26, 2013 at 3:11 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:

> Hi Lukasz,
>
> I don't see any issue or spam in Guillaume's e-mail: he shared an
> information with multiple communities, as it considers (and I think he's
> right) that the information has value and interest for those communities.
> Apache is not a technical project hosting, it's a set of project
> communities. Like in all communities, we are here to share ideas and
> discuss in a fair, smart, and kind way.
> In Karaf (and other projects), we already discussed and use projects
> coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc.
> I remember to have send a couple of e-mails to inform Karaf community
> about new projects that may interest us (Pax-CDI and Pax-JDBC for instance).
>
> Regards
> JB
>
>
> On 01/25/2013 08:12 PM, Łukasz Dywicki wrote:
>
>> Guillaume,
>> If I'll send a mail with announcement about my amazing project, whatever
>> it will be, to apache mailing lists I will be treat a spamer. If I will try
>> doing that with more mailing lists - then I'll be treat as spamer - that's
>> for sure. And that's what have you done. You have something which relates
>> to Apache projects but it's not Apache project yet. Apache mailing lists
>> are not for  announcement about products and projects which are not made
>> under Apache Foundation. Please honor that.
>>
>> That's all in this topic from me and I don't going to discuss about any
>> other Fuse project any more on Apache mailing lists. If you want donate
>> hawt.io, that's fine - write incubator proposal (as it doesn't fit Karaf
>> at all) or take it as part of other community. I don't care.
>> For example you may wish use ServiceMix for that. You have most of
>> commiters there. It will fit also SMX5, more over it will let you
>> resuscitate it after two years of doing nothing.
>>
>> I hope I made it clear.
>> --
>> Cheers from cold Poland,
>> Lukasz
>>
>> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25
>> sty 2013, o godz. 19:22:
>>
>>  As I explained in the camel thread, I think the main benefit and
>>> difference
>>> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
>>> or
>>> linked to it in anyway.  It means the plugins can be reused for non OSGi
>>> users, which still represent a big part of the camel and activemq user
>>> base.
>>> The idea would be to avoid having each project needing a different web
>>> console at the end (and those projects can't really use the Karaf one I
>>> think).
>>> For Karaf, we don't really care, but the downstream projects do, and
>>> aligning on something would help working together on the same code base.
>>>
>>> i don't honestly care about the location of the project itself.  We
>>> depends
>>> on lots of things that are not hosted at the ASF (all the pax stuff for
>>> example) and that has never been a problem.    And I don't really think
>>> this console belongs to Karaf at all because it's not OSGi related.   It
>>> would actually be an adoption problem for hawtio if it would be in Karaf
>>> as
>>> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
>>> James is willing to move it anywhere else atm.
>>>
>>> For now, given the project is not really mature, I think the best way
>>> going
>>> forward is to start hacking plugins inside that project itself and we'll
>>> see over time how it evolves.  If there's a need to move each plugin back
>>> to the original project, it can be done, but today is really not the day
>>> to
>>> think about that imho, that's a minor issue, and as long as people are
>>> able
>>> to hack on plugins, it should be ok.   For this purpose,, github (with
>>> forks and pull requests) is actually much easier than the ASF.
>>>
>>> If the hawtio project really picks up, then switching to it can be
>>> considered, but we may want it to mature a bit more before.  Im sure it's
>>> still missing a lot of features we may need, and I only had a quick look
>>> at
>>> it, but I really like the underlying technology (a static html page, REST
>>> for accessing the backend, and the whole JMX tree being available through
>>> REST with jolokia).
>>>
>>>
>>>
>>>
>>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>>  AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>>>> exactly the purpose of Karaf WebConsole: provide a kind of container for
>>>> plugins/features extensions.
>>>>
>>>> That's my point: identify the overlap/gap between Karaf WebConsole and
>>>> HawtIO to "communicate" and anticipate the adoption.
>>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>>>> projects, it would make sense to have the "Console" project at Apache.
>>>> As a
>>>> Karaf subproject, we can move forward and see later if it makes sense to
>>>> promote as a TLP.
>>>>
>>>> My $0.02
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>>>
>>>>  I have not looked into HawtIO in detail but the idea of having a
>>>>> general
>>>>> console with plugins for each technology sounds good to me.
>>>>> I also think it is good to start such a console separately in github as
>>>>> it allows for fast progress to show it works.
>>>>>
>>>>> For the long term I think that the generic part of such a console
>>>>> should
>>>>> move into an apache project. As it makes sense to keep the console
>>>>> independent of OSGi a separate project may make sense.
>>>>> So why should we do this in apache? The reason is that currently HawtIO
>>>>> is just another console. Only at a big community like apache we can
>>>>> hope
>>>>> for a project to get enough acceptance that a lot of projects
>>>>> participate.
>>>>>
>>>>> So if we succeed in creating an accepted generic foundation for
>>>>> management consoles then each of the technology plugins could be
>>>>> developed in the respective projects.
>>>>>
>>>>> What do you think about this?
>>>>>
>>>>> Christian
>>>>>
>>>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>>>
>>>>>  FYI, I'm really excited about finally being able to have a unified web
>>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
>>>>>> same
>>>>>> web
>>>>>> console can be used in a non OSGi-environment, so we can really
>>>>>> leverage
>>>>>> and work together on a single web console.
>>>>>> I'd encourage everyone to have a look at it and eventually look at
>>>>>> what's
>>>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>>>> integrate it.
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: James Strachan <ja...@gmail.com>
>>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
>>>>>> Camel,
>>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>>>
>>>>>>
>>>>>> For the impatient just look here :) http://hawt.io/
>>>>>>
>>>>>> Background
>>>>>> ==========
>>>>>> We've had numerous consoles all over the place for some time in
>>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>>>> custom web app to be deployed (which often is quite large); none
>>>>>> particularly working together.
>>>>>>
>>>>>> We've been working on Fuse Fabric and its management console to
>>>>>> provide a more consolidated view of a cluster of Apache integration &
>>>>>> middleware technologies. Increasingly we're seeing our users and
>>>>>> customers using different combinations of technologies in different
>>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>>>
>>>>>> So for a few months a few of us have been working on trying to make
>>>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>>>> and matched together to suite any container and combination of
>>>>>> technologies that folks deploy in a JVM.
>>>>>>
>>>>>>
>>>>>> hawtio
>>>>>> =====
>>>>>> The result so far is hawtio: http://hawt.io/
>>>>>>
>>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>>>> way.
>>>>>>
>>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>>>> side component is jolokia which is a small (about 300K) REST connector
>>>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>>>> could be served from anywhere so doesn't need to be deployed in each
>>>>>> JVM).
>>>>>>
>>>>>> Its based around a plugin architecture:
>>>>>> http://hawt.io/developers/****plugins.html<http://hawt.io/developers/**plugins.html>
>>>>>> <http://hawt.io/**developers/plugins.html<http://hawt.io/developers/plugins.html>
>>>>>> >
>>>>>>
>>>>>> so its easy to add new plugins for any kind of technology. A plugin is
>>>>>> pretty much anything that runs in a browser.
>>>>>>
>>>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>>>> UI can update in real time as you deploy new things into a JVM!
>>>>>>
>>>>>>
>>>>>> hawtio, the hawt camel rider
>>>>>> ======================
>>>>>> A quick summary of the current features for camel folks:
>>>>>>
>>>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>>>> up it adds an Integration tab which shows all the camel contexts
>>>>>> running.
>>>>>>
>>>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>>>> tab lets you visualise the real time metrics.
>>>>>>
>>>>>> * You can create new endpoints; browse endpoints which are browsable &
>>>>>> send messages to endpoints (with syntax editing support for JSON / XML
>>>>>> / YAML / properties)
>>>>>>
>>>>>> * You can visualise all the camel routes or a specific camel route for
>>>>>> a context in the Diagram tab and see real time metrics of how many
>>>>>> messages are passing through each step on the diagram. e.g.
>>>>>> https://raw.github.com/hawtio/****hawtio/master/website/src/**<https://raw.github.com/hawtio/**hawtio/master/website/src/**>
>>>>>> images/screenshots/camelRoute.****png<https://raw.github.com/**
>>>>>> hawtio/hawtio/master/website/**src/images/screenshots/**
>>>>>> camelRoute.png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>>> >
>>>>>>
>>>>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>>>>> a message into a route then it captures a copy of the message at each
>>>>>> point through the route. So you can step through (scroll/click through
>>>>>> the table) a route and see the message contents and how the message
>>>>>> flows through the EIPs - highlighting where on the diagram each
>>>>>> message is. This is very handy for figuring out why your route doesn't
>>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>>>> go where you expected.
>>>>>>
>>>>>> In general most of the runtime features of the open source Fuse IDE
>>>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>>>> available in a web browser.
>>>>>>
>>>>>>
>>>>>> Summary
>>>>>> =======
>>>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>>>> urge you to give it a try. We love contributions and feedback!
>>>>>> http://hawt.io/contributing/****index.html<http://hawt.io/contributing/**index.html>
>>>>>> <http://hawt.io/**contributing/index.html<http://hawt.io/contributing/index.html>
>>>>>> >
>>>>>>
>>>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>>>> https://github.com/hawtio/****hawtio/issues?labels=camel&**<https://github.com/hawtio/**hawtio/issues?labels=camel&**>
>>>>>> page=1&sort=updated&state=**open<https://github.com/**
>>>>>> hawtio/hawtio/issues?labels=**camel&page=1&sort=updated&**state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>>> >
>>>>>>
>>>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>>>> should be able to expose existing web apps/consoles as links inside
>>>>>> hawtio too BTW.
>>>>>>
>>>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> Red Hat
>>>>>>
>>>>>> Email: jstracha@redhat.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: jstrachan, fusenews
>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
Hi Lukasz!

I also do not see any issues with this announcement on the dev@ Camel
mailing list.
This announcement is relevant for the Camel users as it offers a awesome
management user interface for Camel (and other frameworks/technologies).
Even better, this product is also open source under Apache license 2.0.
This announcement is NOT spam.

Also the fact that this project is not an Apache project is NOT an issue at
all. As the others already mentioned, we use multiple projects/frameworks
which are developed outside the Apache community. What would we do if we
couldn't use great frameworks/products like Spring, Jetty, JUnit, Pax-*,
EasyMock, Quartz, ... or Jolokia?

I share Guillaumes opinion that your post sounds angry. But I think there
is really no reason for. If this product is in competition with an existing
(Apache) project like Karaf WebConsole, this is a good thing from my point
of view. Competition creates great products and is powering progress. And
at the end, *IF* one of the projects will disappear because their user
basis is getting to small, than because the user decided to use the other -
better - tool. It's not nice to see dieing a project. It's even harder if
it's a project you are involved with. But that's life and also has goods.
But until now, Karaf WebConsole is alive and you can try to convince your
users that this is the better web console for Karaf and Camel. Go out and
fight for it!

Have a nice - not so cold - week,
Christian

On Sat, Jan 26, 2013 at 3:11 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:

> Hi Lukasz,
>
> I don't see any issue or spam in Guillaume's e-mail: he shared an
> information with multiple communities, as it considers (and I think he's
> right) that the information has value and interest for those communities.
> Apache is not a technical project hosting, it's a set of project
> communities. Like in all communities, we are here to share ideas and
> discuss in a fair, smart, and kind way.
> In Karaf (and other projects), we already discussed and use projects
> coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc.
> I remember to have send a couple of e-mails to inform Karaf community
> about new projects that may interest us (Pax-CDI and Pax-JDBC for instance).
>
> Regards
> JB
>
>
> On 01/25/2013 08:12 PM, Łukasz Dywicki wrote:
>
>> Guillaume,
>> If I'll send a mail with announcement about my amazing project, whatever
>> it will be, to apache mailing lists I will be treat a spamer. If I will try
>> doing that with more mailing lists - then I'll be treat as spamer - that's
>> for sure. And that's what have you done. You have something which relates
>> to Apache projects but it's not Apache project yet. Apache mailing lists
>> are not for  announcement about products and projects which are not made
>> under Apache Foundation. Please honor that.
>>
>> That's all in this topic from me and I don't going to discuss about any
>> other Fuse project any more on Apache mailing lists. If you want donate
>> hawt.io, that's fine - write incubator proposal (as it doesn't fit Karaf
>> at all) or take it as part of other community. I don't care.
>> For example you may wish use ServiceMix for that. You have most of
>> commiters there. It will fit also SMX5, more over it will let you
>> resuscitate it after two years of doing nothing.
>>
>> I hope I made it clear.
>> --
>> Cheers from cold Poland,
>> Lukasz
>>
>> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25
>> sty 2013, o godz. 19:22:
>>
>>  As I explained in the camel thread, I think the main benefit and
>>> difference
>>> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
>>> or
>>> linked to it in anyway.  It means the plugins can be reused for non OSGi
>>> users, which still represent a big part of the camel and activemq user
>>> base.
>>> The idea would be to avoid having each project needing a different web
>>> console at the end (and those projects can't really use the Karaf one I
>>> think).
>>> For Karaf, we don't really care, but the downstream projects do, and
>>> aligning on something would help working together on the same code base.
>>>
>>> i don't honestly care about the location of the project itself.  We
>>> depends
>>> on lots of things that are not hosted at the ASF (all the pax stuff for
>>> example) and that has never been a problem.    And I don't really think
>>> this console belongs to Karaf at all because it's not OSGi related.   It
>>> would actually be an adoption problem for hawtio if it would be in Karaf
>>> as
>>> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
>>> James is willing to move it anywhere else atm.
>>>
>>> For now, given the project is not really mature, I think the best way
>>> going
>>> forward is to start hacking plugins inside that project itself and we'll
>>> see over time how it evolves.  If there's a need to move each plugin back
>>> to the original project, it can be done, but today is really not the day
>>> to
>>> think about that imho, that's a minor issue, and as long as people are
>>> able
>>> to hack on plugins, it should be ok.   For this purpose,, github (with
>>> forks and pull requests) is actually much easier than the ASF.
>>>
>>> If the hawtio project really picks up, then switching to it can be
>>> considered, but we may want it to mature a bit more before.  Im sure it's
>>> still missing a lot of features we may need, and I only had a quick look
>>> at
>>> it, but I really like the underlying technology (a static html page, REST
>>> for accessing the backend, and the whole JMX tree being available through
>>> REST with jolokia).
>>>
>>>
>>>
>>>
>>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>>  AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>>>> exactly the purpose of Karaf WebConsole: provide a kind of container for
>>>> plugins/features extensions.
>>>>
>>>> That's my point: identify the overlap/gap between Karaf WebConsole and
>>>> HawtIO to "communicate" and anticipate the adoption.
>>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>>>> projects, it would make sense to have the "Console" project at Apache.
>>>> As a
>>>> Karaf subproject, we can move forward and see later if it makes sense to
>>>> promote as a TLP.
>>>>
>>>> My $0.02
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>>>
>>>>  I have not looked into HawtIO in detail but the idea of having a
>>>>> general
>>>>> console with plugins for each technology sounds good to me.
>>>>> I also think it is good to start such a console separately in github as
>>>>> it allows for fast progress to show it works.
>>>>>
>>>>> For the long term I think that the generic part of such a console
>>>>> should
>>>>> move into an apache project. As it makes sense to keep the console
>>>>> independent of OSGi a separate project may make sense.
>>>>> So why should we do this in apache? The reason is that currently HawtIO
>>>>> is just another console. Only at a big community like apache we can
>>>>> hope
>>>>> for a project to get enough acceptance that a lot of projects
>>>>> participate.
>>>>>
>>>>> So if we succeed in creating an accepted generic foundation for
>>>>> management consoles then each of the technology plugins could be
>>>>> developed in the respective projects.
>>>>>
>>>>> What do you think about this?
>>>>>
>>>>> Christian
>>>>>
>>>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>>>
>>>>>  FYI, I'm really excited about finally being able to have a unified web
>>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
>>>>>> same
>>>>>> web
>>>>>> console can be used in a non OSGi-environment, so we can really
>>>>>> leverage
>>>>>> and work together on a single web console.
>>>>>> I'd encourage everyone to have a look at it and eventually look at
>>>>>> what's
>>>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>>>> integrate it.
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: James Strachan <ja...@gmail.com>
>>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
>>>>>> Camel,
>>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>>>
>>>>>>
>>>>>> For the impatient just look here :) http://hawt.io/
>>>>>>
>>>>>> Background
>>>>>> ==========
>>>>>> We've had numerous consoles all over the place for some time in
>>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>>>> custom web app to be deployed (which often is quite large); none
>>>>>> particularly working together.
>>>>>>
>>>>>> We've been working on Fuse Fabric and its management console to
>>>>>> provide a more consolidated view of a cluster of Apache integration &
>>>>>> middleware technologies. Increasingly we're seeing our users and
>>>>>> customers using different combinations of technologies in different
>>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>>>
>>>>>> So for a few months a few of us have been working on trying to make
>>>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>>>> and matched together to suite any container and combination of
>>>>>> technologies that folks deploy in a JVM.
>>>>>>
>>>>>>
>>>>>> hawtio
>>>>>> =====
>>>>>> The result so far is hawtio: http://hawt.io/
>>>>>>
>>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>>>> way.
>>>>>>
>>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>>>> side component is jolokia which is a small (about 300K) REST connector
>>>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>>>> could be served from anywhere so doesn't need to be deployed in each
>>>>>> JVM).
>>>>>>
>>>>>> Its based around a plugin architecture:
>>>>>> http://hawt.io/developers/****plugins.html<http://hawt.io/developers/**plugins.html>
>>>>>> <http://hawt.io/**developers/plugins.html<http://hawt.io/developers/plugins.html>
>>>>>> >
>>>>>>
>>>>>> so its easy to add new plugins for any kind of technology. A plugin is
>>>>>> pretty much anything that runs in a browser.
>>>>>>
>>>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>>>> UI can update in real time as you deploy new things into a JVM!
>>>>>>
>>>>>>
>>>>>> hawtio, the hawt camel rider
>>>>>> ======================
>>>>>> A quick summary of the current features for camel folks:
>>>>>>
>>>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>>>> up it adds an Integration tab which shows all the camel contexts
>>>>>> running.
>>>>>>
>>>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>>>> tab lets you visualise the real time metrics.
>>>>>>
>>>>>> * You can create new endpoints; browse endpoints which are browsable &
>>>>>> send messages to endpoints (with syntax editing support for JSON / XML
>>>>>> / YAML / properties)
>>>>>>
>>>>>> * You can visualise all the camel routes or a specific camel route for
>>>>>> a context in the Diagram tab and see real time metrics of how many
>>>>>> messages are passing through each step on the diagram. e.g.
>>>>>> https://raw.github.com/hawtio/****hawtio/master/website/src/**<https://raw.github.com/hawtio/**hawtio/master/website/src/**>
>>>>>> images/screenshots/camelRoute.****png<https://raw.github.com/**
>>>>>> hawtio/hawtio/master/website/**src/images/screenshots/**
>>>>>> camelRoute.png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>>> >
>>>>>>
>>>>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>>>>> a message into a route then it captures a copy of the message at each
>>>>>> point through the route. So you can step through (scroll/click through
>>>>>> the table) a route and see the message contents and how the message
>>>>>> flows through the EIPs - highlighting where on the diagram each
>>>>>> message is. This is very handy for figuring out why your route doesn't
>>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>>>> go where you expected.
>>>>>>
>>>>>> In general most of the runtime features of the open source Fuse IDE
>>>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>>>> available in a web browser.
>>>>>>
>>>>>>
>>>>>> Summary
>>>>>> =======
>>>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>>>> urge you to give it a try. We love contributions and feedback!
>>>>>> http://hawt.io/contributing/****index.html<http://hawt.io/contributing/**index.html>
>>>>>> <http://hawt.io/**contributing/index.html<http://hawt.io/contributing/index.html>
>>>>>> >
>>>>>>
>>>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>>>> https://github.com/hawtio/****hawtio/issues?labels=camel&**<https://github.com/hawtio/**hawtio/issues?labels=camel&**>
>>>>>> page=1&sort=updated&state=**open<https://github.com/**
>>>>>> hawtio/hawtio/issues?labels=**camel&page=1&sort=updated&**state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>>> >
>>>>>>
>>>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>>>> should be able to expose existing web apps/consoles as links inside
>>>>>> hawtio too BTW.
>>>>>>
>>>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> Red Hat
>>>>>>
>>>>>> Email: jstracha@redhat.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: jstrachan, fusenews
>>>>>> Blog: http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Lukasz,

I don't see any issue or spam in Guillaume's e-mail: he shared an 
information with multiple communities, as it considers (and I think he's 
right) that the information has value and interest for those communities.
Apache is not a technical project hosting, it's a set of project 
communities. Like in all communities, we are here to share ideas and 
discuss in a fair, smart, and kind way.
In Karaf (and other projects), we already discussed and use projects 
coming from "outside". It's long list: Cellar, EIK, Pax*, jledit, etc.
I remember to have send a couple of e-mails to inform Karaf community 
about new projects that may interest us (Pax-CDI and Pax-JDBC for instance).

Regards
JB

On 01/25/2013 08:12 PM, Łukasz Dywicki wrote:
> Guillaume,
> If I'll send a mail with announcement about my amazing project, whatever it will be, to apache mailing lists I will be treat a spamer. If I will try doing that with more mailing lists - then I'll be treat as spamer - that's for sure. And that's what have you done. You have something which relates to Apache projects but it's not Apache project yet. Apache mailing lists are not for  announcement about products and projects which are not made under Apache Foundation. Please honor that.
>
> That's all in this topic from me and I don't going to discuss about any other Fuse project any more on Apache mailing lists. If you want donate hawt.io, that's fine - write incubator proposal (as it doesn't fit Karaf at all) or take it as part of other community. I don't care.
> For example you may wish use ServiceMix for that. You have most of commiters there. It will fit also SMX5, more over it will let you resuscitate it after two years of doing nothing.
>
> I hope I made it clear.
> --
> Cheers from cold Poland,
> Lukasz
>
> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25 sty 2013, o godz. 19:22:
>
>> As I explained in the camel thread, I think the main benefit and difference
>> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied or
>> linked to it in anyway.  It means the plugins can be reused for non OSGi
>> users, which still represent a big part of the camel and activemq user base.
>> The idea would be to avoid having each project needing a different web
>> console at the end (and those projects can't really use the Karaf one I
>> think).
>> For Karaf, we don't really care, but the downstream projects do, and
>> aligning on something would help working together on the same code base.
>>
>> i don't honestly care about the location of the project itself.  We depends
>> on lots of things that are not hosted at the ASF (all the pax stuff for
>> example) and that has never been a problem.    And I don't really think
>> this console belongs to Karaf at all because it's not OSGi related.   It
>> would actually be an adoption problem for hawtio if it would be in Karaf as
>> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
>> James is willing to move it anywhere else atm.
>>
>> For now, given the project is not really mature, I think the best way going
>> forward is to start hacking plugins inside that project itself and we'll
>> see over time how it evolves.  If there's a need to move each plugin back
>> to the original project, it can be done, but today is really not the day to
>> think about that imho, that's a minor issue, and as long as people are able
>> to hack on plugins, it should be ok.   For this purpose,, github (with
>> forks and pull requests) is actually much easier than the ASF.
>>
>> If the hawtio project really picks up, then switching to it can be
>> considered, but we may want it to mature a bit more before.  Im sure it's
>> still missing a lot of features we may need, and I only had a quick look at
>> it, but I really like the underlying technology (a static html page, REST
>> for accessing the backend, and the whole JMX tree being available through
>> REST with jolokia).
>>
>>
>>
>>
>> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>
>>> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>>> exactly the purpose of Karaf WebConsole: provide a kind of container for
>>> plugins/features extensions.
>>>
>>> That's my point: identify the overlap/gap between Karaf WebConsole and
>>> HawtIO to "communicate" and anticipate the adoption.
>>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>>> projects, it would make sense to have the "Console" project at Apache. As a
>>> Karaf subproject, we can move forward and see later if it makes sense to
>>> promote as a TLP.
>>>
>>> My $0.02
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>>
>>>> I have not looked into HawtIO in detail but the idea of having a general
>>>> console with plugins for each technology sounds good to me.
>>>> I also think it is good to start such a console separately in github as
>>>> it allows for fast progress to show it works.
>>>>
>>>> For the long term I think that the generic part of such a console should
>>>> move into an apache project. As it makes sense to keep the console
>>>> independent of OSGi a separate project may make sense.
>>>> So why should we do this in apache? The reason is that currently HawtIO
>>>> is just another console. Only at a big community like apache we can hope
>>>> for a project to get enough acceptance that a lot of projects participate.
>>>>
>>>> So if we succeed in creating an accepted generic foundation for
>>>> management consoles then each of the technology plugins could be
>>>> developed in the respective projects.
>>>>
>>>> What do you think about this?
>>>>
>>>> Christian
>>>>
>>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>>
>>>>> FYI, I'm really excited about finally being able to have a unified web
>>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the same
>>>>> web
>>>>> console can be used in a non OSGi-environment, so we can really leverage
>>>>> and work together on a single web console.
>>>>> I'd encourage everyone to have a look at it and eventually look at what's
>>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>>> integrate it.
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: James Strachan <ja...@gmail.com>
>>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
>>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>>
>>>>>
>>>>> For the impatient just look here :) http://hawt.io/
>>>>>
>>>>> Background
>>>>> ==========
>>>>> We've had numerous consoles all over the place for some time in
>>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>>> custom web app to be deployed (which often is quite large); none
>>>>> particularly working together.
>>>>>
>>>>> We've been working on Fuse Fabric and its management console to
>>>>> provide a more consolidated view of a cluster of Apache integration &
>>>>> middleware technologies. Increasingly we're seeing our users and
>>>>> customers using different combinations of technologies in different
>>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>>
>>>>> So for a few months a few of us have been working on trying to make
>>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>>> and matched together to suite any container and combination of
>>>>> technologies that folks deploy in a JVM.
>>>>>
>>>>>
>>>>> hawtio
>>>>> =====
>>>>> The result so far is hawtio: http://hawt.io/
>>>>>
>>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>>> way.
>>>>>
>>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>>> side component is jolokia which is a small (about 300K) REST connector
>>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>>> could be served from anywhere so doesn't need to be deployed in each
>>>>> JVM).
>>>>>
>>>>> Its based around a plugin architecture:
>>>>> http://hawt.io/developers/**plugins.html<http://hawt.io/developers/plugins.html>
>>>>>
>>>>> so its easy to add new plugins for any kind of technology. A plugin is
>>>>> pretty much anything that runs in a browser.
>>>>>
>>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>>> UI can update in real time as you deploy new things into a JVM!
>>>>>
>>>>>
>>>>> hawtio, the hawt camel rider
>>>>> ======================
>>>>> A quick summary of the current features for camel folks:
>>>>>
>>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>>> up it adds an Integration tab which shows all the camel contexts
>>>>> running.
>>>>>
>>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>>> tab lets you visualise the real time metrics.
>>>>>
>>>>> * You can create new endpoints; browse endpoints which are browsable &
>>>>> send messages to endpoints (with syntax editing support for JSON / XML
>>>>> / YAML / properties)
>>>>>
>>>>> * You can visualise all the camel routes or a specific camel route for
>>>>> a context in the Diagram tab and see real time metrics of how many
>>>>> messages are passing through each step on the diagram. e.g.
>>>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
>>>>> images/screenshots/camelRoute.**png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>>
>>>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>>>> a message into a route then it captures a copy of the message at each
>>>>> point through the route. So you can step through (scroll/click through
>>>>> the table) a route and see the message contents and how the message
>>>>> flows through the EIPs - highlighting where on the diagram each
>>>>> message is. This is very handy for figuring out why your route doesn't
>>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>>> go where you expected.
>>>>>
>>>>> In general most of the runtime features of the open source Fuse IDE
>>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>>> available in a web browser.
>>>>>
>>>>>
>>>>> Summary
>>>>> =======
>>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>>> urge you to give it a try. We love contributions and feedback!
>>>>> http://hawt.io/contributing/**index.html<http://hawt.io/contributing/index.html>
>>>>>
>>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
>>>>> page=1&sort=updated&state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>>
>>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>>> should be able to expose existing web apps/consoles as links inside
>>>>> hawtio too BTW.
>>>>>
>>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> Red Hat
>>>>>
>>>>> Email: jstracha@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: jstrachan, fusenews
>>>>> Blog: http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
Will have a look at hawtio over the weekend...
This thread has to cool down bit. Looking for technical discussions and
proposals how to move forward.

Best,
Christian

Sent from a mobile device
Am 25.01.2013 22:30 schrieb "Guillaume Nodet" <gn...@gmail.com>:

> On Fri, Jan 25, 2013 at 8:12 PM, Łukasz Dywicki <lu...@code-house.org>
> wrote:
>
> > Guillaume,
> > If I'll send a mail with announcement about my amazing project, whatever
> > it will be, to apache mailing lists I will be treat a spamer.  If I will
> > try doing that with more mailing lists - then I'll be treat as spamer -
> > that's for sure. And that's what have you done.
>
>
> It's not even MY project.  James only talked about it to me a few days ago
> and I have never committed anything to it, go check the log if you want.
>
> Such a person would be a spammer if it keeps sending out-of-topic emails
> for no reason.  Do I have to remind you that James sent that annoucement
> email because I mentioned this project on the mailing list a few hours
> before, just saying we could have a look at it.   It was relevant to the
> discussion, because we were talking about the future web console for Camel
> 3.   People started talking about hawtio, so it totally made sense for
> James to start a separate thread about it instead of polluting the camel 3
> discussion and give a few explanations about what hawtio is.  When we talk
> about web console, talking about web console technologies is not really
> spamming to me.  It's just technical discussion.
>
> So no, if you're start a project outside the ASF that could be beneficial
> for the project, you really should talk about it.  Not doing that is a
> disservice to the project and the community.
>
>
> >  You have something which relates to Apache projects but it's not Apache
> > project yet.
>
>
> It may not even become an ASF project, nobody ever talked about that.  So I
> really don't get the "yet" part.  Really, I don't.
>
>
> > Apache mailing lists are not for  announcement about products and
> projects
> > which are not made under Apache Foundation. Please honor that.
> >
>
> Well, then you don't understand what the ASF is.  It's not a silo with a a
> rule enforcement about not talking about other projects, not using them, or
> enforcing solely the use of other ASF projects.   Remember the mantra
> "community over code" ? The ASF is about community.   The ASF does not have
> any technical steering committee  does not forbid competing projects inside
> the ASF (there are a bunch of those already).  An ASF projects is free to
> use whatever other project it wishes, as long as the license is compatible
> with ASL.
>
> For example, we do use a lot of pax stuff (logging, web, etc..) which some
> of us are heavily involved in.   Some of us are also involved in other
> projets that we use which come from the ASF (mina, felix, aries).    We're
> also using jetty and not tomcat (where none of us is really involved in),
> so what's your point ?  Some very good projects are developped outside the
> ASF.  ASF is one style of open-source development, it's not either the only
> one, nor does it have to be.
>
> If we can't discuss and disagree over things in a calm way, then there's a
> problem, for sure.
>
>
> > That's all in this topic from me and I don't going to discuss about any
> > other Fuse project any more on Apache mailing lists.
>
>
> We're not discussing a Fuse project.  James starts all kind of projects
> each year.  Some of them are good and pick up, some of them don't.  We
> talked about this project because it makes sense for the communities and
> projects here at the ASF.   Forbidding to talk about it is just nonsense.
>
> If you want another example, I'm currently trying to have weld-osgi, the
> cdi container, running correctly in OSGi and Karaf.  It's not an ASF
> project, and the discussion about CDI never came up on Karaf dev list.
>  Would it have been the case, I would have talked about what I'm doing.
>  And that would have been relevant.  Another thing I have in mind is to
> upgrade to OSGi r5 at some point in the future, and I may look at the
> repository implementation David B wrote in jboss-osgi to see if it fits my
> needs.   If it does not, I'll intend to either modify it if I think it's
> doable, or even rewrite a new one if I think it makes more sense.   Is that
> also a crime for you ?
>
>
> > If you want donate hawt.io, that's fine - write incubator proposal (as
> it
> > doesn't fit Karaf at all) or take it as part of other community. I don't
> > care.
>
>
> But nobody talked about donating hawtio anywhere at this point.  I even
> said a few hours ago I don't think it's a good idea, at least at the
> moment.   I don't really have any saying in this anymore, given I haven't
> even touched it.
>
>
> > For example you may wish use ServiceMix for that. You have most of
> > committers there. It will fit also SMX5, more over it will let you
> > resuscitate it after two years of doing nothing.
> >
>
> Not sure I get your point here.  Should I be ashamed of not having worked a
> lot on ServiceMix recently after having worked mostly full time on it for 5
> years ? You must be kidding, right ?  Anyway, no ASF committer is bound to
> a project and the people are free to work or not work on anything they
> want.  The value of ServiceMix went away, first when Camel was created,
> then when the Kernel was moved to a TLP in Karaf.  Everyone knows that,
> even if it took time to admit it.  And btw, I don't see how hawtio would
> fit in ServiceMix at all.  Fwiw, I don't think it fits in any TLP I can
> think of right now.  Again, everything does not *have to* be at the ASF:
> the ASF does not try to rule the world.
>
>
> > I hope I made it clear.
> >
>
> No, not really.  And that time, I hope nobody is accusing James or me to
> try to push a hidden company agenda : do I have to remind you that you and
> I are actually working for the same company ?  Maybe the problem is there
> has been very few hot technical discussions in the projects we've worked
> at.
>
> Anyway, this email is pointless and too much time consuming for me (I'm
> usually spending a *lot* of time writing such emails to make sure I won't
> regret a single word of it, which does not always succeed btw).  So please,
> have a break during the weekend, stop attacking people and if you have
> technical arguments, raise them so that we can get the discussion going
> with sane arguments.
>
> --
> > Cheers from cold Poland,
> > Lukasz
> >
> > Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25
> sty
> > 2013, o godz. 19:22:
> >
> > > As I explained in the camel thread, I think the main benefit and
> > difference
> > > is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
> > or
> > > linked to it in anyway.  It means the plugins can be reused for non
> OSGi
> > > users, which still represent a big part of the camel and activemq user
> > base.
> > > The idea would be to avoid having each project needing a different web
> > > console at the end (and those projects can't really use the Karaf one I
> > > think).
> > > For Karaf, we don't really care, but the downstream projects do, and
> > > aligning on something would help working together on the same code
> base.
> > >
> > > i don't honestly care about the location of the project itself.  We
> > depends
> > > on lots of things that are not hosted at the ASF (all the pax stuff for
> > > example) and that has never been a problem.    And I don't really think
> > > this console belongs to Karaf at all because it's not OSGi related.
> It
> > > would actually be an adoption problem for hawtio if it would be in
> Karaf
> > as
> > > it would be seen as being OSGi, even if it's not.  Besides that, I
> doubt
> > > James is willing to move it anywhere else atm.
> > >
> > > For now, given the project is not really mature, I think the best way
> > going
> > > forward is to start hacking plugins inside that project itself and
> we'll
> > > see over time how it evolves.  If there's a need to move each plugin
> back
> > > to the original project, it can be done, but today is really not the
> day
> > to
> > > think about that imho, that's a minor issue, and as long as people are
> > able
> > > to hack on plugins, it should be ok.   For this purpose,, github (with
> > > forks and pull requests) is actually much easier than the ASF.
> > >
> > > If the hawtio project really picks up, then switching to it can be
> > > considered, but we may want it to mature a bit more before.  Im sure
> it's
> > > still missing a lot of features we may need, and I only had a quick
> look
> > at
> > > it, but I really like the underlying technology (a static html page,
> REST
> > > for accessing the backend, and the whole JMX tree being available
> through
> > > REST with jolokia).
> > >
> > >
> > >
> > >
> > > On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
> > >wrote:
> > >
> > >> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
> > >> exactly the purpose of Karaf WebConsole: provide a kind of container
> for
> > >> plugins/features extensions.
> > >>
> > >> That's my point: identify the overlap/gap between Karaf WebConsole and
> > >> HawtIO to "communicate" and anticipate the adoption.
> > >> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
> > >> projects, it would make sense to have the "Console" project at Apache.
> > As a
> > >> Karaf subproject, we can move forward and see later if it makes sense
> to
> > >> promote as a TLP.
> > >>
> > >> My $0.02
> > >>
> > >> Regards
> > >> JB
> > >>
> > >>
> > >> On 01/25/2013 06:22 PM, Christian Schneider wrote:
> > >>
> > >>> I have not looked into HawtIO in detail but the idea of having a
> > general
> > >>> console with plugins for each technology sounds good to me.
> > >>> I also think it is good to start such a console separately in github
> as
> > >>> it allows for fast progress to show it works.
> > >>>
> > >>> For the long term I think that the generic part of such a console
> > should
> > >>> move into an apache project. As it makes sense to keep the console
> > >>> independent of OSGi a separate project may make sense.
> > >>> So why should we do this in apache? The reason is that currently
> HawtIO
> > >>> is just another console. Only at a big community like apache we can
> > hope
> > >>> for a project to get enough acceptance that a lot of projects
> > participate.
> > >>>
> > >>> So if we succeed in creating an accepted generic foundation for
> > >>> management consoles then each of the technology plugins could be
> > >>> developed in the respective projects.
> > >>>
> > >>> What do you think about this?
> > >>>
> > >>> Christian
> > >>>
> > >>> On 25.01.2013 12:08, Guillaume Nodet wrote:
> > >>>
> > >>>> FYI, I'm really excited about finally being able to have a unified
> web
> > >>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
> > same
> > >>>> web
> > >>>> console can be used in a non OSGi-environment, so we can really
> > leverage
> > >>>> and work together on a single web console.
> > >>>> I'd encourage everyone to have a look at it and eventually look at
> > what's
> > >>>> missing from a Karaf point of view so that we can discuss if/how we
> > >>>> integrate it.
> > >>>>
> > >>>> ---------- Forwarded message ----------
> > >>>> From: James Strachan <ja...@gmail.com>
> > >>>> Date: Fri, Jan 25, 2013 at 10:59 AM
> > >>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
> > Camel,
> > >>>> ActiveMQ, JMX, OSGi & Fuse Fabric
> > >>>> To: "users@camel.apache.org" <us...@camel.apache.org>
> > >>>>
> > >>>>
> > >>>> For the impatient just look here :) http://hawt.io/
> > >>>>
> > >>>> Background
> > >>>> ==========
> > >>>> We've had numerous consoles all over the place for some time in
> > >>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> > >>>> Fabric to name but a few. Many of them quite heavy weight requiring
> a
> > >>>> custom web app to be deployed (which often is quite large); none
> > >>>> particularly working together.
> > >>>>
> > >>>> We've been working on Fuse Fabric and its management console to
> > >>>> provide a more consolidated view of a cluster of Apache integration
> &
> > >>>> middleware technologies. Increasingly we're seeing our users and
> > >>>> customers using different combinations of technologies in different
> > >>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> > >>>> Karaf + ActiveMQ + Camel or whatever).
> > >>>>
> > >>>> So for a few months a few of us have been working on trying to make
> > >>>> the various web consoles for things like Apache Camel, ActiveMQ,
> > >>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like
> JMX
> > >>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> > >>>> and matched together to suite any container and combination of
> > >>>> technologies that folks deploy in a JVM.
> > >>>>
> > >>>>
> > >>>> hawtio
> > >>>> =====
> > >>>> The result so far is hawtio: http://hawt.io/
> > >>>>
> > >>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> > >>>> provides a UI console for whatever it finds in the JVM. So it works
> > >>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins
> for
> > >>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> > >>>> way.
> > >>>>
> > >>>> The nice thing is its pretty small (about 1Mb WAR containing all the
> > >>>> server side code, HTML, JS, images, CSS etc). The only real server
> > >>>> side component is jolokia which is a small (about 300K) REST
> connector
> > >>>> for JMX (which is awesome BTW!) - the rest is static content (which
> > >>>> could be served from anywhere so doesn't need to be deployed in each
> > >>>> JVM).
> > >>>>
> > >>>> Its based around a plugin architecture:
> > >>>> http://hawt.io/developers/**plugins.html<
> > http://hawt.io/developers/plugins.html>
> > >>>>
> > >>>> so its easy to add new plugins for any kind of technology. A plugin
> is
> > >>>> pretty much anything that runs in a browser.
> > >>>>
> > >>>> The nice thing is hawtio can discover UI plugins at runtime by
> > >>>> examining the contents of the JVM or querying REST endpoints; so the
> > >>>> UI can update in real time as you deploy new things into a JVM!
> > >>>>
> > >>>>
> > >>>> hawtio, the hawt camel rider
> > >>>> ======================
> > >>>> A quick summary of the current features for camel folks:
> > >>>>
> > >>>> * If you have any camel contexts running in a JVM when hawtio starts
> > >>>> up it adds an Integration tab which shows all the camel contexts
> > >>>> running.
> > >>>>
> > >>>> * You can start/stop/suspend/resume the context and its routes; then
> > >>>> look at all the metrics for routes/endpoints/processors. The Charts
> > >>>> tab lets you visualise the real time metrics.
> > >>>>
> > >>>> * You can create new endpoints; browse endpoints which are
> browsable &
> > >>>> send messages to endpoints (with syntax editing support for JSON /
> XML
> > >>>> / YAML / properties)
> > >>>>
> > >>>> * You can visualise all the camel routes or a specific camel route
> for
> > >>>> a context in the Diagram tab and see real time metrics of how many
> > >>>> messages are passing through each step on the diagram. e.g.
> > >>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
> > >>>> images/screenshots/camelRoute.**png<
> >
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
> > >
> > >>>>
> > >>>> * Clicking on a Route allows you to Trace it; when tracing if you
> send
> > >>>> a message into a route then it captures a copy of the message at
> each
> > >>>> point through the route. So you can step through (scroll/click
> through
> > >>>> the table) a route and see the message contents and how the message
> > >>>> flows through the EIPs - highlighting where on the diagram each
> > >>>> message is. This is very handy for figuring out why your route
> doesn't
> > >>>> work :) Spot where the heading disappears! Or see why the CBR
> doesn't
> > >>>> go where you expected.
> > >>>>
> > >>>> In general most of the runtime features of the open source Fuse IDE
> > >>>> eclipse tooling are now supported in the camel hawtio plugin; so
> > >>>> available in a web browser.
> > >>>>
> > >>>>
> > >>>> Summary
> > >>>> =======
> > >>>> So if you're vaguely interested in web consoles for Apache Camel I
> > >>>> urge you to give it a try. We love contributions and feedback!
> > >>>> http://hawt.io/contributing/**index.html<
> > http://hawt.io/contributing/index.html>
> > >>>>
> > >>>> or feel free to raise new issues for how to improve the camel
> plugin:
> > >>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
> > >>>> page=1&sort=updated&state=open<
> >
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
> > >
> > >>>>
> > >>>> or if you've an itch for a new kind of plugin please dive in! We
> > >>>> should be able to expose existing web apps/consoles as links inside
> > >>>> hawtio too BTW.
> > >>>>
> > >>>> Feedback appreciated! Its hawt, but stay cool! ;)
> > >>>>
> > >>>> --
> > >>>> James
> > >>>> -------
> > >>>> Red Hat
> > >>>>
> > >>>> Email: jstracha@redhat.com
> > >>>> Web: http://fusesource.com
> > >>>> Twitter: jstrachan, fusenews
> > >>>> Blog: http://macstrac.blogspot.com/
> > >>>>
> > >>>> Open Source Integration
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >> --
> > >> Jean-Baptiste Onofré
> > >> jbonofre@apache.org
> > >> http://blog.nanthrax.net
> > >> Talend - http://www.talend.com
> > >>
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: gnodet@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
On Sat, Jan 26, 2013 at 12:45 AM, Łukasz Dywicki <lu...@code-house.org>wrote:

> Guillaume,
> I'll not answer for your points since my statement was clear in previous
> message. Made the decision what do you want to do with hawt.io, what you
> want to offer Karaf community and then, simply back.
>

I was just offerring the knowledge, nothing more. And eventually an
invitation to look at it and eventually work on it if people want.  Not all
people follow the camel list and I think it made sense to do it.  Because
it runs in Karaf, and because lots of Karaf users use camel or activemq,
and because it can also serve as a Karaf management console.  If you're not
interested, just ignore the discussion.


> If  you have some objections about my previous or current arguments, go
> ahead.


So I did, but you just said you don't want to answer them.


> We can talk with somebody who is higher than we. I'm personally curious
> what Apache officers thinks about this kind of announcements.


In such a case, you should really send an email to the PMC first (
private@karaf.apache.org),  where JB being the PMC chair is also an officer
of the ASF.  There are also a few other ASF members there.  The PMC is the
one responsible for the project.  Ultimately, you can ping the board (
board@apache.org), though it's usually done when the PMC fails to handle a
situation.


> I'll especially skip the argument about company since Apache is community
> over the code and you should never raise argument like that.
>

You brought the argument in when you said "Fuse project" (not even sure
what you mean by that since FuseSource does not exist anymore).   I think
one of the implication is I'm not acting for the benefit of the project
itself.  So you're questioning my integrity, and I can't really let that go
without answering.


> --
> Pozdrawiam,
> Lukasz




-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Łukasz Dywicki <lu...@code-house.org>.
Guillaume,
I'll not answer for your points since my statement was clear in previous message. Made the decision what do you want to do with hawt.io, what you want to offer Karaf community and then, simply back.

If  you have some objections about my previous or current arguments, go ahead. We can talk with somebody who is higher than we. I'm personally curious what Apache officers thinks about this kind of announcements. I'll especially skip the argument about company since Apache is community over the code and you should never raise argument like that.

--
Pozdrawiam,
Lukasz

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Jan 25, 2013 at 8:12 PM, Łukasz Dywicki <lu...@code-house.org> wrote:

> Guillaume,
> If I'll send a mail with announcement about my amazing project, whatever
> it will be, to apache mailing lists I will be treat a spamer.  If I will
> try doing that with more mailing lists - then I'll be treat as spamer -
> that's for sure. And that's what have you done.


It's not even MY project.  James only talked about it to me a few days ago
and I have never committed anything to it, go check the log if you want.

Such a person would be a spammer if it keeps sending out-of-topic emails
for no reason.  Do I have to remind you that James sent that annoucement
email because I mentioned this project on the mailing list a few hours
before, just saying we could have a look at it.   It was relevant to the
discussion, because we were talking about the future web console for Camel
3.   People started talking about hawtio, so it totally made sense for
James to start a separate thread about it instead of polluting the camel 3
discussion and give a few explanations about what hawtio is.  When we talk
about web console, talking about web console technologies is not really
spamming to me.  It's just technical discussion.

So no, if you're start a project outside the ASF that could be beneficial
for the project, you really should talk about it.  Not doing that is a
disservice to the project and the community.


>  You have something which relates to Apache projects but it's not Apache
> project yet.


It may not even become an ASF project, nobody ever talked about that.  So I
really don't get the "yet" part.  Really, I don't.


> Apache mailing lists are not for  announcement about products and projects
> which are not made under Apache Foundation. Please honor that.
>

Well, then you don't understand what the ASF is.  It's not a silo with a a
rule enforcement about not talking about other projects, not using them, or
enforcing solely the use of other ASF projects.   Remember the mantra
"community over code" ? The ASF is about community.   The ASF does not have
any technical steering committee  does not forbid competing projects inside
the ASF (there are a bunch of those already).  An ASF projects is free to
use whatever other project it wishes, as long as the license is compatible
with ASL.

For example, we do use a lot of pax stuff (logging, web, etc..) which some
of us are heavily involved in.   Some of us are also involved in other
projets that we use which come from the ASF (mina, felix, aries).    We're
also using jetty and not tomcat (where none of us is really involved in),
so what's your point ?  Some very good projects are developped outside the
ASF.  ASF is one style of open-source development, it's not either the only
one, nor does it have to be.

If we can't discuss and disagree over things in a calm way, then there's a
problem, for sure.


> That's all in this topic from me and I don't going to discuss about any
> other Fuse project any more on Apache mailing lists.


We're not discussing a Fuse project.  James starts all kind of projects
each year.  Some of them are good and pick up, some of them don't.  We
talked about this project because it makes sense for the communities and
projects here at the ASF.   Forbidding to talk about it is just nonsense.

If you want another example, I'm currently trying to have weld-osgi, the
cdi container, running correctly in OSGi and Karaf.  It's not an ASF
project, and the discussion about CDI never came up on Karaf dev list.
 Would it have been the case, I would have talked about what I'm doing.
 And that would have been relevant.  Another thing I have in mind is to
upgrade to OSGi r5 at some point in the future, and I may look at the
repository implementation David B wrote in jboss-osgi to see if it fits my
needs.   If it does not, I'll intend to either modify it if I think it's
doable, or even rewrite a new one if I think it makes more sense.   Is that
also a crime for you ?


> If you want donate hawt.io, that's fine - write incubator proposal (as it
> doesn't fit Karaf at all) or take it as part of other community. I don't
> care.


But nobody talked about donating hawtio anywhere at this point.  I even
said a few hours ago I don't think it's a good idea, at least at the
moment.   I don't really have any saying in this anymore, given I haven't
even touched it.


> For example you may wish use ServiceMix for that. You have most of
> committers there. It will fit also SMX5, more over it will let you
> resuscitate it after two years of doing nothing.
>

Not sure I get your point here.  Should I be ashamed of not having worked a
lot on ServiceMix recently after having worked mostly full time on it for 5
years ? You must be kidding, right ?  Anyway, no ASF committer is bound to
a project and the people are free to work or not work on anything they
want.  The value of ServiceMix went away, first when Camel was created,
then when the Kernel was moved to a TLP in Karaf.  Everyone knows that,
even if it took time to admit it.  And btw, I don't see how hawtio would
fit in ServiceMix at all.  Fwiw, I don't think it fits in any TLP I can
think of right now.  Again, everything does not *have to* be at the ASF:
the ASF does not try to rule the world.


> I hope I made it clear.
>

No, not really.  And that time, I hope nobody is accusing James or me to
try to push a hidden company agenda : do I have to remind you that you and
I are actually working for the same company ?  Maybe the problem is there
has been very few hot technical discussions in the projects we've worked at.

Anyway, this email is pointless and too much time consuming for me (I'm
usually spending a *lot* of time writing such emails to make sure I won't
regret a single word of it, which does not always succeed btw).  So please,
have a break during the weekend, stop attacking people and if you have
technical arguments, raise them so that we can get the discussion going
with sane arguments.

--
> Cheers from cold Poland,
> Lukasz
>
> Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25 sty
> 2013, o godz. 19:22:
>
> > As I explained in the camel thread, I think the main benefit and
> difference
> > is that hawtio is not OSGi at all.  It can work in OSGi but is not tied
> or
> > linked to it in anyway.  It means the plugins can be reused for non OSGi
> > users, which still represent a big part of the camel and activemq user
> base.
> > The idea would be to avoid having each project needing a different web
> > console at the end (and those projects can't really use the Karaf one I
> > think).
> > For Karaf, we don't really care, but the downstream projects do, and
> > aligning on something would help working together on the same code base.
> >
> > i don't honestly care about the location of the project itself.  We
> depends
> > on lots of things that are not hosted at the ASF (all the pax stuff for
> > example) and that has never been a problem.    And I don't really think
> > this console belongs to Karaf at all because it's not OSGi related.   It
> > would actually be an adoption problem for hawtio if it would be in Karaf
> as
> > it would be seen as being OSGi, even if it's not.  Besides that, I doubt
> > James is willing to move it anywhere else atm.
> >
> > For now, given the project is not really mature, I think the best way
> going
> > forward is to start hacking plugins inside that project itself and we'll
> > see over time how it evolves.  If there's a need to move each plugin back
> > to the original project, it can be done, but today is really not the day
> to
> > think about that imho, that's a minor issue, and as long as people are
> able
> > to hack on plugins, it should be ok.   For this purpose,, github (with
> > forks and pull requests) is actually much easier than the ASF.
> >
> > If the hawtio project really picks up, then switching to it can be
> > considered, but we may want it to mature a bit more before.  Im sure it's
> > still missing a lot of features we may need, and I only had a quick look
> at
> > it, but I really like the underlying technology (a static html page, REST
> > for accessing the backend, and the whole JMX tree being available through
> > REST with jolokia).
> >
> >
> >
> >
> > On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb@nanthrax.net
> >wrote:
> >
> >> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
> >> exactly the purpose of Karaf WebConsole: provide a kind of container for
> >> plugins/features extensions.
> >>
> >> That's my point: identify the overlap/gap between Karaf WebConsole and
> >> HawtIO to "communicate" and anticipate the adoption.
> >> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
> >> projects, it would make sense to have the "Console" project at Apache.
> As a
> >> Karaf subproject, we can move forward and see later if it makes sense to
> >> promote as a TLP.
> >>
> >> My $0.02
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 01/25/2013 06:22 PM, Christian Schneider wrote:
> >>
> >>> I have not looked into HawtIO in detail but the idea of having a
> general
> >>> console with plugins for each technology sounds good to me.
> >>> I also think it is good to start such a console separately in github as
> >>> it allows for fast progress to show it works.
> >>>
> >>> For the long term I think that the generic part of such a console
> should
> >>> move into an apache project. As it makes sense to keep the console
> >>> independent of OSGi a separate project may make sense.
> >>> So why should we do this in apache? The reason is that currently HawtIO
> >>> is just another console. Only at a big community like apache we can
> hope
> >>> for a project to get enough acceptance that a lot of projects
> participate.
> >>>
> >>> So if we succeed in creating an accepted generic foundation for
> >>> management consoles then each of the technology plugins could be
> >>> developed in the respective projects.
> >>>
> >>> What do you think about this?
> >>>
> >>> Christian
> >>>
> >>> On 25.01.2013 12:08, Guillaume Nodet wrote:
> >>>
> >>>> FYI, I'm really excited about finally being able to have a unified web
> >>>> console for Karaf / ActiveMQ / Camel, especially the fact that the
> same
> >>>> web
> >>>> console can be used in a non OSGi-environment, so we can really
> leverage
> >>>> and work together on a single web console.
> >>>> I'd encourage everyone to have a look at it and eventually look at
> what's
> >>>> missing from a Karaf point of view so that we can discuss if/how we
> >>>> integrate it.
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: James Strachan <ja...@gmail.com>
> >>>> Date: Fri, Jan 25, 2013 at 10:59 AM
> >>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache
> Camel,
> >>>> ActiveMQ, JMX, OSGi & Fuse Fabric
> >>>> To: "users@camel.apache.org" <us...@camel.apache.org>
> >>>>
> >>>>
> >>>> For the impatient just look here :) http://hawt.io/
> >>>>
> >>>> Background
> >>>> ==========
> >>>> We've had numerous consoles all over the place for some time in
> >>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> >>>> Fabric to name but a few. Many of them quite heavy weight requiring a
> >>>> custom web app to be deployed (which often is quite large); none
> >>>> particularly working together.
> >>>>
> >>>> We've been working on Fuse Fabric and its management console to
> >>>> provide a more consolidated view of a cluster of Apache integration &
> >>>> middleware technologies. Increasingly we're seeing our users and
> >>>> customers using different combinations of technologies in different
> >>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> >>>> Karaf + ActiveMQ + Camel or whatever).
> >>>>
> >>>> So for a few months a few of us have been working on trying to make
> >>>> the various web consoles for things like Apache Camel, ActiveMQ,
> >>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> >>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> >>>> and matched together to suite any container and combination of
> >>>> technologies that folks deploy in a JVM.
> >>>>
> >>>>
> >>>> hawtio
> >>>> =====
> >>>> The result so far is hawtio: http://hawt.io/
> >>>>
> >>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> >>>> provides a UI console for whatever it finds in the JVM. So it works
> >>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> >>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> >>>> way.
> >>>>
> >>>> The nice thing is its pretty small (about 1Mb WAR containing all the
> >>>> server side code, HTML, JS, images, CSS etc). The only real server
> >>>> side component is jolokia which is a small (about 300K) REST connector
> >>>> for JMX (which is awesome BTW!) - the rest is static content (which
> >>>> could be served from anywhere so doesn't need to be deployed in each
> >>>> JVM).
> >>>>
> >>>> Its based around a plugin architecture:
> >>>> http://hawt.io/developers/**plugins.html<
> http://hawt.io/developers/plugins.html>
> >>>>
> >>>> so its easy to add new plugins for any kind of technology. A plugin is
> >>>> pretty much anything that runs in a browser.
> >>>>
> >>>> The nice thing is hawtio can discover UI plugins at runtime by
> >>>> examining the contents of the JVM or querying REST endpoints; so the
> >>>> UI can update in real time as you deploy new things into a JVM!
> >>>>
> >>>>
> >>>> hawtio, the hawt camel rider
> >>>> ======================
> >>>> A quick summary of the current features for camel folks:
> >>>>
> >>>> * If you have any camel contexts running in a JVM when hawtio starts
> >>>> up it adds an Integration tab which shows all the camel contexts
> >>>> running.
> >>>>
> >>>> * You can start/stop/suspend/resume the context and its routes; then
> >>>> look at all the metrics for routes/endpoints/processors. The Charts
> >>>> tab lets you visualise the real time metrics.
> >>>>
> >>>> * You can create new endpoints; browse endpoints which are browsable &
> >>>> send messages to endpoints (with syntax editing support for JSON / XML
> >>>> / YAML / properties)
> >>>>
> >>>> * You can visualise all the camel routes or a specific camel route for
> >>>> a context in the Diagram tab and see real time metrics of how many
> >>>> messages are passing through each step on the diagram. e.g.
> >>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
> >>>> images/screenshots/camelRoute.**png<
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
> >
> >>>>
> >>>> * Clicking on a Route allows you to Trace it; when tracing if you send
> >>>> a message into a route then it captures a copy of the message at each
> >>>> point through the route. So you can step through (scroll/click through
> >>>> the table) a route and see the message contents and how the message
> >>>> flows through the EIPs - highlighting where on the diagram each
> >>>> message is. This is very handy for figuring out why your route doesn't
> >>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
> >>>> go where you expected.
> >>>>
> >>>> In general most of the runtime features of the open source Fuse IDE
> >>>> eclipse tooling are now supported in the camel hawtio plugin; so
> >>>> available in a web browser.
> >>>>
> >>>>
> >>>> Summary
> >>>> =======
> >>>> So if you're vaguely interested in web consoles for Apache Camel I
> >>>> urge you to give it a try. We love contributions and feedback!
> >>>> http://hawt.io/contributing/**index.html<
> http://hawt.io/contributing/index.html>
> >>>>
> >>>> or feel free to raise new issues for how to improve the camel plugin:
> >>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
> >>>> page=1&sort=updated&state=open<
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
> >
> >>>>
> >>>> or if you've an itch for a new kind of plugin please dive in! We
> >>>> should be able to expose existing web apps/consoles as links inside
> >>>> hawtio too BTW.
> >>>>
> >>>> Feedback appreciated! Its hawt, but stay cool! ;)
> >>>>
> >>>> --
> >>>> James
> >>>> -------
> >>>> Red Hat
> >>>>
> >>>> Email: jstracha@redhat.com
> >>>> Web: http://fusesource.com
> >>>> Twitter: jstrachan, fusenews
> >>>> Blog: http://macstrac.blogspot.com/
> >>>>
> >>>> Open Source Integration
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Łukasz Dywicki <lu...@code-house.org>.
Guillaume,
If I'll send a mail with announcement about my amazing project, whatever it will be, to apache mailing lists I will be treat a spamer. If I will try doing that with more mailing lists - then I'll be treat as spamer - that's for sure. And that's what have you done. You have something which relates to Apache projects but it's not Apache project yet. Apache mailing lists are not for  announcement about products and projects which are not made under Apache Foundation. Please honor that.

That's all in this topic from me and I don't going to discuss about any other Fuse project any more on Apache mailing lists. If you want donate hawt.io, that's fine - write incubator proposal (as it doesn't fit Karaf at all) or take it as part of other community. I don't care.
For example you may wish use ServiceMix for that. You have most of commiters there. It will fit also SMX5, more over it will let you resuscitate it after two years of doing nothing. 

I hope I made it clear.
--
Cheers from cold Poland,
Lukasz

Wiadomość napisana przez Guillaume Nodet <gn...@gmail.com> w dniu 25 sty 2013, o godz. 19:22:

> As I explained in the camel thread, I think the main benefit and difference
> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied or
> linked to it in anyway.  It means the plugins can be reused for non OSGi
> users, which still represent a big part of the camel and activemq user base.
> The idea would be to avoid having each project needing a different web
> console at the end (and those projects can't really use the Karaf one I
> think).
> For Karaf, we don't really care, but the downstream projects do, and
> aligning on something would help working together on the same code base.
> 
> i don't honestly care about the location of the project itself.  We depends
> on lots of things that are not hosted at the ASF (all the pax stuff for
> example) and that has never been a problem.    And I don't really think
> this console belongs to Karaf at all because it's not OSGi related.   It
> would actually be an adoption problem for hawtio if it would be in Karaf as
> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
> James is willing to move it anywhere else atm.
> 
> For now, given the project is not really mature, I think the best way going
> forward is to start hacking plugins inside that project itself and we'll
> see over time how it evolves.  If there's a need to move each plugin back
> to the original project, it can be done, but today is really not the day to
> think about that imho, that's a minor issue, and as long as people are able
> to hack on plugins, it should be ok.   For this purpose,, github (with
> forks and pull requests) is actually much easier than the ASF.
> 
> If the hawtio project really picks up, then switching to it can be
> considered, but we may want it to mature a bit more before.  Im sure it's
> still missing a lot of features we may need, and I only had a quick look at
> it, but I really like the underlying technology (a static html page, REST
> for accessing the backend, and the whole JMX tree being available through
> REST with jolokia).
> 
> 
> 
> 
> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> 
>> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>> exactly the purpose of Karaf WebConsole: provide a kind of container for
>> plugins/features extensions.
>> 
>> That's my point: identify the overlap/gap between Karaf WebConsole and
>> HawtIO to "communicate" and anticipate the adoption.
>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>> projects, it would make sense to have the "Console" project at Apache. As a
>> Karaf subproject, we can move forward and see later if it makes sense to
>> promote as a TLP.
>> 
>> My $0.02
>> 
>> Regards
>> JB
>> 
>> 
>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>> 
>>> I have not looked into HawtIO in detail but the idea of having a general
>>> console with plugins for each technology sounds good to me.
>>> I also think it is good to start such a console separately in github as
>>> it allows for fast progress to show it works.
>>> 
>>> For the long term I think that the generic part of such a console should
>>> move into an apache project. As it makes sense to keep the console
>>> independent of OSGi a separate project may make sense.
>>> So why should we do this in apache? The reason is that currently HawtIO
>>> is just another console. Only at a big community like apache we can hope
>>> for a project to get enough acceptance that a lot of projects participate.
>>> 
>>> So if we succeed in creating an accepted generic foundation for
>>> management consoles then each of the technology plugins could be
>>> developed in the respective projects.
>>> 
>>> What do you think about this?
>>> 
>>> Christian
>>> 
>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>> 
>>>> FYI, I'm really excited about finally being able to have a unified web
>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the same
>>>> web
>>>> console can be used in a non OSGi-environment, so we can really leverage
>>>> and work together on a single web console.
>>>> I'd encourage everyone to have a look at it and eventually look at what's
>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>> integrate it.
>>>> 
>>>> ---------- Forwarded message ----------
>>>> From: James Strachan <ja...@gmail.com>
>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>> 
>>>> 
>>>> For the impatient just look here :) http://hawt.io/
>>>> 
>>>> Background
>>>> ==========
>>>> We've had numerous consoles all over the place for some time in
>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>> custom web app to be deployed (which often is quite large); none
>>>> particularly working together.
>>>> 
>>>> We've been working on Fuse Fabric and its management console to
>>>> provide a more consolidated view of a cluster of Apache integration &
>>>> middleware technologies. Increasingly we're seeing our users and
>>>> customers using different combinations of technologies in different
>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>> Karaf + ActiveMQ + Camel or whatever).
>>>> 
>>>> So for a few months a few of us have been working on trying to make
>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>> and matched together to suite any container and combination of
>>>> technologies that folks deploy in a JVM.
>>>> 
>>>> 
>>>> hawtio
>>>> =====
>>>> The result so far is hawtio: http://hawt.io/
>>>> 
>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>> way.
>>>> 
>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>> side component is jolokia which is a small (about 300K) REST connector
>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>> could be served from anywhere so doesn't need to be deployed in each
>>>> JVM).
>>>> 
>>>> Its based around a plugin architecture:
>>>> http://hawt.io/developers/**plugins.html<http://hawt.io/developers/plugins.html>
>>>> 
>>>> so its easy to add new plugins for any kind of technology. A plugin is
>>>> pretty much anything that runs in a browser.
>>>> 
>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>> UI can update in real time as you deploy new things into a JVM!
>>>> 
>>>> 
>>>> hawtio, the hawt camel rider
>>>> ======================
>>>> A quick summary of the current features for camel folks:
>>>> 
>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>> up it adds an Integration tab which shows all the camel contexts
>>>> running.
>>>> 
>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>> tab lets you visualise the real time metrics.
>>>> 
>>>> * You can create new endpoints; browse endpoints which are browsable &
>>>> send messages to endpoints (with syntax editing support for JSON / XML
>>>> / YAML / properties)
>>>> 
>>>> * You can visualise all the camel routes or a specific camel route for
>>>> a context in the Diagram tab and see real time metrics of how many
>>>> messages are passing through each step on the diagram. e.g.
>>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
>>>> images/screenshots/camelRoute.**png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>> 
>>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>>> a message into a route then it captures a copy of the message at each
>>>> point through the route. So you can step through (scroll/click through
>>>> the table) a route and see the message contents and how the message
>>>> flows through the EIPs - highlighting where on the diagram each
>>>> message is. This is very handy for figuring out why your route doesn't
>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>> go where you expected.
>>>> 
>>>> In general most of the runtime features of the open source Fuse IDE
>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>> available in a web browser.
>>>> 
>>>> 
>>>> Summary
>>>> =======
>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>> urge you to give it a try. We love contributions and feedback!
>>>> http://hawt.io/contributing/**index.html<http://hawt.io/contributing/index.html>
>>>> 
>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
>>>> page=1&sort=updated&state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>> 
>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>> should be able to expose existing web apps/consoles as links inside
>>>> hawtio too BTW.
>>>> 
>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>> 
>>>> --
>>>> James
>>>> -------
>>>> Red Hat
>>>> 
>>>> Email: jstracha@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan, fusenews
>>>> Blog: http://macstrac.blogspot.com/
>>>> 
>>>> Open Source Integration
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
> 
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/


Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I got your point about non-OSGi and it makes sense.

 From a technical perspective, and regarding that HawtIO is a new 
project, it makes sense for move forward on github.

The point will be present later. For instance, I got remarks from some 
users saying that they would prefer to see Pax* projects as ASF projects 
to insure legal stuff and at least release votes (which is a kind of ASF 
stamp for the project). They are less confident in non Apache project 
because they are not really code review and release vote.
To be honest, I don't think it's a big deal, but some users is looking 
for that.

Regards
JB

On 01/25/2013 07:22 PM, Guillaume Nodet wrote:
> As I explained in the camel thread, I think the main benefit and difference
> is that hawtio is not OSGi at all.  It can work in OSGi but is not tied or
> linked to it in anyway.  It means the plugins can be reused for non OSGi
> users, which still represent a big part of the camel and activemq user base.
> The idea would be to avoid having each project needing a different web
> console at the end (and those projects can't really use the Karaf one I
> think).
> For Karaf, we don't really care, but the downstream projects do, and
> aligning on something would help working together on the same code base.
>
> i don't honestly care about the location of the project itself.  We depends
> on lots of things that are not hosted at the ASF (all the pax stuff for
> example) and that has never been a problem.    And I don't really think
> this console belongs to Karaf at all because it's not OSGi related.   It
> would actually be an adoption problem for hawtio if it would be in Karaf as
> it would be seen as being OSGi, even if it's not.  Besides that, I doubt
> James is willing to move it anywhere else atm.
>
> For now, given the project is not really mature, I think the best way going
> forward is to start hacking plugins inside that project itself and we'll
> see over time how it evolves.  If there's a need to move each plugin back
> to the original project, it can be done, but today is really not the day to
> think about that imho, that's a minor issue, and as long as people are able
> to hack on plugins, it should be ok.   For this purpose,, github (with
> forks and pull requests) is actually much easier than the ASF.
>
> If the hawtio project really picks up, then switching to it can be
> considered, but we may want it to mature a bit more before.  Im sure it's
> still missing a lot of features we may need, and I only had a quick look at
> it, but I really like the underlying technology (a static html page, REST
> for accessing the backend, and the whole JMX tree being available through
> REST with jolokia).
>
>
>
>
> On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
>> exactly the purpose of Karaf WebConsole: provide a kind of container for
>> plugins/features extensions.
>>
>> That's my point: identify the overlap/gap between Karaf WebConsole and
>> HawtIO to "communicate" and anticipate the adoption.
>> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
>> projects, it would make sense to have the "Console" project at Apache. As a
>> Karaf subproject, we can move forward and see later if it makes sense to
>> promote as a TLP.
>>
>> My $0.02
>>
>> Regards
>> JB
>>
>>
>> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>>
>>> I have not looked into HawtIO in detail but the idea of having a general
>>> console with plugins for each technology sounds good to me.
>>> I also think it is good to start such a console separately in github as
>>> it allows for fast progress to show it works.
>>>
>>> For the long term I think that the generic part of such a console should
>>> move into an apache project. As it makes sense to keep the console
>>> independent of OSGi a separate project may make sense.
>>> So why should we do this in apache? The reason is that currently HawtIO
>>> is just another console. Only at a big community like apache we can hope
>>> for a project to get enough acceptance that a lot of projects participate.
>>>
>>> So if we succeed in creating an accepted generic foundation for
>>> management consoles then each of the technology plugins could be
>>> developed in the respective projects.
>>>
>>> What do you think about this?
>>>
>>> Christian
>>>
>>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>>
>>>> FYI, I'm really excited about finally being able to have a unified web
>>>> console for Karaf / ActiveMQ / Camel, especially the fact that the same
>>>> web
>>>> console can be used in a non OSGi-environment, so we can really leverage
>>>> and work together on a single web console.
>>>> I'd encourage everyone to have a look at it and eventually look at what's
>>>> missing from a Karaf point of view so that we can discuss if/how we
>>>> integrate it.
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: James Strachan <ja...@gmail.com>
>>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
>>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>>
>>>>
>>>> For the impatient just look here :) http://hawt.io/
>>>>
>>>> Background
>>>> ==========
>>>> We've had numerous consoles all over the place for some time in
>>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>>> custom web app to be deployed (which often is quite large); none
>>>> particularly working together.
>>>>
>>>> We've been working on Fuse Fabric and its management console to
>>>> provide a more consolidated view of a cluster of Apache integration &
>>>> middleware technologies. Increasingly we're seeing our users and
>>>> customers using different combinations of technologies in different
>>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>>> Karaf + ActiveMQ + Camel or whatever).
>>>>
>>>> So for a few months a few of us have been working on trying to make
>>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>>> and matched together to suite any container and combination of
>>>> technologies that folks deploy in a JVM.
>>>>
>>>>
>>>> hawtio
>>>> =====
>>>> The result so far is hawtio: http://hawt.io/
>>>>
>>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>>> provides a UI console for whatever it finds in the JVM. So it works
>>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>>> way.
>>>>
>>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>>> server side code, HTML, JS, images, CSS etc). The only real server
>>>> side component is jolokia which is a small (about 300K) REST connector
>>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>>> could be served from anywhere so doesn't need to be deployed in each
>>>> JVM).
>>>>
>>>> Its based around a plugin architecture:
>>>> http://hawt.io/developers/**plugins.html<http://hawt.io/developers/plugins.html>
>>>>
>>>> so its easy to add new plugins for any kind of technology. A plugin is
>>>> pretty much anything that runs in a browser.
>>>>
>>>> The nice thing is hawtio can discover UI plugins at runtime by
>>>> examining the contents of the JVM or querying REST endpoints; so the
>>>> UI can update in real time as you deploy new things into a JVM!
>>>>
>>>>
>>>> hawtio, the hawt camel rider
>>>> ======================
>>>> A quick summary of the current features for camel folks:
>>>>
>>>> * If you have any camel contexts running in a JVM when hawtio starts
>>>> up it adds an Integration tab which shows all the camel contexts
>>>> running.
>>>>
>>>> * You can start/stop/suspend/resume the context and its routes; then
>>>> look at all the metrics for routes/endpoints/processors. The Charts
>>>> tab lets you visualise the real time metrics.
>>>>
>>>> * You can create new endpoints; browse endpoints which are browsable &
>>>> send messages to endpoints (with syntax editing support for JSON / XML
>>>> / YAML / properties)
>>>>
>>>> * You can visualise all the camel routes or a specific camel route for
>>>> a context in the Diagram tab and see real time metrics of how many
>>>> messages are passing through each step on the diagram. e.g.
>>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
>>>> images/screenshots/camelRoute.**png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>>
>>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>>> a message into a route then it captures a copy of the message at each
>>>> point through the route. So you can step through (scroll/click through
>>>> the table) a route and see the message contents and how the message
>>>> flows through the EIPs - highlighting where on the diagram each
>>>> message is. This is very handy for figuring out why your route doesn't
>>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>>> go where you expected.
>>>>
>>>> In general most of the runtime features of the open source Fuse IDE
>>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>>> available in a web browser.
>>>>
>>>>
>>>> Summary
>>>> =======
>>>> So if you're vaguely interested in web consoles for Apache Camel I
>>>> urge you to give it a try. We love contributions and feedback!
>>>> http://hawt.io/contributing/**index.html<http://hawt.io/contributing/index.html>
>>>>
>>>> or feel free to raise new issues for how to improve the camel plugin:
>>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
>>>> page=1&sort=updated&state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>>
>>>> or if you've an itch for a new kind of plugin please dive in! We
>>>> should be able to expose existing web apps/consoles as links inside
>>>> hawtio too BTW.
>>>>
>>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>>
>>>> --
>>>> James
>>>> -------
>>>> Red Hat
>>>>
>>>> Email: jstracha@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: jstrachan, fusenews
>>>> Blog: http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
As I explained in the camel thread, I think the main benefit and difference
is that hawtio is not OSGi at all.  It can work in OSGi but is not tied or
linked to it in anyway.  It means the plugins can be reused for non OSGi
users, which still represent a big part of the camel and activemq user base.
The idea would be to avoid having each project needing a different web
console at the end (and those projects can't really use the Karaf one I
think).
For Karaf, we don't really care, but the downstream projects do, and
aligning on something would help working together on the same code base.

i don't honestly care about the location of the project itself.  We depends
on lots of things that are not hosted at the ASF (all the pax stuff for
example) and that has never been a problem.    And I don't really think
this console belongs to Karaf at all because it's not OSGi related.   It
would actually be an adoption problem for hawtio if it would be in Karaf as
it would be seen as being OSGi, even if it's not.  Besides that, I doubt
James is willing to move it anywhere else atm.

For now, given the project is not really mature, I think the best way going
forward is to start hacking plugins inside that project itself and we'll
see over time how it evolves.  If there's a need to move each plugin back
to the original project, it can be done, but today is really not the day to
think about that imho, that's a minor issue, and as long as people are able
to hack on plugins, it should be ok.   For this purpose,, github (with
forks and pull requests) is actually much easier than the ASF.

If the hawtio project really picks up, then switching to it can be
considered, but we may want it to mature a bit more before.  Im sure it's
still missing a lot of features we may need, and I only had a quick look at
it, but I really like the underlying technology (a static html page, REST
for accessing the backend, and the whole JMX tree being available through
REST with jolokia).




On Fri, Jan 25, 2013 at 7:01 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:

> AFAIR (I think that Lukasz and Achim will jump in), once again, it's
> exactly the purpose of Karaf WebConsole: provide a kind of container for
> plugins/features extensions.
>
> That's my point: identify the overlap/gap between Karaf WebConsole and
> HawtIO to "communicate" and anticipate the adoption.
> IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache
> projects, it would make sense to have the "Console" project at Apache. As a
> Karaf subproject, we can move forward and see later if it makes sense to
> promote as a TLP.
>
> My $0.02
>
> Regards
> JB
>
>
> On 01/25/2013 06:22 PM, Christian Schneider wrote:
>
>> I have not looked into HawtIO in detail but the idea of having a general
>> console with plugins for each technology sounds good to me.
>> I also think it is good to start such a console separately in github as
>> it allows for fast progress to show it works.
>>
>> For the long term I think that the generic part of such a console should
>> move into an apache project. As it makes sense to keep the console
>> independent of OSGi a separate project may make sense.
>> So why should we do this in apache? The reason is that currently HawtIO
>> is just another console. Only at a big community like apache we can hope
>> for a project to get enough acceptance that a lot of projects participate.
>>
>> So if we succeed in creating an accepted generic foundation for
>> management consoles then each of the technology plugins could be
>> developed in the respective projects.
>>
>> What do you think about this?
>>
>> Christian
>>
>> On 25.01.2013 12:08, Guillaume Nodet wrote:
>>
>>> FYI, I'm really excited about finally being able to have a unified web
>>> console for Karaf / ActiveMQ / Camel, especially the fact that the same
>>> web
>>> console can be used in a non OSGi-environment, so we can really leverage
>>> and work together on a single web console.
>>> I'd encourage everyone to have a look at it and eventually look at what's
>>> missing from a Karaf point of view so that we can discuss if/how we
>>> integrate it.
>>>
>>> ---------- Forwarded message ----------
>>> From: James Strachan <ja...@gmail.com>
>>> Date: Fri, Jan 25, 2013 at 10:59 AM
>>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
>>> ActiveMQ, JMX, OSGi & Fuse Fabric
>>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>>
>>>
>>> For the impatient just look here :) http://hawt.io/
>>>
>>> Background
>>> ==========
>>> We've had numerous consoles all over the place for some time in
>>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>>> Fabric to name but a few. Many of them quite heavy weight requiring a
>>> custom web app to be deployed (which often is quite large); none
>>> particularly working together.
>>>
>>> We've been working on Fuse Fabric and its management console to
>>> provide a more consolidated view of a cluster of Apache integration &
>>> middleware technologies. Increasingly we're seeing our users and
>>> customers using different combinations of technologies in different
>>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>>> Karaf + ActiveMQ + Camel or whatever).
>>>
>>> So for a few months a few of us have been working on trying to make
>>> the various web consoles for things like Apache Camel, ActiveMQ,
>>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>>> and matched together to suite any container and combination of
>>> technologies that folks deploy in a JVM.
>>>
>>>
>>> hawtio
>>> =====
>>> The result so far is hawtio: http://hawt.io/
>>>
>>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>>> provides a UI console for whatever it finds in the JVM. So it works
>>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>>> way.
>>>
>>> The nice thing is its pretty small (about 1Mb WAR containing all the
>>> server side code, HTML, JS, images, CSS etc). The only real server
>>> side component is jolokia which is a small (about 300K) REST connector
>>> for JMX (which is awesome BTW!) - the rest is static content (which
>>> could be served from anywhere so doesn't need to be deployed in each
>>> JVM).
>>>
>>> Its based around a plugin architecture:
>>> http://hawt.io/developers/**plugins.html<http://hawt.io/developers/plugins.html>
>>>
>>> so its easy to add new plugins for any kind of technology. A plugin is
>>> pretty much anything that runs in a browser.
>>>
>>> The nice thing is hawtio can discover UI plugins at runtime by
>>> examining the contents of the JVM or querying REST endpoints; so the
>>> UI can update in real time as you deploy new things into a JVM!
>>>
>>>
>>> hawtio, the hawt camel rider
>>> ======================
>>> A quick summary of the current features for camel folks:
>>>
>>> * If you have any camel contexts running in a JVM when hawtio starts
>>> up it adds an Integration tab which shows all the camel contexts
>>> running.
>>>
>>> * You can start/stop/suspend/resume the context and its routes; then
>>> look at all the metrics for routes/endpoints/processors. The Charts
>>> tab lets you visualise the real time metrics.
>>>
>>> * You can create new endpoints; browse endpoints which are browsable &
>>> send messages to endpoints (with syntax editing support for JSON / XML
>>> / YAML / properties)
>>>
>>> * You can visualise all the camel routes or a specific camel route for
>>> a context in the Diagram tab and see real time metrics of how many
>>> messages are passing through each step on the diagram. e.g.
>>> https://raw.github.com/hawtio/**hawtio/master/website/src/**
>>> images/screenshots/camelRoute.**png<https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png>
>>>
>>> * Clicking on a Route allows you to Trace it; when tracing if you send
>>> a message into a route then it captures a copy of the message at each
>>> point through the route. So you can step through (scroll/click through
>>> the table) a route and see the message contents and how the message
>>> flows through the EIPs - highlighting where on the diagram each
>>> message is. This is very handy for figuring out why your route doesn't
>>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>>> go where you expected.
>>>
>>> In general most of the runtime features of the open source Fuse IDE
>>> eclipse tooling are now supported in the camel hawtio plugin; so
>>> available in a web browser.
>>>
>>>
>>> Summary
>>> =======
>>> So if you're vaguely interested in web consoles for Apache Camel I
>>> urge you to give it a try. We love contributions and feedback!
>>> http://hawt.io/contributing/**index.html<http://hawt.io/contributing/index.html>
>>>
>>> or feel free to raise new issues for how to improve the camel plugin:
>>> https://github.com/hawtio/**hawtio/issues?labels=camel&**
>>> page=1&sort=updated&state=open<https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open>
>>>
>>> or if you've an itch for a new kind of plugin please dive in! We
>>> should be able to expose existing web apps/consoles as links inside
>>> hawtio too BTW.
>>>
>>> Feedback appreciated! Its hawt, but stay cool! ;)
>>>
>>> --
>>> James
>>> -------
>>> Red Hat
>>>
>>> Email: jstracha@redhat.com
>>> Web: http://fusesource.com
>>> Twitter: jstrachan, fusenews
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>>
>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
AFAIR (I think that Lukasz and Achim will jump in), once again, it's 
exactly the purpose of Karaf WebConsole: provide a kind of container for 
plugins/features extensions.

That's my point: identify the overlap/gap between Karaf WebConsole and 
HawtIO to "communicate" and anticipate the adoption.
IMHO, as ActiveMQ, ServiceMix, Karaf, Camel, KarafEE, etc are Apache 
projects, it would make sense to have the "Console" project at Apache. 
As a Karaf subproject, we can move forward and see later if it makes 
sense to promote as a TLP.

My $0.02

Regards
JB

On 01/25/2013 06:22 PM, Christian Schneider wrote:
> I have not looked into HawtIO in detail but the idea of having a general
> console with plugins for each technology sounds good to me.
> I also think it is good to start such a console separately in github as
> it allows for fast progress to show it works.
>
> For the long term I think that the generic part of such a console should
> move into an apache project. As it makes sense to keep the console
> independent of OSGi a separate project may make sense.
> So why should we do this in apache? The reason is that currently HawtIO
> is just another console. Only at a big community like apache we can hope
> for a project to get enough acceptance that a lot of projects participate.
>
> So if we succeed in creating an accepted generic foundation for
> management consoles then each of the technology plugins could be
> developed in the respective projects.
>
> What do you think about this?
>
> Christian
>
> On 25.01.2013 12:08, Guillaume Nodet wrote:
>> FYI, I'm really excited about finally being able to have a unified web
>> console for Karaf / ActiveMQ / Camel, especially the fact that the same web
>> console can be used in a non OSGi-environment, so we can really leverage
>> and work together on a single web console.
>> I'd encourage everyone to have a look at it and eventually look at what's
>> missing from a Karaf point of view so that we can discuss if/how we
>> integrate it.
>>
>> ---------- Forwarded message ----------
>> From: James Strachan <ja...@gmail.com>
>> Date: Fri, Jan 25, 2013 at 10:59 AM
>> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
>> ActiveMQ, JMX, OSGi & Fuse Fabric
>> To: "users@camel.apache.org" <us...@camel.apache.org>
>>
>>
>> For the impatient just look here :) http://hawt.io/
>>
>> Background
>> ==========
>> We've had numerous consoles all over the place for some time in
>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>> Fabric to name but a few. Many of them quite heavy weight requiring a
>> custom web app to be deployed (which often is quite large); none
>> particularly working together.
>>
>> We've been working on Fuse Fabric and its management console to
>> provide a more consolidated view of a cluster of Apache integration &
>> middleware technologies. Increasingly we're seeing our users and
>> customers using different combinations of technologies in different
>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>> Karaf + ActiveMQ + Camel or whatever).
>>
>> So for a few months a few of us have been working on trying to make
>> the various web consoles for things like Apache Camel, ActiveMQ,
>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>> and matched together to suite any container and combination of
>> technologies that folks deploy in a JVM.
>>
>>
>> hawtio
>> =====
>> The result so far is hawtio: http://hawt.io/
>>
>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>> provides a UI console for whatever it finds in the JVM. So it works
>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>> way.
>>
>> The nice thing is its pretty small (about 1Mb WAR containing all the
>> server side code, HTML, JS, images, CSS etc). The only real server
>> side component is jolokia which is a small (about 300K) REST connector
>> for JMX (which is awesome BTW!) - the rest is static content (which
>> could be served from anywhere so doesn't need to be deployed in each
>> JVM).
>>
>> Its based around a plugin architecture:
>> http://hawt.io/developers/plugins.html
>>
>> so its easy to add new plugins for any kind of technology. A plugin is
>> pretty much anything that runs in a browser.
>>
>> The nice thing is hawtio can discover UI plugins at runtime by
>> examining the contents of the JVM or querying REST endpoints; so the
>> UI can update in real time as you deploy new things into a JVM!
>>
>>
>> hawtio, the hawt camel rider
>> ======================
>> A quick summary of the current features for camel folks:
>>
>> * If you have any camel contexts running in a JVM when hawtio starts
>> up it adds an Integration tab which shows all the camel contexts
>> running.
>>
>> * You can start/stop/suspend/resume the context and its routes; then
>> look at all the metrics for routes/endpoints/processors. The Charts
>> tab lets you visualise the real time metrics.
>>
>> * You can create new endpoints; browse endpoints which are browsable &
>> send messages to endpoints (with syntax editing support for JSON / XML
>> / YAML / properties)
>>
>> * You can visualise all the camel routes or a specific camel route for
>> a context in the Diagram tab and see real time metrics of how many
>> messages are passing through each step on the diagram. e.g.
>> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>>
>> * Clicking on a Route allows you to Trace it; when tracing if you send
>> a message into a route then it captures a copy of the message at each
>> point through the route. So you can step through (scroll/click through
>> the table) a route and see the message contents and how the message
>> flows through the EIPs - highlighting where on the diagram each
>> message is. This is very handy for figuring out why your route doesn't
>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>> go where you expected.
>>
>> In general most of the runtime features of the open source Fuse IDE
>> eclipse tooling are now supported in the camel hawtio plugin; so
>> available in a web browser.
>>
>>
>> Summary
>> =======
>> So if you're vaguely interested in web consoles for Apache Camel I
>> urge you to give it a try. We love contributions and feedback!
>> http://hawt.io/contributing/index.html
>>
>> or feel free to raise new issues for how to improve the camel plugin:
>> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>>
>> or if you've an itch for a new kind of plugin please dive in! We
>> should be able to expose existing web apps/consoles as links inside
>> hawtio too BTW.
>>
>> Feedback appreciated! Its hawt, but stay cool! ;)
>>
>> --
>> James
>> -------
>> Red Hat
>>
>> Email: jstracha@redhat.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>>
>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Schneider <ch...@die-schneider.net>.
I have not looked into HawtIO in detail but the idea of having a general
console with plugins for each technology sounds good to me.
I also think it is good to start such a console separately in github as
it allows for fast progress to show it works.

For the long term I think that the generic part of such a console should
move into an apache project. As it makes sense to keep the console
independent of OSGi a separate project may make sense.
So why should we do this in apache? The reason is that currently HawtIO
is just another console. Only at a big community like apache we can hope
for a project to get enough acceptance that a lot of projects participate.

So if we succeed in creating an accepted generic foundation for
management consoles then each of the technology plugins could be
developed in the respective projects.

What do you think about this?

Christian

On 25.01.2013 12:08, Guillaume Nodet wrote:
> FYI, I'm really excited about finally being able to have a unified web
> console for Karaf / ActiveMQ / Camel, especially the fact that the same web
> console can be used in a non OSGi-environment, so we can really leverage
> and work together on a single web console.
> I'd encourage everyone to have a look at it and eventually look at what's
> missing from a Karaf point of view so that we can discuss if/how we
> integrate it.
>
> ---------- Forwarded message ----------
> From: James Strachan <ja...@gmail.com>
> Date: Fri, Jan 25, 2013 at 10:59 AM
> Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
> ActiveMQ, JMX, OSGi & Fuse Fabric
> To: "users@camel.apache.org" <us...@camel.apache.org>
>
>
> For the impatient just look here :) http://hawt.io/
>
> Background
> ==========
> We've had numerous consoles all over the place for some time in
> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> Fabric to name but a few. Many of them quite heavy weight requiring a
> custom web app to be deployed (which often is quite large); none
> particularly working together.
>
> We've been working on Fuse Fabric and its management console to
> provide a more consolidated view of a cluster of Apache integration &
> middleware technologies. Increasingly we're seeing our users and
> customers using different combinations of technologies in different
> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> Karaf + ActiveMQ + Camel or whatever).
>
> So for a few months a few of us have been working on trying to make
> the various web consoles for things like Apache Camel, ActiveMQ,
> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> and matched together to suite any container and combination of
> technologies that folks deploy in a JVM.
>
>
> hawtio
> =====
> The result so far is hawtio: http://hawt.io/
>
> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> provides a UI console for whatever it finds in the JVM. So it works
> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> way.
>
> The nice thing is its pretty small (about 1Mb WAR containing all the
> server side code, HTML, JS, images, CSS etc). The only real server
> side component is jolokia which is a small (about 300K) REST connector
> for JMX (which is awesome BTW!) - the rest is static content (which
> could be served from anywhere so doesn't need to be deployed in each
> JVM).
>
> Its based around a plugin architecture:
> http://hawt.io/developers/plugins.html
>
> so its easy to add new plugins for any kind of technology. A plugin is
> pretty much anything that runs in a browser.
>
> The nice thing is hawtio can discover UI plugins at runtime by
> examining the contents of the JVM or querying REST endpoints; so the
> UI can update in real time as you deploy new things into a JVM!
>
>
> hawtio, the hawt camel rider
> ======================
> A quick summary of the current features for camel folks:
>
> * If you have any camel contexts running in a JVM when hawtio starts
> up it adds an Integration tab which shows all the camel contexts
> running.
>
> * You can start/stop/suspend/resume the context and its routes; then
> look at all the metrics for routes/endpoints/processors. The Charts
> tab lets you visualise the real time metrics.
>
> * You can create new endpoints; browse endpoints which are browsable &
> send messages to endpoints (with syntax editing support for JSON / XML
> / YAML / properties)
>
> * You can visualise all the camel routes or a specific camel route for
> a context in the Diagram tab and see real time metrics of how many
> messages are passing through each step on the diagram. e.g.
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>
> * Clicking on a Route allows you to Trace it; when tracing if you send
> a message into a route then it captures a copy of the message at each
> point through the route. So you can step through (scroll/click through
> the table) a route and see the message contents and how the message
> flows through the EIPs - highlighting where on the diagram each
> message is. This is very handy for figuring out why your route doesn't
> work :) Spot where the heading disappears! Or see why the CBR doesn't
> go where you expected.
>
> In general most of the runtime features of the open source Fuse IDE
> eclipse tooling are now supported in the camel hawtio plugin; so
> available in a web browser.
>
>
> Summary
> =======
> So if you're vaguely interested in web consoles for Apache Camel I
> urge you to give it a try. We love contributions and feedback!
> http://hawt.io/contributing/index.html
>
> or feel free to raise new issues for how to improve the camel plugin:
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>
> or if you've an itch for a new kind of plugin please dive in! We
> should be able to expose existing web apps/consoles as links inside
> hawtio too BTW.
>
> Feedback appreciated! Its hawt, but stay cool! ;)
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Fwd: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Guillaume Nodet <gn...@gmail.com>.
FYI, I'm really excited about finally being able to have a unified web
console for Karaf / ActiveMQ / Camel, especially the fact that the same web
console can be used in a non OSGi-environment, so we can really leverage
and work together on a single web console.
I'd encourage everyone to have a look at it and eventually look at what's
missing from a Karaf point of view so that we can discuss if/how we
integrate it.

---------- Forwarded message ----------
From: James Strachan <ja...@gmail.com>
Date: Fri, Jan 25, 2013 at 10:59 AM
Subject: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel,
ActiveMQ, JMX, OSGi & Fuse Fabric
To: "users@camel.apache.org" <us...@camel.apache.org>


For the impatient just look here :) http://hawt.io/

Background
==========
We've had numerous consoles all over the place for some time in
various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
Fabric to name but a few. Many of them quite heavy weight requiring a
custom web app to be deployed (which often is quite large); none
particularly working together.

We've been working on Fuse Fabric and its management console to
provide a more consolidated view of a cluster of Apache integration &
middleware technologies. Increasingly we're seeing our users and
customers using different combinations of technologies in different
containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
Karaf + ActiveMQ + Camel or whatever).

So for a few months a few of us have been working on trying to make
the various web consoles for things like Apache Camel, ActiveMQ,
Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
& OSGi) available as lightweight HTML5 plugins so they can be mixed
and matched together to suite any container and combination of
technologies that folks deploy in a JVM.


hawtio
=====
The result so far is hawtio: http://hawt.io/

You can deploy it as a WAR in any JVM (or feature in karaf) and it
provides a UI console for whatever it finds in the JVM. So it works
with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
way.

The nice thing is its pretty small (about 1Mb WAR containing all the
server side code, HTML, JS, images, CSS etc). The only real server
side component is jolokia which is a small (about 300K) REST connector
for JMX (which is awesome BTW!) - the rest is static content (which
could be served from anywhere so doesn't need to be deployed in each
JVM).

Its based around a plugin architecture:
http://hawt.io/developers/plugins.html

so its easy to add new plugins for any kind of technology. A plugin is
pretty much anything that runs in a browser.

The nice thing is hawtio can discover UI plugins at runtime by
examining the contents of the JVM or querying REST endpoints; so the
UI can update in real time as you deploy new things into a JVM!


hawtio, the hawt camel rider
======================
A quick summary of the current features for camel folks:

* If you have any camel contexts running in a JVM when hawtio starts
up it adds an Integration tab which shows all the camel contexts
running.

* You can start/stop/suspend/resume the context and its routes; then
look at all the metrics for routes/endpoints/processors. The Charts
tab lets you visualise the real time metrics.

* You can create new endpoints; browse endpoints which are browsable &
send messages to endpoints (with syntax editing support for JSON / XML
/ YAML / properties)

* You can visualise all the camel routes or a specific camel route for
a context in the Diagram tab and see real time metrics of how many
messages are passing through each step on the diagram. e.g.
https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png

* Clicking on a Route allows you to Trace it; when tracing if you send
a message into a route then it captures a copy of the message at each
point through the route. So you can step through (scroll/click through
the table) a route and see the message contents and how the message
flows through the EIPs - highlighting where on the diagram each
message is. This is very handy for figuring out why your route doesn't
work :) Spot where the heading disappears! Or see why the CBR doesn't
go where you expected.

In general most of the runtime features of the open source Fuse IDE
eclipse tooling are now supported in the camel hawtio plugin; so
available in a web browser.


Summary
=======
So if you're vaguely interested in web consoles for Apache Camel I
urge you to give it a try. We love contributions and feedback!
http://hawt.io/contributing/index.html

or feel free to raise new issues for how to improve the camel plugin:
https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open

or if you've an itch for a new kind of plugin please dive in! We
should be able to expose existing web apps/consoles as links inside
hawtio too BTW.

Feedback appreciated! Its hawt, but stay cool! ;)

--
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
for me it worked issuing

install https://oss.sonatype.org/content/repositories/snapshots/io/hawt/hawtio-web/1.0-SNAPSHOT/hawtio-web-1.0-20130125.104750-35.war instead of the mvn url

With kind regards

Maruan Sahyoun

Am 27.01.2013 um 19:43 schrieb Christian Müller <ch...@gmail.com>:

> Hi James (and all others involved creating this product)!
> 
> Congrats for this product. It looks awesome (without having the time to go
> into the details until now). I wish you success with it.
> 
> At present, I think the best is to let the project grow up at GitHub and
> see whether it will get a solid user basis (I bet it will). If it has
> success and you want donate to Apache, I think a new TLP is the best place
> (after going through the incubator), because it is so generic (supports
> different runtime environments, supports different projects, ...).
> 
> If I understand it correct, Hawtio is shipt by default with a Camel plugin,
> right?
> This means if we want to improve this plugin, we have to submit a
> patch/pull request (or forge it), right?
> Which features you figured out are still missing?
> 
> By the way, I couldn't install it into Karaf 2.3.0. I followed your
> instructions by editing org.ops4j.pax.url.mvn.cfg (shouldn't be the url
> https://oss.sonatype.org/content/repositories/snapshots instead of
> https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo?).
> I got the following output:
> 
> Christian-Muellers-MacBook-Pro:bin cmueller$ ./karaf clean
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>        __ __                  ____
>       / //_/____ __________ _/ __/
>      / ,<  / __ `/ ___/ __ `/ /_
>     / /| |/ /_/ / /  / /_/ / __/
>    /_/ |_|\__,_/_/   \__,_/_/
> 
>  Apache Karaf (2.3.0)
> 
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown Karaf.
> 
> karaf@root> features:install war
> karaf@root> install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
> Bundle IDs:
> Error executing command: Error installing bundles:
>    Unable to install bundle mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
> 
> Best,
> Christian
> 
> On Fri, Jan 25, 2013 at 10:59 AM, James Strachan
> <ja...@gmail.com>wrote:
> 
>> For the impatient just look here :) http://hawt.io/
>> 
>> Background
>> ==========
>> We've had numerous consoles all over the place for some time in
>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>> Fabric to name but a few. Many of them quite heavy weight requiring a
>> custom web app to be deployed (which often is quite large); none
>> particularly working together.
>> 
>> We've been working on Fuse Fabric and its management console to
>> provide a more consolidated view of a cluster of Apache integration &
>> middleware technologies. Increasingly we're seeing our users and
>> customers using different combinations of technologies in different
>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>> Karaf + ActiveMQ + Camel or whatever).
>> 
>> So for a few months a few of us have been working on trying to make
>> the various web consoles for things like Apache Camel, ActiveMQ,
>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>> and matched together to suite any container and combination of
>> technologies that folks deploy in a JVM.
>> 
>> 
>> hawtio
>> =====
>> The result so far is hawtio: http://hawt.io/
>> 
>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>> provides a UI console for whatever it finds in the JVM. So it works
>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>> way.
>> 
>> The nice thing is its pretty small (about 1Mb WAR containing all the
>> server side code, HTML, JS, images, CSS etc). The only real server
>> side component is jolokia which is a small (about 300K) REST connector
>> for JMX (which is awesome BTW!) - the rest is static content (which
>> could be served from anywhere so doesn't need to be deployed in each
>> JVM).
>> 
>> Its based around a plugin architecture:
>> http://hawt.io/developers/plugins.html
>> 
>> so its easy to add new plugins for any kind of technology. A plugin is
>> pretty much anything that runs in a browser.
>> 
>> The nice thing is hawtio can discover UI plugins at runtime by
>> examining the contents of the JVM or querying REST endpoints; so the
>> UI can update in real time as you deploy new things into a JVM!
>> 
>> 
>> hawtio, the hawt camel rider
>> ======================
>> A quick summary of the current features for camel folks:
>> 
>> * If you have any camel contexts running in a JVM when hawtio starts
>> up it adds an Integration tab which shows all the camel contexts
>> running.
>> 
>> * You can start/stop/suspend/resume the context and its routes; then
>> look at all the metrics for routes/endpoints/processors. The Charts
>> tab lets you visualise the real time metrics.
>> 
>> * You can create new endpoints; browse endpoints which are browsable &
>> send messages to endpoints (with syntax editing support for JSON / XML
>> / YAML / properties)
>> 
>> * You can visualise all the camel routes or a specific camel route for
>> a context in the Diagram tab and see real time metrics of how many
>> messages are passing through each step on the diagram. e.g.
>> 
>> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>> 
>> * Clicking on a Route allows you to Trace it; when tracing if you send
>> a message into a route then it captures a copy of the message at each
>> point through the route. So you can step through (scroll/click through
>> the table) a route and see the message contents and how the message
>> flows through the EIPs - highlighting where on the diagram each
>> message is. This is very handy for figuring out why your route doesn't
>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>> go where you expected.
>> 
>> In general most of the runtime features of the open source Fuse IDE
>> eclipse tooling are now supported in the camel hawtio plugin; so
>> available in a web browser.
>> 
>> 
>> Summary
>> =======
>> So if you're vaguely interested in web consoles for Apache Camel I
>> urge you to give it a try. We love contributions and feedback!
>> http://hawt.io/contributing/index.html
>> 
>> or feel free to raise new issues for how to improve the camel plugin:
>> 
>> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>> 
>> or if you've an itch for a new kind of plugin please dive in! We
>> should be able to expose existing web apps/consoles as links inside
>> hawtio too BTW.
>> 
>> Feedback appreciated! Its hawt, but stay cool! ;)
>> 
>> --
>> James
>> -------
>> Red Hat
>> 
>> Email: jstracha@redhat.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>> 
>> Open Source Integration
>> 
> 
> 
> 
> --


Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Hadrian Zbarcea <hz...@gmail.com>.
Well, I think I do understand the issue Lukasz is bringing up. I am 
blaming his ESL on not sending the message across very well.

One thing would help (I think) is to move the traffic related to hawt.io 
on the hawt.io site, off the @camel lists. (Same goes for the 
camel-extra project.)

Cheers,
Hadrian


On 01/27/2013 01:43 PM, Christian Müller wrote:
> Hi James (and all others involved creating this product)!
>
> Congrats for this product. It looks awesome (without having the time to go
> into the details until now). I wish you success with it.
>
> At present, I think the best is to let the project grow up at GitHub and
> see whether it will get a solid user basis (I bet it will). If it has
> success and you want donate to Apache, I think a new TLP is the best place
> (after going through the incubator), because it is so generic (supports
> different runtime environments, supports different projects, ...).
>
> If I understand it correct, Hawtio is shipt by default with a Camel plugin,
> right?
> This means if we want to improve this plugin, we have to submit a
> patch/pull request (or forge it), right?
> Which features you figured out are still missing?
>
> By the way, I couldn't install it into Karaf 2.3.0. I followed your
> instructions by editing org.ops4j.pax.url.mvn.cfg (shouldn't be the url
> https://oss.sonatype.org/content/repositories/snapshots instead of
> https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo?).
> I got the following output:
>
> Christian-Muellers-MacBook-Pro:bin cmueller$ ./karaf clean
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>          __ __                  ____
>         / //_/____ __________ _/ __/
>        / ,<  / __ `/ ___/ __ `/ /_
>       / /| |/ /_/ / /  / /_/ / __/
>      /_/ |_|\__,_/_/   \__,_/_/
>
>    Apache Karaf (2.3.0)
>
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown Karaf.
>
> karaf@root> features:install war
> karaf@root> install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
> Bundle IDs:
> Error executing command: Error installing bundles:
>      Unable to install bundle mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
>
> Best,
> Christian
>
> On Fri, Jan 25, 2013 at 10:59 AM, James Strachan
> <ja...@gmail.com>wrote:
>
>> For the impatient just look here :) http://hawt.io/
>>
>> Background
>> ==========
>> We've had numerous consoles all over the place for some time in
>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>> Fabric to name but a few. Many of them quite heavy weight requiring a
>> custom web app to be deployed (which often is quite large); none
>> particularly working together.
>>
>> We've been working on Fuse Fabric and its management console to
>> provide a more consolidated view of a cluster of Apache integration &
>> middleware technologies. Increasingly we're seeing our users and
>> customers using different combinations of technologies in different
>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>> Karaf + ActiveMQ + Camel or whatever).
>>
>> So for a few months a few of us have been working on trying to make
>> the various web consoles for things like Apache Camel, ActiveMQ,
>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>> and matched together to suite any container and combination of
>> technologies that folks deploy in a JVM.
>>
>>
>> hawtio
>> =====
>> The result so far is hawtio: http://hawt.io/
>>
>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>> provides a UI console for whatever it finds in the JVM. So it works
>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>> way.
>>
>> The nice thing is its pretty small (about 1Mb WAR containing all the
>> server side code, HTML, JS, images, CSS etc). The only real server
>> side component is jolokia which is a small (about 300K) REST connector
>> for JMX (which is awesome BTW!) - the rest is static content (which
>> could be served from anywhere so doesn't need to be deployed in each
>> JVM).
>>
>> Its based around a plugin architecture:
>> http://hawt.io/developers/plugins.html
>>
>> so its easy to add new plugins for any kind of technology. A plugin is
>> pretty much anything that runs in a browser.
>>
>> The nice thing is hawtio can discover UI plugins at runtime by
>> examining the contents of the JVM or querying REST endpoints; so the
>> UI can update in real time as you deploy new things into a JVM!
>>
>>
>> hawtio, the hawt camel rider
>> ======================
>> A quick summary of the current features for camel folks:
>>
>> * If you have any camel contexts running in a JVM when hawtio starts
>> up it adds an Integration tab which shows all the camel contexts
>> running.
>>
>> * You can start/stop/suspend/resume the context and its routes; then
>> look at all the metrics for routes/endpoints/processors. The Charts
>> tab lets you visualise the real time metrics.
>>
>> * You can create new endpoints; browse endpoints which are browsable &
>> send messages to endpoints (with syntax editing support for JSON / XML
>> / YAML / properties)
>>
>> * You can visualise all the camel routes or a specific camel route for
>> a context in the Diagram tab and see real time metrics of how many
>> messages are passing through each step on the diagram. e.g.
>>
>> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>>
>> * Clicking on a Route allows you to Trace it; when tracing if you send
>> a message into a route then it captures a copy of the message at each
>> point through the route. So you can step through (scroll/click through
>> the table) a route and see the message contents and how the message
>> flows through the EIPs - highlighting where on the diagram each
>> message is. This is very handy for figuring out why your route doesn't
>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>> go where you expected.
>>
>> In general most of the runtime features of the open source Fuse IDE
>> eclipse tooling are now supported in the camel hawtio plugin; so
>> available in a web browser.
>>
>>
>> Summary
>> =======
>> So if you're vaguely interested in web consoles for Apache Camel I
>> urge you to give it a try. We love contributions and feedback!
>> http://hawt.io/contributing/index.html
>>
>> or feel free to raise new issues for how to improve the camel plugin:
>>
>> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>>
>> or if you've an itch for a new kind of plugin please dive in! We
>> should be able to expose existing web apps/consoles as links inside
>> hawtio too BTW.
>>
>> Feedback appreciated! Its hawt, but stay cool! ;)
>>
>> --
>> James
>> -------
>> Red Hat
>>
>> Email: jstracha@redhat.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>>
>
>
>
> --
>

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
Just in case others are trying it in karaf; we just hit an issue deploying
hawtio in jboss; so have made 'hawtio-osgi' for deploying hawtio in OSGi
containers; then 'hawtio-web.war' works out of the box in Tomcat, Jetty,
JBoss.

So the command line is now this until we cut a release:

install
https://oss.sonatype.org/content/repositories/snapshots/io/hawt/hawtio-osgi/1.0-SNAPSHOT/hawtio-osgi-1.0-20130128.154950-1.war

If in doubt check out the instructions on the home page; we'll try to keep
them up to date...
http://hawt.io/


On 27 January 2013 18:43, Christian Müller <ch...@gmail.com>wrote:

> Hi James (and all others involved creating this product)!
>
> Congrats for this product. It looks awesome (without having the time to go
> into the details until now). I wish you success with it.
>
> At present, I think the best is to let the project grow up at GitHub and
> see whether it will get a solid user basis (I bet it will). If it has
> success and you want donate to Apache, I think a new TLP is the best place
> (after going through the incubator), because it is so generic (supports
> different runtime environments, supports different projects, ...).
>
> If I understand it correct, Hawtio is shipt by default with a Camel
> plugin, right?
> This means if we want to improve this plugin, we have to submit a
> patch/pull request (or forge it), right?
> Which features you figured out are still missing?
>
> By the way, I couldn't install it into Karaf 2.3.0. I followed your
> instructions by editing org.ops4j.pax.url.mvn.cfg (shouldn't be the url
> https://oss.sonatype.org/content/repositories/snapshots instead of
> https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo?).
> I got the following output:
>
> Christian-Muellers-MacBook-Pro:bin cmueller$ ./karaf clean
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>         __ __                  ____
>        / //_/____ __________ _/ __/
>       / ,<  / __ `/ ___/ __ `/ /_
>      / /| |/ /_/ / /  / /_/ / __/
>     /_/ |_|\__,_/_/   \__,_/_/
>
>   Apache Karaf (2.3.0)
>
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown Karaf.
>
> karaf@root> features:install war
> karaf@root> install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
> Bundle IDs:
> Error executing command: Error installing bundles:
>     Unable to install bundle mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
>
> Best,
> Christian
>
> On Fri, Jan 25, 2013 at 10:59 AM, James Strachan <james.strachan@gmail.com
> > wrote:
>
>> For the impatient just look here :) http://hawt.io/
>>
>> Background
>> ==========
>> We've had numerous consoles all over the place for some time in
>> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
>> Fabric to name but a few. Many of them quite heavy weight requiring a
>> custom web app to be deployed (which often is quite large); none
>> particularly working together.
>>
>> We've been working on Fuse Fabric and its management console to
>> provide a more consolidated view of a cluster of Apache integration &
>> middleware technologies. Increasingly we're seeing our users and
>> customers using different combinations of technologies in different
>> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
>> Karaf + ActiveMQ + Camel or whatever).
>>
>> So for a few months a few of us have been working on trying to make
>> the various web consoles for things like Apache Camel, ActiveMQ,
>> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
>> & OSGi) available as lightweight HTML5 plugins so they can be mixed
>> and matched together to suite any container and combination of
>> technologies that folks deploy in a JVM.
>>
>>
>> hawtio
>> =====
>> The result so far is hawtio: http://hawt.io/
>>
>> You can deploy it as a WAR in any JVM (or feature in karaf) and it
>> provides a UI console for whatever it finds in the JVM. So it works
>> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
>> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
>> way.
>>
>> The nice thing is its pretty small (about 1Mb WAR containing all the
>> server side code, HTML, JS, images, CSS etc). The only real server
>> side component is jolokia which is a small (about 300K) REST connector
>> for JMX (which is awesome BTW!) - the rest is static content (which
>> could be served from anywhere so doesn't need to be deployed in each
>> JVM).
>>
>> Its based around a plugin architecture:
>> http://hawt.io/developers/plugins.html
>>
>> so its easy to add new plugins for any kind of technology. A plugin is
>> pretty much anything that runs in a browser.
>>
>> The nice thing is hawtio can discover UI plugins at runtime by
>> examining the contents of the JVM or querying REST endpoints; so the
>> UI can update in real time as you deploy new things into a JVM!
>>
>>
>> hawtio, the hawt camel rider
>> ======================
>> A quick summary of the current features for camel folks:
>>
>> * If you have any camel contexts running in a JVM when hawtio starts
>> up it adds an Integration tab which shows all the camel contexts
>> running.
>>
>> * You can start/stop/suspend/resume the context and its routes; then
>> look at all the metrics for routes/endpoints/processors. The Charts
>> tab lets you visualise the real time metrics.
>>
>> * You can create new endpoints; browse endpoints which are browsable &
>> send messages to endpoints (with syntax editing support for JSON / XML
>> / YAML / properties)
>>
>> * You can visualise all the camel routes or a specific camel route for
>> a context in the Diagram tab and see real time metrics of how many
>> messages are passing through each step on the diagram. e.g.
>>
>> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>>
>> * Clicking on a Route allows you to Trace it; when tracing if you send
>> a message into a route then it captures a copy of the message at each
>> point through the route. So you can step through (scroll/click through
>> the table) a route and see the message contents and how the message
>> flows through the EIPs - highlighting where on the diagram each
>> message is. This is very handy for figuring out why your route doesn't
>> work :) Spot where the heading disappears! Or see why the CBR doesn't
>> go where you expected.
>>
>> In general most of the runtime features of the open source Fuse IDE
>> eclipse tooling are now supported in the camel hawtio plugin; so
>> available in a web browser.
>>
>>
>> Summary
>> =======
>> So if you're vaguely interested in web consoles for Apache Camel I
>> urge you to give it a try. We love contributions and feedback!
>> http://hawt.io/contributing/index.html
>>
>> or feel free to raise new issues for how to improve the camel plugin:
>>
>> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>>
>> or if you've an itch for a new kind of plugin please dive in! We
>> should be able to expose existing web apps/consoles as links inside
>> hawtio too BTW.
>>
>> Feedback appreciated! Its hawt, but stay cool! ;)
>>
>> --
>> James
>> -------
>> Red Hat
>>
>> Email: jstracha@redhat.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>>
>
>
>
> --
>
>


-- 
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by James Strachan <ja...@gmail.com>.
On 27 January 2013 18:43, Christian Müller <ch...@gmail.com>wrote:

> Hi James (and all others involved creating this product)!
>
> Congrats for this product. It looks awesome (without having the time to go
> into the details until now). I wish you success with it.
>

Many thanks!


At present, I think the best is to let the project grow up at GitHub and
> see whether it will get a solid user basis (I bet it will). If it has
> success and you want donate to Apache, I think a new TLP is the best place
> (after going through the incubator), because it is so generic (supports
> different runtime environments, supports different projects, ...).
>
> If I understand it correct, Hawtio is shipt by default with a Camel
> plugin, right?
> This means if we want to improve this plugin, we have to submit a
> patch/pull request (or forge it), right?
>

Yeah, thats the easiest thing for now:
http://hawt.io/contributing/index.html

Folks could create extra plugins too (either inside Apache Camel or on
github) if they wanted. e.g. the camel-watch web app looks cool.



> Which features you figured out are still missing?
>

Here's the current pending camel issues.
https://github.com/hawtio/hawtio/issues?labels=camel&page=1&state=open

If anyone has ideas for improvements to the camel plugin, please raise an
issue there or please dive in and help fix the existing issues :)


>
> By the way, I couldn't install it into Karaf 2.3.0. I followed your
> instructions by editing org.ops4j.pax.url.mvn.cfg (shouldn't be the url
> https://oss.sonatype.org/content/repositories/snapshots instead of
> https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo?).
> I got the following output:
>
> Christian-Muellers-MacBook-Pro:bin cmueller$ ./karaf clean
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>         __ __                  ____
>        / //_/____ __________ _/ __/
>       / ,<  / __ `/ ___/ __ `/ /_
>      / /| |/ /_/ / /  / /_/ / __/
>     /_/ |_|\__,_/_/   \__,_/_/
>
>   Apache Karaf (2.3.0)
>
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown Karaf.
>
> karaf@root> features:install war
> karaf@root> install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
> Bundle IDs:
> Error executing command: Error installing bundles:
>     Unable to install bundle mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
>

Ah it looked like Maruan figured it out (thanks Maruan!); its a snapsnot
issue. Hopefully we can get 1.0 out really soon to avoid folks having
SNAPSHOT pain! (A karaf feature would be nice too...)

-- 
James
-------
Red Hat

Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

Open Source Integration

Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi & Fuse Fabric

Posted by Christian Müller <ch...@gmail.com>.
Hi James (and all others involved creating this product)!

Congrats for this product. It looks awesome (without having the time to go
into the details until now). I wish you success with it.

At present, I think the best is to let the project grow up at GitHub and
see whether it will get a solid user basis (I bet it will). If it has
success and you want donate to Apache, I think a new TLP is the best place
(after going through the incubator), because it is so generic (supports
different runtime environments, supports different projects, ...).

If I understand it correct, Hawtio is shipt by default with a Camel plugin,
right?
This means if we want to improve this plugin, we have to submit a
patch/pull request (or forge it), right?
Which features you figured out are still missing?

By the way, I couldn't install it into Karaf 2.3.0. I followed your
instructions by editing org.ops4j.pax.url.mvn.cfg (shouldn't be the url
https://oss.sonatype.org/content/repositories/snapshots instead of
https://oss.sonatype.org/content/repositories/snapshots=sonatype.snapshot.repo?).
I got the following output:

Christian-Muellers-MacBook-Pro:bin cmueller$ ./karaf clean
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
        __ __                  ____
       / //_/____ __________ _/ __/
      / ,<  / __ `/ ___/ __ `/ /_
     / /| |/ /_/ / /  / /_/ / __/
    /_/ |_|\__,_/_/   \__,_/_/

  Apache Karaf (2.3.0)

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown Karaf.

karaf@root> features:install war
karaf@root> install mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war
Bundle IDs:
Error executing command: Error installing bundles:
    Unable to install bundle mvn:io.hawt/hawtio-web/1.0-SNAPSHOT/war

Best,
Christian

On Fri, Jan 25, 2013 at 10:59 AM, James Strachan
<ja...@gmail.com>wrote:

> For the impatient just look here :) http://hawt.io/
>
> Background
> ==========
> We've had numerous consoles all over the place for some time in
> various projects like Felix, Karaf, ActiveMQ, Camel, Tomcat, Fuse
> Fabric to name but a few. Many of them quite heavy weight requiring a
> custom web app to be deployed (which often is quite large); none
> particularly working together.
>
> We've been working on Fuse Fabric and its management console to
> provide a more consolidated view of a cluster of Apache integration &
> middleware technologies. Increasingly we're seeing our users and
> customers using different combinations of technologies in different
> containers (e.g. Tomcat + ActiveMQ or Karaf + Camel or Fuse Fabric +
> Karaf + ActiveMQ + Camel or whatever).
>
> So for a few months a few of us have been working on trying to make
> the various web consoles for things like Apache Camel, ActiveMQ,
> Felix/Karaf/OSGi & Fuse Fabric (long with more generic things like JMX
> & OSGi) available as lightweight HTML5 plugins so they can be mixed
> and matched together to suite any container and combination of
> technologies that folks deploy in a JVM.
>
>
> hawtio
> =====
> The result so far is hawtio: http://hawt.io/
>
> You can deploy it as a WAR in any JVM (or feature in karaf) and it
> provides a UI console for whatever it finds in the JVM. So it works
> with Tomcat / Jetty / Karaf / JBoss / Fuse Fabric; and has plugins for
> JMX, OSGi, ActiveMQ, Camel & Fuse Fabric so far with others on the
> way.
>
> The nice thing is its pretty small (about 1Mb WAR containing all the
> server side code, HTML, JS, images, CSS etc). The only real server
> side component is jolokia which is a small (about 300K) REST connector
> for JMX (which is awesome BTW!) - the rest is static content (which
> could be served from anywhere so doesn't need to be deployed in each
> JVM).
>
> Its based around a plugin architecture:
> http://hawt.io/developers/plugins.html
>
> so its easy to add new plugins for any kind of technology. A plugin is
> pretty much anything that runs in a browser.
>
> The nice thing is hawtio can discover UI plugins at runtime by
> examining the contents of the JVM or querying REST endpoints; so the
> UI can update in real time as you deploy new things into a JVM!
>
>
> hawtio, the hawt camel rider
> ======================
> A quick summary of the current features for camel folks:
>
> * If you have any camel contexts running in a JVM when hawtio starts
> up it adds an Integration tab which shows all the camel contexts
> running.
>
> * You can start/stop/suspend/resume the context and its routes; then
> look at all the metrics for routes/endpoints/processors. The Charts
> tab lets you visualise the real time metrics.
>
> * You can create new endpoints; browse endpoints which are browsable &
> send messages to endpoints (with syntax editing support for JSON / XML
> / YAML / properties)
>
> * You can visualise all the camel routes or a specific camel route for
> a context in the Diagram tab and see real time metrics of how many
> messages are passing through each step on the diagram. e.g.
>
> https://raw.github.com/hawtio/hawtio/master/website/src/images/screenshots/camelRoute.png
>
> * Clicking on a Route allows you to Trace it; when tracing if you send
> a message into a route then it captures a copy of the message at each
> point through the route. So you can step through (scroll/click through
> the table) a route and see the message contents and how the message
> flows through the EIPs - highlighting where on the diagram each
> message is. This is very handy for figuring out why your route doesn't
> work :) Spot where the heading disappears! Or see why the CBR doesn't
> go where you expected.
>
> In general most of the runtime features of the open source Fuse IDE
> eclipse tooling are now supported in the camel hawtio plugin; so
> available in a web browser.
>
>
> Summary
> =======
> So if you're vaguely interested in web consoles for Apache Camel I
> urge you to give it a try. We love contributions and feedback!
> http://hawt.io/contributing/index.html
>
> or feel free to raise new issues for how to improve the camel plugin:
>
> https://github.com/hawtio/hawtio/issues?labels=camel&page=1&sort=updated&state=open
>
> or if you've an itch for a new kind of plugin please dive in! We
> should be able to expose existing web apps/consoles as links inside
> hawtio too BTW.
>
> Feedback appreciated! Its hawt, but stay cool! ;)
>
> --
> James
> -------
> Red Hat
>
> Email: jstracha@redhat.com
> Web: http://fusesource.com
> Twitter: jstrachan, fusenews
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
>



--