willem is the jaxws extension in the wsdl something that is commonly used? I have never seens this before. I am not keen on adding this to .wsdl files. I want them to be platform neutral

CAMEL-723

willem maybe CAMEL-520 is something you could look at now that you are stream cache expert ;)

davsclaus: There are some discription in the Chapter 8 of JAXWS 2.1 spec about the a standard customization facility that can be used to customize the WSDL 1.1 to Java binding.

davscalus: In 8.4 you can use an external binding file without touching the WSDL , I am hearding on this example now :)

willem - ah that is great ;) would love to reuse existing wsdl that is platform neutral - glad you are working on this ;)

hadrian: BTW the JMX tree for Camel looks kinda wonky when looking at it in JMX tools - with ActiveMQ you can clearly see whats what with folders for Queues/Topics/Subscriptions/Connections and so forth - in camel the folder within camelContext looks a bit wonky

e.g. we maybe need a routes folder ro something

so within a context you have endpoints, context, routes or something

jstrachan: so we'll need to play a bit again with the naming conventions

yeah

i didn't look at that in quite a while

time to get back to it

its kinda hard to do useful stuff in the FUSE web console currently as the JMX tree is kinda wonky

its maybe the 'consumer' mbeans that are looking wacky

i didn't look at the web console either in months

try just jconsole - it looks wacky in there too

e.g. I've 2 routes; I see one route mbean, only one endpoint mbean (despite there being 3 in use)

oh-oh, not good

jstrachan: how does you settings.xml look like for building fuse-console?

hadrian: no special settings required - it doesnt use any special plugins

hadrian: try jconsole though first

i will

there was something for gwt, builing now

the gwt stuff is hard to run currently; other than in the fuse-activemq distro or your IDE if you set it up to run GWT stuff

is there no ManagedCamelContext btw?

nope

the DefaultCamelContext has an InstrumentationLifecycleStrategy that handles all that iirc

we're gonna need an mbean for CamelContext so we can do things like add/remove endpoint and ultimately one day add/remove routes etc

jstrachan: yeah, i think there's still an open jira about that

fancy taking a stab at it? :)

yeah, i think i played with it ages ago and put it off :)

what good adding an endpoint if one cannot add a route?

e.g. if I wanna send to a queue Foo

from a management console

great endpoint "activemq:Foo"

then click the send operation on the endpoint mbean

(which we need too...)

ah, so an implicit route from the console endpoint to the created enpoint

where I got stuck last time, was the syntax in an exchange for creating routes :)

adding an endpoint is easy - it just takes a string - calls camelContext.getSingletonEndpoint(uri)

yeah, the route was the issue

adding routes over JMX is gonna have to take an XML string really to avoid JMX serialization hell

for the endpoint it's just a url, that's a string, easy

returning the available routes as XML would be handy too

yeah

exactly, so if the route is a string, could be xml (ugly like hell), scala (not quite funny for many users)

my preference would be a standalone integration DSL that would sorta formalize the patterns in the eip book

i am still struggling with that

have a few methods taking different things...

addRoutefromXml(String); addRouteFromScala(....) etc

for Scala we'd probably add the add method on the Scala component or something

addRouteFrom(Language, String)

sounds cool with me

btw I did up Eclipse templates for some of the Camel EIPs. Let me know what you think. http://janstey.blogspot.com/2008/08/eclipse-templates-for-apache-camel.html

yay