camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <>
Subject Re: Camel Web Console Questions
Date Thu, 26 May 2011 09:41:36 GMT

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.


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

View raw message