gnodet:ping

Hello once again

hi

It looks like that the servicemix-camel-service-unit will produce a regular su instead of a camel one. Thus not connecting with the tutorial

of course...it IS a smx su

well it is supposed to generate and example xml, and at the moment it is not ;)

also i was expecting the camel dependency in the pom file

unless this is intended behavior

how did u created the su

just had a look at the archetype and the dependency to servicemix-camel is there....of course you need to put the real camel dependencies in for yourself

with the maven archetype, just a sec i will get it from the buffer

C:\workspace\servicemix_camel_tutorial\tutorial-camel-su>mvn archetype:create -DarchtypeArtifactId=servicemix-camel-service-unit -DarchtypeGroupId=eu.u

ds.servicemix.tutorial.camel -DartifactId=tutorial-camel-su

remember the huge amount of camel components....we can't put them all in there because you need only one or two of them

at least I would think so

That is good, but then the tutorial 3 needs to be updated i think

which deps are missing?

cvdstap: your archetype command is wrong

gertv: maybe u can have a look here. Seems there are some deps missing in your tutorial

the archetypeGroupId should be org.apache.servicemix.tooling

and the parameter should be archetypeSomething, not archtypeSomething

fully correct, i think i will go for that coffee ~_~

coffee helps solve every it problem

and good to know that typos there will not produce an error

lhein already drinks coffee

cvdstap: if you had specified the parameter names correct, you would have gotten an error

because it can't find the archetype in that group id

but now that the parameter names themselves were off too, the archetype plugin doesn't find the parameter and just uses its own defaults

gertv just got himself a coffee too

I'm working at a coffee roasting company today -- so I'm right at the source of it

wow...thats something, gert

hehe

hmm do the tooling archetypes pick the group id from the parent pom ?

yep, I think so

ah that is why i got confused i think *tests*

i do have to use the -DarchetypeVersion=3.2.2 trick again tho, i should realy figure out where that comes from

lhein: you had a problem building 3.3 yesterday with my changes?

that is now fixed gert...needed to adapt some version numbers

ok

ping ffang

Even though i did run in some issues... my brain keeps telling me, this can not be this simple

rong:pang

ffang: I just opened SM-1526 which is a major problem for us. Any ideas off the top of your head re: what might be the problem?

cvdstap: what's too simple for you?

rong: looks like the JdbcAuditor want to serialize some class from cxf codebase

gertv, it is realy little effort to get the SU's SA's set up and deployed, considering what they do

cvdstap: yeah, it is, and we are working on making it even easier with smx 4

ffang: Am I correct that the cxf code is not prepared for such an operation?

rong: require JBIDestination is serialable doesn't make sense to me, I will figure out can we add some modifier to the variable JBIDestination inside smx such as "transient" to avoid this happen

ffang: if that doesn't work, would implementing a custom JBIDestinationOutputStream.writeObject() be another alternative?

rong: mark JBIDestiantion as seriable and add dummy writeObject() would be a work around but doesn't make sense

ffang: also I suspect SM-1436 is the same problem. It probably looks a bit different due to different smx/cxf versions.

rong: IIRC, there would be some normal way to exclude object variable which not implment Seriable in a seriable object

rong: yes, it should be

rong: should be get addressed in same way

ffang: we should probably keep in mind that we also use serialization for the JMS flow

ffang: so if you need the JBIDestination at the other end there, we probably need to implement Externalizable to read/write it to bytes somewhere

ffang: otherwise, we just make it transient

gertv: how about make it transient?

ffang: if you make it transient, the JBIDestination of whatever you made transient will be null if you deserialize it

ffang: so if you need it again, you need to be able to recreate it

ffang: for the JdbcAuditor, that probably doesn't matter though

gertv: so far I don't think we need serialize the JBIDestination and deserialize at the other end, so mark it transient is fine

ffang: yep

ffang: pong

gnodet: does osgi support two different bundles export same package name?

not very well

well, it does in a few cases:

gnodet: so I guess https://issues.apache.org/activemq/browse/SMX4-88 comes from this package name conflict

ffang: yes, i think this is the reason

gnodet: so we need repackage the code in features/camel/servicemix-camel, how about org.apache.servicemix.camel.component?

gnodet: in which case osgi support same package name from different bundles?

ffang: two cases: if the two bundles really export the *same* pacakge (two copies of the same classes)

in such a case, one copy will be chosen

(you can also export the same package in two different versions)

gnodet: thanks, and what do you think we need do for features versioning?

but if you want the two packages to be merged, this is possible but it requires the use of some OSGi meta-data which is not supported by felix

and one bundle is attached to the other one, becoming a part of this bundle

but it's better to avoid that

gnodet: ok, I will repackage the one in features project

this component is very close to the jbi one, so i'm not sure we want to keep a dupicate copy of nearly the same code

the only difference with the jbi component is that it uses directly the nmr instead

and now that the jbi components are packaged as osgi bundles, this is becoming less interesting, as you can now use a plain configuration file to define your camel routes and jbi endpoints

gnodet: but since we still have serveral tests and samples based on this components, I think keep it is ok

the problem is that it's much more limited than the jbi camel component

for example the mep can not be really configured when going from camel -> nmr

it takes the mep from the camel exchange, which is always InOnly iirc

and i don't think it propagates the properties / attachments

so we need to either: work on it to duplicate all that was done on the camel jbi component, or update the examples to use the jbi component

gertv: any opinion on that ?

Another question from a beginner: is the "urn:" part of the namespace used for the services mandatory or even better what does is mean ?

gnodet: the MEP is not always InOnly, and it can support attachment, we have a test org/apache/servicemix/camel/AttachmentTest.java

gnodet: about the MEP, the camel exchange should set MEP correctly before pass to nmr

ok, so forget what i said

let's rename its package

what about org.apache.servicemix.camel.nmr ?

it may be more explicit than "component"

gnodet: it's fine, :-)

ffang: btw, when you're at it, i've just seen a dependency on the cxf component

the ServiceMixProducer imports org.apache.camel.component.cxf.CxfConstants

so it creates a requirement on the osgi side, which is not necessary imho

gnodet, ffang: why would we want to keep the both of them around?

to avoid having to go through the JBI layer for a camel route on smx4?

ffang: so jbiDestination would get marked transient in org.apache.cxf.transport.jbi.JBIDestination.BackChannelConduit?

cvdstap: the urn: is just convention -- a replacement for the http://... commonly found in URIs

gnodet: I will fix the reference for CxfConstants

gertv, i see

ffant: well, it does not end up in the manifest it seems as it's jut a constant, but it would be cleaner

thanks

cvdstap: we use the urn: in our tutorials to avoid confusing people with http:// uri

gertv, also it makes it more distinct from other namespaces, which is a good thing

rong: not sure where the jbiDestinataion get passed into smx NormalizedMessage, need find it out

gnodet: about features versioning, do you think we should support to install different versions of feature?

ffang: yes, we should work on that i think or at least think about it

gnodet: what else do you think we should support for features versioning?

gnodet: for backword compability, I think we should give each feature a default version if it doesn't specify one in the features.xml

ffang: yes, osgi does that too, so using 0.0.0 sounds like a good default

gnodet: sounds good to me as well :-)

gertv, i think http://servicemix.apache.org/34-exchanging-messages-with-other-jbi-services.html section Receive a message from the JBI ESB bullet 1 could use a picture... it is realy hard to understand what happens with the text alone

ffang: i think org.apache.cxf.transport.jbi.JBIDestination.BackChannelConduit.prepare() updates message with JBIDestinationOutputStream

rong: yes, that's how response message send out

ffang: so do you think it is likely that the jbiDestination member variable in JBIDestination.BackChannelConduit is the serialization/externalizable offender?

cvdstap: do you feel up to creating one?

cvdstap: I'm not much of a graphics artist myself -- but I'll happily add it to the site for you

i could make an atempt, but i dont have any of the other graphics that are already used (and i do not understand what it says exactly ;))

rong: shouldn't be, since BackChannelConduit itself is not marked as Seriable,

cvdstap: what part of it is hard to grasp?

ffang: MessageExchangeImpl is not serializable but externalizable which I believe is a less strict requirement

the part where it says "Because this matches the the external JMS consumer endpoint we created on the previous page, this route will receive the messages from this external endpoint."

I get that the from("jbi:endpoint:...") publishes a service to the nmr

but why that provider gets connected to the jms one i dont get.

both SM-1526 and SM-1436 the exception comes from serialize the org.apache.servicemix.jbi.messaging.NormalizedMessageImpl, so looks like somehow JBIDestination get passed into org.apache.servicemix.jbi.messaging.NormalizedMessageImpl

rong: maybe passed in as a property, but not sure now

cvdstap: the from("jbi:endpoint:...") publishes an endpoint on the nmr

that's an internal endpoint (available on the esb itself)

the jms:consumer is an external endpoint -- it's available from the outside world

the only thing it says there is that because the names of the services are the same, the message arriving at the queue will be sent to the internal endpoint by the jms:consumer

ffang: I noticed that getDestination() is method on cxf Message interface and I suspect smx messageExchange contains reference to cxf message.

so the Camel endpoint exposed on the nmr matches the name of the target service configured on the jms:consumer

ffang: got to run...thx for the help.

i think i am mixing up some things at the moment. In jbi the consumer is the initiator... of an excahnge. So now i guess that when the queue recieves an item on the provider, the consumer will create an exchange to the nmr and since the camel endpoint is the same name the nmr routes it from the jms consumer to the camel endpoint

yeah, that's about right

when the jms:provider receives a JBI MessageExchange, it sends a JMS message to the queue

and when the jms:consumer notices the JMS message on the queue, it will create the MessageExchange and the NMR does the routing just as you described

so in short "when a consumer endpoint matches an producer enpoint the exchange will get routed between them" ?

also what happaned to tutorial 4-5-6 ?

tutorial 4 is currently in progress (it's about cxf)

the 7 is just called 7 because we wanted to move it up the road

perhaps we had better called it 'intermediate 1' or something

fair enough

i think its best to let the information sink in a little, thanks for the help and explanation!

np

gaginn: just replied to your mail

could you quickly check if that makes sense to you before I'm off to dinner?

i.e. to lunch ;)

gertv: i think yes. I'm going to do it according to your suggestions ;)

just a random thought.. It seems to me (not tested) that within one su i could use for instance both a jms and a file component. Any reason why not to? since all te examples are having multiple service definitions within a single su of each component type.

cvdstap: no, you can not do that at the moment

cvdstap: one SU contains the configuration for a single JBI component

As by jbi spec ?

cvdstap: that's one of the thing we will have in SMX4, where you can deploy an OSGi bundle with config for mulitple components

yes, that's JBI packaging

for smx4, you can still use that if you want, but you'll also be able to deploy a plain XML file or an OSGi bundle containing multiple component's config

I read about OSGi, it seems like a very interesting technologie for this purpose

yep, definitely

that is nice, since i think it will make things easier to find, since one "route" can be in one file. At the moment it is spread all over