Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0-M1
-
None
Description
(10:27:54) milerfang: Hi Dan
(10:28:17) kulp: hey
(10:28:59) milerfang: I see you change the pom in integration/jbi to remove the servicemix jar from distribution
(10:29:19) kulp: Right.
(10:29:24) milerfang: in fact, this jar only contain JBI api and no servicemix work in it
(10:29:57) milerfang: we need this jar in our distribution for JBI work
(10:30:33) kulp: Why? Wouldn't whatever JBI provider the user uses provide it?
(10:34:55) milerfang: the JBITransport init need this jar , and when bus init, the bus would try to load any transport from spring bean config file
(10:35:18) milerfang: like jms api jar is also included in the kit
(10:36:47) kulp: In that case, I think the cxf-integration-jbi shouldn't be on the classpath at all for the "normal" cases. Just for the JBI integration cases.
(10:38:44) milerfang: it's only a api jar, just like jms api or any other api, since we provide JBI transport, why it's not a normal case 
(10:40:36) milerfang: currently, all demo would fail since init bus failed, would you mind I just add jbi api jar back in the kit?
(10:41:29) kulp: I'd prefer if cxf-integration-jbi is removed from the manifest jar if it shouldn't be there.
(10:43:06) milerfang: you mean we shouldn't ship cxf-integration-jbi with our kit?
(10:43:19) kulp: Ship it, but not on the default classpath.
(10:43:32) kulp: It's only applicable if running in a JBI container, right?
(10:43:44) milerfang: so by this way bus will not try to load jbi transport?
(10:44:00) milerfang: yes, only running in a JBI container
(10:44:39) kulp: Right. Then it doesn't need to be on the classpath for all the demos and for "normal" use of CXF.
(10:44:50) kulp: Thus, ship it, but not part of the manifest jar.
(10:44:57) kulp: (JCA should probably be similar)
(10:45:21) milerfang: ok, I think you are right