|
Hello.
It seems that dependencies for a blueprint file depend on the way it is deployed. In a first step, I directly copy the blueprint XML file to the deploy folder, and it works as expected. In a second step, I package the same file into a bundle using the felix maven plugin, and deploy the generated JAR into the deploy folder. In this case, an error is produced during the deployment : java.lang.NoClassDefFoundError: groovy/lang/Script I've not tested other cases, but I suppose that it may do the same error for other Camel component like it does with groovy in my example. When I look at the first bundle description in the web console, I can see a list of all the actual dependent modules in the imported packages : groovy.lang,version=1.8.5 from groovy-all (219) groovyjarjarantlr,version=1.8.5 from groovy-all (219) org.apache.activemq,version=5.5.1 from org.apache.activemq.activemq-core (50) org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) org.apache.camel.blueprint,version=2.8.5 from org.apache.camel.camel-blueprint (152) org.apache.camel.impl,version=2.8.5 from org.apache.camel.camel-core (91) org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core (91) org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all (219) org.osgi.service.blueprint.container,version=1.0.1 from org.apache.aries.blueprint (10) In the second case, the maven plugin only sets the "org.osgi.service.blueprint" in the imported packages list in the manifest. Indeed, It seems that all the OSGi part of my blueprint is taken into account, but nothing from the camel context... Nothing seems to be done at deployment time to add the camel components dependences... Where is the error ? Should I do something different to build the JAR with the maven plugin ? Thanks for you help. camel-context.xml pom.xml |
|
The maven-bundle-plugin won't detect what Camel components you are using
and make sure those are installed. To do this you will need to use a feature for your application http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.htmlYou can create one something like this: <feature name="myapp" version="${project.version}"> <feature>camel-core</feature> <feature>camel-blueprint</feature> <feature>camel-activemq</feature> ... <bundle>mvn:myapp/myapp/${project.version}</bundle> </feature> Now, when you install "myapp" feature, all the Camel components you need will be installed as well. If you want to enforce the various package imports are there at the OSGi bundle level, you can always add them in manually with the <Import-Package> instruction. Cheers, Jon On Fri, Jul 27, 2012 at 1:41 PM, Ephemeris Lappis < [hidden email]> wrote: > Hello. > > It seems that dependencies for a blueprint file depend on the way it is > deployed. > > In a first step, I directly copy the blueprint XML file to the deploy > folder, and it works as expected. > > In a second step, I package the same file into a bundle using the felix > maven plugin, and deploy the generated JAR into the deploy folder. In this > case, an error is produced during the deployment : > > java.lang.NoClassDefFoundError: groovy/lang/Script > > I've not tested other cases, but I suppose that it may do the same error > for > other Camel component like it does with groovy in my example. > > When I look at the first bundle description in the web console, I can see a > list of all the actual dependent modules in the imported packages : > > groovy.lang,version=1.8.5 from groovy-all (219) > groovyjarjarantlr,version=1.8.5 from groovy-all (219) > org.apache.activemq,version=5.5.1 from org.apache.activemq.activemq-core > (50) > org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) > org.apache.camel.blueprint,version=2.8.5 from > org.apache.camel.camel-blueprint (152) > org.apache.camel.impl,version=2.8.5 from org.apache.camel.camel-core (91) > org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core (91) > org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) > org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all (219) > org.osgi.service.blueprint.container,version=1.0.1 from > org.apache.aries.blueprint (10) > > In the second case, the maven plugin only sets the > "org.osgi.service.blueprint" in the imported packages list in the manifest. > Indeed, It seems that all the OSGi part of my blueprint is taken into > account, but nothing from the camel context... Nothing seems to be done at > deployment time to add the camel components dependences... > > Where is the error ? Should I do something different to build the JAR with > the maven plugin ? > > Thanks for you help. > > http://servicemix.396122.n5.nabble.com/file/n5714018/camel-context.xml > camel-context.xml > http://servicemix.396122.n5.nabble.com/file/n5714018/pom.xml pom.xml > > > > -- > View this message in context: > http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > -- Cheers, Jon --------------- FuseSource Email: [hidden email] Web: fusesource.com Twitter: jon_anstey Blog: http://janstey.blogspot.com Author of Camel in Action: http://manning.com/ibsen |
|
A blueprint file deployed is going to be setup with a
Dynamic-Import: * Which is pretty expensive for the framework, a bundle with blueprint on your classpath is going to need the correct imports and exports. /je On Jul 30, 2012, at 10:35 AM, Jon Anstey wrote: > The maven-bundle-plugin won't detect what Camel components you are using > and make sure those are installed. To do this you will need to use a > feature for your application > http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.htmlYou > can create one something like this: > > <feature name="myapp" version="${project.version}"> > <feature>camel-core</feature> > <feature>camel-blueprint</feature> > <feature>camel-activemq</feature> > ... > <bundle>mvn:myapp/myapp/${project.version}</bundle> > </feature> > > Now, when you install "myapp" feature, all the Camel components you need > will be installed as well. > > If you want to enforce the various package imports are there at the OSGi > bundle level, you can always add them in manually with the <Import-Package> > instruction. > > Cheers, > Jon > > On Fri, Jul 27, 2012 at 1:41 PM, Ephemeris Lappis < > [hidden email]> wrote: > >> Hello. >> >> It seems that dependencies for a blueprint file depend on the way it is >> deployed. >> >> In a first step, I directly copy the blueprint XML file to the deploy >> folder, and it works as expected. >> >> In a second step, I package the same file into a bundle using the felix >> maven plugin, and deploy the generated JAR into the deploy folder. In this >> case, an error is produced during the deployment : >> >> java.lang.NoClassDefFoundError: groovy/lang/Script >> >> I've not tested other cases, but I suppose that it may do the same error >> for >> other Camel component like it does with groovy in my example. >> >> When I look at the first bundle description in the web console, I can see a >> list of all the actual dependent modules in the imported packages : >> >> groovy.lang,version=1.8.5 from groovy-all (219) >> groovyjarjarantlr,version=1.8.5 from groovy-all (219) >> org.apache.activemq,version=5.5.1 from org.apache.activemq.activemq-core >> (50) >> org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) >> org.apache.camel.blueprint,version=2.8.5 from >> org.apache.camel.camel-blueprint (152) >> org.apache.camel.impl,version=2.8.5 from org.apache.camel.camel-core (91) >> org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core (91) >> org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) >> org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all (219) >> org.osgi.service.blueprint.container,version=1.0.1 from >> org.apache.aries.blueprint (10) >> >> In the second case, the maven plugin only sets the >> "org.osgi.service.blueprint" in the imported packages list in the manifest. >> Indeed, It seems that all the OSGi part of my blueprint is taken into >> account, but nothing from the camel context... Nothing seems to be done at >> deployment time to add the camel components dependences... >> >> Where is the error ? Should I do something different to build the JAR with >> the maven plugin ? >> >> Thanks for you help. >> >> http://servicemix.396122.n5.nabble.com/file/n5714018/camel-context.xml >> camel-context.xml >> http://servicemix.396122.n5.nabble.com/file/n5714018/pom.xml pom.xml >> >> >> >> -- >> View this message in context: >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018.html >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> > > > > -- > Cheers, > Jon > --------------- > FuseSource > Email: [hidden email] > Web: fusesource.com > Twitter: jon_anstey > Blog: http://janstey.blogspot.com > Author of Camel in Action: http://manning.com/ibsen |
|
In reply to this post by Jon Anstey
Hello.
Does it mean that anyway I have to be aware of the Camel's dependencies of my blueprint routes when I package them as an OSGi bundle ? I've verified several times that a same blueprint deployed alone works by itself with all the needed features if they are already installed of course. This suggests that the blueprint context is correctly created in this case, and I don't understand why the same file could not be processed when it is included in a bundled JAR. In addition, how can I identify all the packages that simple tags in my blueprint imply, like "<groovy>" in my case ? I've done a test, copying from the web console in the Import-Package section of the descriptor of the bundle for a flat XML once it is deployed, and put it in my Maven Plugin instructions, but dynamic runtime dependencies of groovy were still missing, and other exceptions occurred. In this case the package "org.codehaus.groovy .runtime.typehandling" was loaded lately when needed... I'm sure other groovy packages could be missing... It seems the blueprint containers are not provisioned with identical class loaders depending of the packaging, at least for groovy... Could it be confirmed ? Thanks for your help. Regards. Ephemeris LappisLe 30/07/2012 18:36, Jon Anstey [via ServiceMix] a écrit : The maven-bundle-plugin won't detect what Camel components you are using |
|
In reply to this post by Johan Edstrom-2
Hello.
I don't understand what you mean : should I explicitly put the "Dynamic-Import: *" in my bundle instructions ? Thanks. Ephemeris LappisLe 30/07/2012 18:42, Johan Edstrom-2 [via ServiceMix] a écrit : A blueprint file deployed is going to be setup with a |
|
Yes, you need to manage dependencies in OSGi.
On Jul 30, 2012, at 12:32 PM, Ephemeris Lappis wrote: > Hello. > > I don't understand what you mean : should I explicitly put the > "Dynamic-Import: *" in my bundle instructions ? > Thanks. > > Ephemeris Lappis > > Le 30/07/2012 18:42, Johan Edstrom-2 [via ServiceMix] a écrit : >> A blueprint file deployed is going to be setup with a >> Dynamic-Import: * >> >> Which is pretty expensive for the framework, a bundle with blueprint >> on your >> classpath is going to need the correct imports and exports. >> >> /je >> On Jul 30, 2012, at 10:35 AM, Jon Anstey wrote: >> >>> The maven-bundle-plugin won't detect what Camel components you are >> using >>> and make sure those are installed. To do this you will need to use a >>> feature for your application >>> >> http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.htmlYou >>> can create one something like this: >>> >>> <feature name="myapp" version="${project.version}"> >>> <feature>camel-core</feature> >>> <feature>camel-blueprint</feature> >>> <feature>camel-activemq</feature> >>> ... >>> <bundle>mvn:myapp/myapp/${project.version}</bundle> >>> </feature> >>> >>> Now, when you install "myapp" feature, all the Camel components you >> need >>> will be installed as well. >>> >>> If you want to enforce the various package imports are there at the >> OSGi >>> bundle level, you can always add them in manually with the >> <Import-Package> >>> instruction. >>> >>> Cheers, >>> Jon >>> >>> On Fri, Jul 27, 2012 at 1:41 PM, Ephemeris Lappis < >>> [hidden email] </user/SendEmail.jtp?type=node&node=5714023&i=0>> wrote: >>> >>>> Hello. >>>> >>>> It seems that dependencies for a blueprint file depend on the way >> it is >>>> deployed. >>>> >>>> In a first step, I directly copy the blueprint XML file to the deploy >>>> folder, and it works as expected. >>>> >>>> In a second step, I package the same file into a bundle using the >> felix >>>> maven plugin, and deploy the generated JAR into the deploy folder. >> In this >>>> case, an error is produced during the deployment : >>>> >>>> java.lang.NoClassDefFoundError: groovy/lang/Script >>>> >>>> I've not tested other cases, but I suppose that it may do the same >> error >>>> for >>>> other Camel component like it does with groovy in my example. >>>> >>>> When I look at the first bundle description in the web console, I >> can see a >>>> list of all the actual dependent modules in the imported packages : >>>> >>>> groovy.lang,version=1.8.5 from groovy-all (219) >>>> groovyjarjarantlr,version=1.8.5 from groovy-all (219) >>>> org.apache.activemq,version=5.5.1 from >> org.apache.activemq.activemq-core >>>> (50) >>>> org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) >>>> org.apache.camel.blueprint,version=2.8.5 from >>>> org.apache.camel.camel-blueprint (152) >>>> org.apache.camel.impl,version=2.8.5 from >> org.apache.camel.camel-core (91) >>>> org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core >> (91) >>>> org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) >>>> org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all >> (219) >>>> org.osgi.service.blueprint.container,version=1.0.1 from >>>> org.apache.aries.blueprint (10) >>>> >>>> In the second case, the maven plugin only sets the >>>> "org.osgi.service.blueprint" in the imported packages list in the >> manifest. >>>> Indeed, It seems that all the OSGi part of my blueprint is taken into >>>> account, but nothing from the camel context... Nothing seems to be >> done at >>>> deployment time to add the camel components dependences... >>>> >>>> Where is the error ? Should I do something different to build the >> JAR with >>>> the maven plugin ? >>>> >>>> Thanks for you help. >>>> >>>> http://servicemix.396122.n5.nabble.com/file/n5714018/camel-context.xml >>>> camel-context.xml >>>> http://servicemix.396122.n5.nabble.com/file/n5714018/pom.xml pom.xml >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018.html >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Jon >>> --------------- >>> FuseSource >>> Email: [hidden email] </user/SendEmail.jtp?type=node&node=5714023&i=1> >>> Web: fusesource.com >>> Twitter: jon_anstey >>> Blog: http://janstey.blogspot.com >>> Author of Camel in Action: http://manning.com/ibsen >> >> >> >> ------------------------------------------------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714023.html >> >> To unsubscribe from Camel classpath using blueprint inside an OSGi >> bundle, click here >> < >> NAML >> <http://servicemix.396122.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > > > > > -- > View this message in context: http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714025.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. |
|
Hello.
Indeed, it works better with a new bundle instruction : <DynamicImport-Package>*</DynamicImport-Package> This way, both the flat XML and bundled blueprints work the same. Thanks for your help. Regards |
|
In reply to this post by Ephemeris Lappis
Hi,
When you drop a blueprint camel router file in $SMX_HOME/deploy folder, actually a karaf blueprint deployer will kick in and transform the blueprint file into a bundle underlying, and as Johan already pointed out, karat blueprint deployer will add "Dynamic-Import: *" for the bundle generated from blueprint file, it works but using Dynamic-Import isn't good practice in OSGi world. When use maven-bundle-plugin to build camel router bundle yourself, it will scan the blueprint configuration file, but only those packages used explicitly in bean declaration would be taken into account(added into Import-Package), the tags like <groovy> won't, as maven-bundle-plugin can't connect tag with the necessary underlying camel packages, you need manage it yourself in maven-bundle-plugin configuration. Freeman ------------- Freeman Fang FuseSource Email:[hidden email] Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-7-31, at 上午2:32, Ephemeris Lappis wrote: > Hello. > > I don't understand what you mean : should I explicitly put the > "Dynamic-Import: *" in my bundle instructions ? > Thanks. > > Ephemeris Lappis > > Le 30/07/2012 18:42, Johan Edstrom-2 [via ServiceMix] a écrit : >> A blueprint file deployed is going to be setup with a >> Dynamic-Import: * >> >> Which is pretty expensive for the framework, a bundle with blueprint >> on your >> classpath is going to need the correct imports and exports. >> >> /je >> On Jul 30, 2012, at 10:35 AM, Jon Anstey wrote: >> >>> The maven-bundle-plugin won't detect what Camel components you are >> using >>> and make sure those are installed. To do this you will need to use a >>> feature for your application >>> >> http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.htmlYou >>> can create one something like this: >>> >>> <feature name="myapp" version="${project.version}"> >>> <feature>camel-core</feature> >>> <feature>camel-blueprint</feature> >>> <feature>camel-activemq</feature> >>> ... >>> <bundle>mvn:myapp/myapp/${project.version}</bundle> >>> </feature> >>> >>> Now, when you install "myapp" feature, all the Camel components you >> need >>> will be installed as well. >>> >>> If you want to enforce the various package imports are there at the >> OSGi >>> bundle level, you can always add them in manually with the >> <Import-Package> >>> instruction. >>> >>> Cheers, >>> Jon >>> >>> On Fri, Jul 27, 2012 at 1:41 PM, Ephemeris Lappis < >>> [hidden email] </user/SendEmail.jtp?type=node&node=5714023&i=0>> wrote: >>> >>>> Hello. >>>> >>>> It seems that dependencies for a blueprint file depend on the way >> it is >>>> deployed. >>>> >>>> In a first step, I directly copy the blueprint XML file to the deploy >>>> folder, and it works as expected. >>>> >>>> In a second step, I package the same file into a bundle using the >> felix >>>> maven plugin, and deploy the generated JAR into the deploy folder. >> In this >>>> case, an error is produced during the deployment : >>>> >>>> java.lang.NoClassDefFoundError: groovy/lang/Script >>>> >>>> I've not tested other cases, but I suppose that it may do the same >> error >>>> for >>>> other Camel component like it does with groovy in my example. >>>> >>>> When I look at the first bundle description in the web console, I >> can see a >>>> list of all the actual dependent modules in the imported packages : >>>> >>>> groovy.lang,version=1.8.5 from groovy-all (219) >>>> groovyjarjarantlr,version=1.8.5 from groovy-all (219) >>>> org.apache.activemq,version=5.5.1 from >> org.apache.activemq.activemq-core >>>> (50) >>>> org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) >>>> org.apache.camel.blueprint,version=2.8.5 from >>>> org.apache.camel.camel-blueprint (152) >>>> org.apache.camel.impl,version=2.8.5 from >> org.apache.camel.camel-core (91) >>>> org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core >> (91) >>>> org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) >>>> org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all >> (219) >>>> org.osgi.service.blueprint.container,version=1.0.1 from >>>> org.apache.aries.blueprint (10) >>>> >>>> In the second case, the maven plugin only sets the >>>> "org.osgi.service.blueprint" in the imported packages list in the >> manifest. >>>> Indeed, It seems that all the OSGi part of my blueprint is taken into >>>> account, but nothing from the camel context... Nothing seems to be >> done at >>>> deployment time to add the camel components dependences... >>>> >>>> Where is the error ? Should I do something different to build the >> JAR with >>>> the maven plugin ? >>>> >>>> Thanks for you help. >>>> >>>> http://servicemix.396122.n5.nabble.com/file/n5714018/camel-context.xml >>>> camel-context.xml >>>> http://servicemix.396122.n5.nabble.com/file/n5714018/pom.xml pom.xml >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018.html >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Jon >>> --------------- >>> FuseSource >>> Email: [hidden email] </user/SendEmail.jtp?type=node&node=5714023&i=1> >>> Web: fusesource.com >>> Twitter: jon_anstey >>> Blog: http://janstey.blogspot.com >>> Author of Camel in Action: http://manning.com/ibsen >> >> >> >> ------------------------------------------------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714023.html >> >> To unsubscribe from Camel classpath using blueprint inside an OSGi >> bundle, click here >> < >> NAML >> <http://servicemix.396122.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > > > > > -- > View this message in context: http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714025.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. |
|
Hello.
I've had many warnings about Dynamic-Import, and I suppose that's for good reasons. I understand how and why the maven plugin doesn't analyze the Camel's routes and their components such as Groovy to build the bundle's dependencies. But how can I guess the packages that Groovy will need at runtime in Camel/ServiceMix/Karaf, and give a hand-made Import-Package for my bundle ? As I've explained before, I've done a test copying the packages that were detected at deployment time using a plain XML blueprint, but some packages are only imported when needed, and errors occur late... Any idea ? Have you experienced dependency management problem for other components ? Thanks again. Ephemeris LappisLe 06/08/2012 07:07, Freeman-2 [via ServiceMix] a écrit : Hi, |
|
Hi,
during Development it's OK to use Dynamic-Import for testing. But to make sure it's only during your research I suggest using the karaf commands to add it to your running bundle like dev:dynamic-import BundleID this will add the imports and with a package:imports BundleId you'll actually see the required packages to import. Just grab those and add them to the Manifest. regards, Achim 2012/8/6 Ephemeris Lappis <[hidden email]>: > Hello. > > I've had many warnings about Dynamic-Import, and I suppose that's for > good reasons. > > I understand how and why the maven plugin doesn't analyze the Camel's > routes and their components such as Groovy to build the bundle's > dependencies. > > But how can I guess the packages that Groovy will need at runtime in > Camel/ServiceMix/Karaf, and give a hand-made Import-Package for my > bundle ? As I've explained before, I've done a test copying the packages > that were detected at deployment time using a plain XML blueprint, but > some packages are only imported when needed, and errors occur late... > > Any idea ? Have you experienced dependency management problem for other > components ? > > Thanks again. > > Ephemeris Lappis > > Le 06/08/2012 07:07, Freeman-2 [via ServiceMix] a écrit : >> Hi, >> >> When you drop a blueprint camel router file in $SMX_HOME/deploy >> folder, actually a karaf blueprint deployer will kick in and transform >> the blueprint file into a bundle underlying, and as Johan already >> pointed out, karat blueprint deployer will add "Dynamic-Import: *" for >> the bundle generated from blueprint file, it works but using >> Dynamic-Import isn't good practice in OSGi world. >> >> When use maven-bundle-plugin to build camel router bundle yourself, it >> will scan the blueprint configuration file, but only those packages >> used explicitly in bean declaration would be taken into account(added >> into Import-Package), the tags like <groovy> won't, as >> maven-bundle-plugin can't connect tag with the necessary underlying >> camel packages, you need manage it yourself in maven-bundle-plugin >> configuration. >> >> Freeman >> ------------- >> Freeman Fang >> >> FuseSource >> Email:[hidden email] </user/SendEmail.jtp?type=node&node=5714083&i=0> >> Web: fusesource.com >> Twitter: freemanfang >> Blog: http://freemanfang.blogspot.com >> http://blog.sina.com.cn/u/1473905042 >> weibo: http://weibo.com/u/1473905042 >> >> On 2012-7-31, at 上午2:32, Ephemeris Lappis wrote: >> >> > Hello. >> > >> > I don't understand what you mean : should I explicitly put the >> > "Dynamic-Import: *" in my bundle instructions ? >> > Thanks. >> > >> > Ephemeris Lappis >> > >> > Le 30/07/2012 18:42, Johan Edstrom-2 [via ServiceMix] a écrit : >> >> A blueprint file deployed is going to be setup with a >> >> Dynamic-Import: * >> >> >> >> Which is pretty expensive for the framework, a bundle with blueprint >> >> on your >> >> classpath is going to need the correct imports and exports. >> >> >> >> /je >> >> On Jul 30, 2012, at 10:35 AM, Jon Anstey wrote: >> >> >> >>> The maven-bundle-plugin won't detect what Camel components you are >> >> using >> >>> and make sure those are installed. To do this you will need to use a >> >>> feature for your application >> >>> >> >> >> http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.htmlYou >> >>> can create one something like this: >> >>> >> >>> <feature name="myapp" version="${project.version}"> >> >>> <feature>camel-core</feature> >> >>> <feature>camel-blueprint</feature> >> >>> <feature>camel-activemq</feature> >> >>> ... >> >>> <bundle>mvn:myapp/myapp/${project.version}</bundle> >> >>> </feature> >> >>> >> >>> Now, when you install "myapp" feature, all the Camel components you >> >> need >> >>> will be installed as well. >> >>> >> >>> If you want to enforce the various package imports are there at the >> >> OSGi >> >>> bundle level, you can always add them in manually with the >> >> <Import-Package> >> >>> instruction. >> >>> >> >>> Cheers, >> >>> Jon >> >>> >> >>> On Fri, Jul 27, 2012 at 1:41 PM, Ephemeris Lappis < >> >>> [hidden email] </user/SendEmail.jtp?type=node&node=5714023&i=0>> >> wrote: >> >>> >> >>>> Hello. >> >>>> >> >>>> It seems that dependencies for a blueprint file depend on the way >> >> it is >> >>>> deployed. >> >>>> >> >>>> In a first step, I directly copy the blueprint XML file to the >> deploy >> >>>> folder, and it works as expected. >> >>>> >> >>>> In a second step, I package the same file into a bundle using the >> >> felix >> >>>> maven plugin, and deploy the generated JAR into the deploy folder. >> >> In this >> >>>> case, an error is produced during the deployment : >> >>>> >> >>>> java.lang.NoClassDefFoundError: groovy/lang/Script >> >>>> >> >>>> I've not tested other cases, but I suppose that it may do the same >> >> error >> >>>> for >> >>>> other Camel component like it does with groovy in my example. >> >>>> >> >>>> When I look at the first bundle description in the web console, I >> >> can see a >> >>>> list of all the actual dependent modules in the imported packages : >> >>>> >> >>>> groovy.lang,version=1.8.5 from groovy-all (219) >> >>>> groovyjarjarantlr,version=1.8.5 from groovy-all (219) >> >>>> org.apache.activemq,version=5.5.1 from >> >> org.apache.activemq.activemq-core >> >>>> (50) >> >>>> org.apache.camel,version=2.8.5 from org.apache.camel.camel-core (91) >> >>>> org.apache.camel.blueprint,version=2.8.5 from >> >>>> org.apache.camel.camel-blueprint (152) >> >>>> org.apache.camel.impl,version=2.8.5 from >> >> org.apache.camel.camel-core (91) >> >>>> org.apache.camel.spi,version=2.8.5 from org.apache.camel.camel-core >> >> (91) >> >>>> org.codehaus.groovy.reflection,version=1.8.5 from groovy-all (219) >> >>>> org.codehaus.groovy.runtime.callsite,version=1.8.5 from groovy-all >> >> (219) >> >>>> org.osgi.service.blueprint.container,version=1.0.1 from >> >>>> org.apache.aries.blueprint (10) >> >>>> >> >>>> In the second case, the maven plugin only sets the >> >>>> "org.osgi.service.blueprint" in the imported packages list in the >> >> manifest. >> >>>> Indeed, It seems that all the OSGi part of my blueprint is taken >> into >> >>>> account, but nothing from the camel context... Nothing seems to be >> >> done at >> >>>> deployment time to add the camel components dependences... >> >>>> >> >>>> Where is the error ? Should I do something different to build the >> >> JAR with >> >>>> the maven plugin ? >> >>>> >> >>>> Thanks for you help. >> >>>> >> >>>> >> http://servicemix.396122.n5.nabble.com/file/n5714018/camel-context.xml >> >>>> camel-context.xml >> >>>> http://servicemix.396122.n5.nabble.com/file/n5714018/pom.xml pom.xml >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> View this message in context: >> >>>> >> >> >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018.html >> >>>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Cheers, >> >>> Jon >> >>> --------------- >> >>> FuseSource >> >>> Email: [hidden email] >> </user/SendEmail.jtp?type=node&node=5714023&i=1> >> >>> Web: fusesource.com >> >>> Twitter: jon_anstey >> >>> Blog: http://janstey.blogspot.com >> >>> Author of Camel in Action: http://manning.com/ibsen >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> If you reply to this email, your message will be added to the >> >> discussion below: >> >> >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714023.html >> >> >> >> >> To unsubscribe from Camel classpath using blueprint inside an OSGi >> >> bundle, click here >> >> < >> >> NAML >> >> >> <http://servicemix.396122.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> >> >> >> > >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714025.html >> > Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714083.html >> >> To unsubscribe from Camel classpath using blueprint inside an OSGi >> bundle, click here >> < >> NAML >> <http://servicemix.396122.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > > > > > -- > View this message in context: http://servicemix.396122.n5.nabble.com/Camel-classpath-using-blueprint-inside-an-OSGi-bundle-tp5714018p5714085.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/> |
|
Hello.
This is more or less what I've tried to do. However, I'm not really sure that it is the definitive best way to do it. In my idea, and perhaps I'm wrong, I should be able to make my bundle, both my code and the deployment directives with no special care about the execution environment and its inner components. Back to the Groovy problem, I can effectively set my Import-Package using the results of a first dynamic resolution. This will work for the current version of Groovy/Camel/Service-Mix/Karaf I am using, but what will occur when I upgrade my target platform ? Some of my dependencies will stay identical, while other will change according the new Camel or Groovy implementation components...
I agree with the idea of giving explicit dependencies in my Import-Package deducted from what I can see myself in my code (java classes or blueprint XML, it doesn't matter) but It seems a bit risky to include transitive dependencies.However, giving only "Groovy" as a direct dependency doesn't work, since all the transitive dependencies are missing at run time, and this makes my bundle fail...
To be more concrete : what are the actual problem when using dynamic imports in these cases ? Thanks again. On Tue, Aug 7, 2012 at 9:27 AM, Achim Nierbeck [via ServiceMix] <[hidden email]> wrote: Hi, |
| Powered by Nabble | Edit this page |
