On 26/05/2011 13:13, James Strachan wrote:
On 26 May 2011 12:57, Jim Talbut wrote:
Yeah. How about /camel/{contextId}/routes/{routeId}
I picked /camel as the root URI for all contexts so that we can then
mix this web app with other web apps showing other things without
clashing
James
I've bee
On 26 May 2011 12:57, Jim Talbut wrote:
> On 26/05/2011 11:51, James Strachan wrote:
>>
>> 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
>>
On 26/05/2011 11:51, James Strachan wrote:
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 sup
Hi Jim,
I also am just another plain Camel user.
OSGi and multiple contexts: This is obviously a prime motivation. We
need to view and observe the details of multiple Camel Contexts
contributed by multiple bundles. The spring extender binds
ApplicationContext objects as OSGi services - we want to
meone 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 thi
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.
is) 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
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
