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 -http://benoday.blogspot.com
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-Web-Console-Questions-tp4425291p4425611.html
Sent from the Camel - Users mailing list archive at Nabble.com.
