if Camel is started from commandline with no spring dependencies then it will try to enable JMX and we need som spring jars for this - should we then catch this situation and fallback to non JMX mode?

Caused by: java.lang.NoClassDefFoundError: org/springframework/jmx/export/metadata/JmxAttributeSource

yeah - I'd have hoped we could have made the spring dependency optional to be honest

I guess if no spring jar is present we could just avoid enabling jmx?

yep i think so to, I will add one of your are you missing XXX jar inspired log messages ;)

yay :)

Could not find needed classes for JMX lifecycle strategy. Are you missing spring-context.jar by any chance? NoClassDefFoundError: org/springframework/jmx/export/metadata/JmxAttributeSource

Not possible to use JMX lifecycle strategy. Using DefaultLifecycleStrategy instead.

sounds great :)

committed to trunk

yay

i am working on my tutorial that introduces camel piece by piece so now i was turning my webservice application to use camel for storing the content as files etc. but my unit test failed as i only uses camel-core.jar

yeah; its kinda so easy with maven to accidentally add hard-dependencies rather than optional dependencies

I guess we need more test cases that just use camel-core and no spring

yep, todays modern framework just grap a insane load of jars. cxf + camel-core has 44 jars in my very simple demo app

yeah!

cxf has crazy numbers of dependencies :)

when its transparent people probably get careless

yeah

we need better tooling to trim pom dependencies etc

its easy for a dependency to pull in tons of stuff

e.g. commons-logging can bring in log4j + commons-logging + avalon + other stuff!

yep sure does. and its kinda hard to know all the scopes and what they are used for

maven isn't documented very well

yeah

and then the fear is that if its to be deployed on IBM websphere on IBM JDK then some strange shit can hit the fan - and with XX to many jars. Damm!

:(

just to convince operations that wsdl4j-1.6.1.jar should be put in jre/endorsed/lib will take it toes. operations is outsourced so they are pretty strickt!

yep not everyone can avoid the beast and jump on the osgi wagon

yeah!

i was wondering in the new flatpack code: DataSetList. 1) in the size method why you can't use return dataSet.getRowCount(); instead?

DOH!

2) and the get: dataSet.absolute(index); return FlatpackConverter.toMap(dataSet);

didn't see that!

oh I missed hte absolute(index) too!

oh thanks!

DataSetList is a bit sucky :)

yep i was looking into charles problem with his header/trails.

you can get the data in net.sf.DataSet and there is a method. IsHeaderId or something where you can test if its the header/trails by its id

yeah - btw its unfortunate the implementation of Splitter (which uses Multicast) that it iterates first, builds up a list, then processes them

so I kinda had to make a List of Maps rather than pass around the DataSet

which is a shame

but hopefully we could have a proxy object maybe that refers to 'row X in dataset' that lets you access the dataset if you need it etc

ah cool

ah great idea

you want to fullblown DSL with the splitter() - that is pretty neat but probably not the first though for camel medium/new users ;)

I noticed that the createIterator() we use in different places (e.g. Splitter()) should really use the Type Conversions - then we can have a DataSet -> Iterator converter method etc

well we have plenty time to create a good solution in 1.5

yeah :)

Ah your precious type converter it can do marvelous stuff!

:)

yeah!

one of my favourite bits of camel :)

btw when talking about type convert, we need it to be smarter so it can access somekind of exchange context = for instance a encoding configuration for byte encoding - we have a jira ticket for it.

also I guess your tracer need somehow to know who was the "from" node

yeah

for the type converter stuff, I was wondering if the 2nd method parameter could be the Exchange/Message

CAMEL-115 : I was hopeing one of you smart people would pave the road and the rest of us could finish it ;)

:)

Wouldn't we need some <property> tag for global /route specific properties, that the exchange / type converters / etc. can reach

then you can have local encoding settings etc. kinda like your errorHandlerRef

but for properties

yeah - I wonder if for type converters we might wanna set the local type converter for some routes; where you can customize or register some converters

so we'd have a global type converter but we could customize some converters/translators in specific routes/contexts

there's nothing to stop us having a bean which is-a transformer that uses a type converter registry that lets folks register custom tranformers or something

<convertBodyTo type="Document" registryRef="someCustomRegistry"/> etc

ah pretty sweet

btw the 2nd parameter as Exchange is a good idea, or if it can bind the parameter to the type Exchange then it will do it

there's normally a default type converter thingy on the camelcontext but it'd be easy to provide custom ones where required

yeah

CAMEL-84 is also a little issue that is a troll

something with return null is "handled special" when a type convert is to be found - cant rember exactly. but the end-users doens't get a good decent exception message that a sutiable type converter could not be found

yeah

okay when hadrian come along, we are ready to build a new RC

great!

jstrachan, davsclaus: I still have some outstanding refactorings to camel-scala -- was waiting to commit them until after the RC

but since the new one isn't built yet, shouldn't I just go ahead and put them in as well?

go for it I'd say!

you are the scala expert, and its marke for work in progress.

so +1 just as it compiles and the unit tests passes ;)

its a bit to soon for saying that scala is feature complete and end-users should use it for production .. or whats your point gertv?

and we don't want to postpone the release because of a new RC

no, definitely not -- it was just waiting because it wasn't building/testing ok before the previous rc

just finishing it now though

no worries - hadrian said he will cut the RC today

hadrian started the rc5 build

jstrachan cheers

hadrian: yay! lets's hope this will be the one...

who gives a -1 builds the next kit :)

;)

great hadrian has created the RC5

he he if you stop the camel context from the jmx console and the app was started with mvn camel:run => camel.spring Main then it will wait forever ;)

waiting at: at org.apache.camel.spring.Main.waitUntilCompleted(Main.java:499)

well just trying the RC5 ;)