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 <jtal...@spudsoft.co.uk> 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 -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. > > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
