camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Camel Web Console Questions
Date Thu, 26 May 2011 10:51:26 GMT
I agree with everything Jim just said :)

So I'm sure we can trim the size down. e.g. we don't really need the
scala compiler for deployment; we can compile all the templates at
build time (though its very handy using it at development time for
rapid reloading of templates as you edit them on the fly so that could
be a maven profile thingy). In terms of dependencies, scalate mostly
just depends on scala-library (which is probably of similar size to
depending on JSP / JSTL / EL / Sitemesh et al).

If folks want to tinker with the build system and refactor the code so
we can create bundles and a separate WAR for folks who prefer WARs
thats cool with me.

Also we don't need to rewrite camel-web just to provide support for
multiple contexts; all thats really required is one or two resource
beans using the OSGi or JMX API to discover the contexts and a
template page or two and multiple contexts could be supported very
easily. One of the big reasons I chose JAXRS is its trivial to extend
a web application in a highly modular way; so folks can easily drop in
different UIs if they want. Plus its easy to put different facades on
top of the camel-web; e.g. you could just interact with its REST API
and put any UI you like on top of it.

Popping my FuseSource hat on for a second, next months Fuse IDE beta
already has support for connecting to remote JVMs via JMX or
connecting to a Fuse Fabric then just navigating to the process in
question - then being able to browse all the CamelContexts however
they are deployed (WARs in Tomcat/Jetty or bundles in Karaf/ServiceMix
or even just stand alone Java processes), view/edit the routes
graphically, interact with endpoints, browse messages, drag/drop
messages from/to different endpoints in any context in any process
and/or files/directories and trace routes so you can step through
routes and see how the messages change from step to step. I just gave
a brief demo of it at CamelOne this week, I'll post a link to the
video when its online & there'll hopefully be some screencasts next
month showing all this stuff. So if you want to use Eclipse you might
find Fuse IDE much more useful than camel-web for working with
multiple contexts. Personally I love being able to interact with
contexts/endpoints by just dragging messages/files around to/from
endpoints, browsing messages & stepping through routes to
diagnose/test/play with Camel! Have wanted something like this for
years now!

Though its worth emphasising, Fuse IDE is aimed at developers for
developing/testing applications using Camel - so its Eclipse based.
Its not really an operational management tool; for that we've a
separate tool called "Fuse Operational Network" which is a management
console and aimed more at devops stuff (managing, monitoring,
provisioning, controlling, charting, alerting etc), the private beta
for that starts later this year.

On 26 May 2011 10:41, Jim Talbut <> wrote:
> Tarun,
> I'm just another user, but I've recently been trying to turn camel-web into
> something that suits my needs.
> There are certainly problems with camel-web, but I'm not convinced that
> Tarun's heading in completely the right direction.
> The two big problems with camel-web for me are:
> 1. I use OSGi and need multiple contexts.  This is what I'm fixing as and
> when I get the chance.
> 2. I want more information about the endpoints (i.e. I want complete details
> of the CXF endpoints even when they are configured via a bean).
> camel-web-2.8-SNAPSHOT.war is 28MB, is that really "very heavy"?
> I think the choice of JAX-RS was the right one for camel-web, and I would be
> wary about working on a REST based system that did not use it (simply
> because it would be more complex).
> The choice of Jersey over CXF-RS seems to have been made in order to get
> support for implicit view providers (@ImplicitProduces) - a simple grep
> shows that no other pom.xml references jersey whilst some do reference
> CXF-RS.  I would be more at home with CXF-RS, but implicit view providers
> are quite neat for turning a REST service into a website.  I have no idea of
> the relative sizes of everything required for jersey vs everything required
> for CXF-RS (but if CXF-RS is there anyway then certainly jersey has to work
> hard to justify itself).
> I think the choice of scalate was a mistake.  It does its job well, but it
> is relatively heavyweight and, much more importantly, is not well known and
> thus makes things more difficult for contributors (it took me a long time to
> get the implicit views working in OSGi).
> camel-web is not, and IMHO should not be, an all-singing, all-dancing
> monitoring platform - but it should be more than the proof of concept that
> it appears to be now.
> It should (IMHO) provide a full (REST probably, but possible something else)
> interface to allow camel data to be integrated into your choice of
> all-singing, all-dancing monitoring platform.
> If a web interface over the REST interface can be provided easily then great
> - and I don't care whether that's server side or client side.
> camel-web can be extended easily thanks to maven war overlays (allowing you
> to add files and to replace any of the files in the original war).
> How else can camel-web be both self contained and extensible?
> Maybe the correct answer is to split it up into more bits (and not try to be
> both self contained and extensible), that would at least allow the OSGi
> bundle to be smaller and more OSGi-ish.
> Having been through this process myself over the last couple of weeks I
> ended up concluding that I was better off spending my time converting
> camel-web into something better rather than starting again.
> Jim
> On 25/05/2011 16:13, boday wrote:
>> There has been a lot of discussion about reworking camel-web with regards
>> to
>> OSGI and multiple contexts.  Overall, I agree that this app should be much
>> more comprehensive, extensible and easy to integrate with existing apps.
>>  If
>> camel-web can evolve into this...great.  But currently, for specific
>> requirements, camel-web is difficult to integrate and customize.  I ended
>> up
>> having to build a custom monitoring app for a client recently using HTML,
>> CSS, jQuery, JMX, JSP/Servlets, Google Charts, etc.
>> Maybe someone from the Fuse team can comment on whether the roadmap for
>> Fuse
>> IDE (or camel-web) overlaps with this effort or not.  But I think a new
>> Camel subproject would be a good place to experiment with some alternate
>> approaches for this.
>> Tarun Ramakrishna-2 wrote:
>>> Hi,
>>> At a first glance (please correct me if I am wrong), the camel web
>>> console implementation appears to be very heavy - depending on Scala,
>>> scala template engines and several Jersey libraries which have a
>>> non-Apache licenses. It also appears to be unsuited to running on an
>>> OSGi environment where different bundles can contribute camel
>>> contexts.
>>> Would the committers be interested if someone re-wrote this web-app to
>>> be more simpler (use HTML 5 techniques and move UI logic to client
>>> instead of heavy template engines), remove the Jersey dependencies
>>> (simply use servlets and a plain JSON library or if JAX/WS is really
>>> wanted use CXF for this) and abstract the lookup of Camel Contexts
>>> through some interface? Or is the community more than happy with what
>>> is there now and wouldn't like  anything changed ?
>>> Best Regards,
>>> Tarun
>> -----
>> Ben O'Day
>> IT Consultant -
>> --
>> View this message in context:
>> Sent from the Camel - Users mailing list archive at

Twitter: jstrachan, fusenews

Open Source Integration and Messaging

View raw message