[
https://issues.apache.org/jira/browse/CAMEL-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752497#comment-15752497
]
Grzegorz Grzybek edited comment on CAMEL-10602 at 12/15/16 8:59 PM:
--------------------------------------------------------------------
See my comments in CAMEL-10476.
I'm guessing (I wasn't here when it was designed) that {{camel:run}} *should*
work after {{mvn clean compile}} - when you have nice {{target/classes}} filled
with compiled java sources and processed resources - just like it was
(probably) designed.
And it may work with spring or CDI, because they're quite independent on what's
contained in MANIFEST.MF.
Blueprint is different (OSGi is different - but it's another topic) because
MANIFEST.MF is crucial - that's how felix-connect (formerly known as PojoSR)
finds _bundles_ - a _bundle_ is just classpath element that contains
MANIFEST.MF.
In camel-archetype-blueprint we use:
{noformat}
<!-- to generate the MANIFEST.MF of the bundle -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.2.0</version>
<extensions>false</extensions>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>prepare-package</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
{noformat}
to generate manifest in ... {{prepare-package}} phase.
So minimal command that succeeds is {{mvn clean prepare-package camel:run}}.
There are two uses of {{CamelBlueprintHelper.createBundleContext()}}:
* a JUnit @Test that extends
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport}}
* a {{mvn camel:run}} invocation ({{org.apache.camel.maven.RunMojo}})
configured with {{<useBlueprint>}} (or when blueprint descriptor is
autodetected)
These two cases call {{CamelBlueprintHelper.createBundleContext()}} with
{{includeTestBundle}} flag:
*
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#includeTestBundle()}}
by default (no Camel test overrides it) returns {{true}}
* {{RunMojo}} calls (blueprint case)
{{org.apache.camel.test.blueprint.Main.main()}} with some arguments - but no
argument changes {{org.apache.camel.test.blueprint.Main#includeSelfAsBundle}}
field which is always {{false}}
So for JUnit test we have {{includeTestBundle==true}} which means Tinybundles
will be used to pack our test classes and add it to mini-registry
(felix-connect)
For {{camel:run}} we have {{includeTestBundle==false}} which means we have to
find a _bundle_ with blueprint descriptor describing our context differently -
{{mvn prepare-package}} is enough.
There are of course quirks - if you do {{mvn clean package}} and then {{mvn
test}} (without {{clean}}) we may end up with *two* _bundles_ having the same
blueprint descriptor. That's another (more annoying actually) incarnation of
{{mvn clean compile camel:run}} problem where we have *no* _bundles_ with
blueprint descriptors.
My view is - current state is ok, as unit tests (that's what
camel-test-blueprint was for) run before packaging - we're testing *any*
blueprint descriptor - possibly one from {{src/main/resources}} (main route)
and maybe some mocks from {{src/test/resources}}.
But with {{camel:run}} we're actually running the main route/context of the
artifact, so we need at least it's MANIFEST.MF.
What do you think?
was (Author: gzres):
See my comments in CAMEL-10476.
I'm guessing (I wasn't here when it was designed) that {{camel:run}} *should*
work after {{mvn clean compile}} - when you have nice {{target/classes}} filled
with compiled java sources and processed resources.
And it may work with spring or CDI, because they're quite independent on what's
contained in MANIFEST.MF.
Blueprint is different (OSGi is different - but it's another topic) because
MANIFEST.MF is crucial - that's how felix-connect (formerly known as PojoSR)
finds _bundles_ - a _bundle_ is just classpath element that contains
MANIFEST.MF.
In camel-archetype-blueprint we use:
{noformat}
<!-- to generate the MANIFEST.MF of the bundle -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.2.0</version>
<extensions>false</extensions>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>prepare-package</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
{noformat}
to generate manifest in ... {{prepare-package}} phase.
So minimal command that succeeds is {{mvn clean prepare-package camel:run}}.
There are two uses of {{CamelBlueprintHelper.createBundleContext()}}:
* a JUnit @Test that extends
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport}}
* a {{mvn camel:run}} invocation ({{org.apache.camel.maven.RunMojo}})
configured with {{<useBlueprint>}} (or when blueprint descriptor is
autodetected)
These two cases call {{CamelBlueprintHelper.createBundleContext()}} with
{{includeTestBundle}} flag:
*
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#includeTestBundle()}}
by default (no Camel test overrides it) returns {{true}}
* {{RunMojo}} calls (blueprint case)
{{org.apache.camel.test.blueprint.Main.main()}} with some arguments - but no
argument changes {{org.apache.camel.test.blueprint.Main#includeSelfAsBundle}}
field which is always {{false}}
So for JUnit test we have {{includeTestBundle==true}} which means Tinybundles
will be used to pack our test classes and add it to mini-registry
(felix-connect)
For {{camel:run}} we have {{includeTestBundle==false}} which means we have to
find a _bundle_ with blueprint descriptor describing our context differently -
{{mvn prepare-package}} is enough.
There are of course quirks - if you do {{mvn clean package}} and then {{mvn
test}} (without {{clean}}) we may end up with *two* _bundles_ having the same
blueprint descriptor. That's another (more annoying actually) incarnation of
{{mvn clean compile camel:run}} problem where we have *no* _bundles_ with
blueprint descriptors.
My view is - current state is ok, as unit tests (that's what
camel-test-blueprint was for) run before packaging - we're testing *any*
blueprint descriptor - possibly one from {{src/main/resources}} (main route)
and maybe some mocks from {{src/test/resources}}.
But with {{camel:run}} we're actually running the main route/context of the
artifact, so we need at least it's MANIFEST.MF.
What do you think?
> camel:run with simple blueprint project failed "waiting for
> BlueprintContainer" although the route is active
> ------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-10602
> URL: https://issues.apache.org/jira/browse/CAMEL-10602
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint, tooling
> Affects Versions: 2.18.0, 2.18.1, 2.19.0
> Reporter: Aurelien Pupier
> Assignee: Grzegorz Grzybek
> Fix For: 2.18.2, 2.19.0
>
>
> Using a simple Content-based Router example leads to this issue.
> With 2.17.3, it is working fine.
> we can notice that the route is up and running before the timeout occurs (I
> dropped a file to the endpoint and it was well executed)
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Fuse CBR Quickstart 1.0.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ camel-blueprint-cbr
> ---
> [INFO] Deleting C:\install\eclipse-neon\eclipse\ws_fusetooling_dev with
> space\cbr218\target
> [INFO]
> [INFO] --- maven-resources-plugin:3.0.1:resources (default-resources) @
> camel-blueprint-cbr ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @
> camel-blueprint-cbr ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-resources-plugin:3.0.1:testResources (default-testResources)
> @ camel-blueprint-cbr ---
> [INFO] Not copying test resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @
> camel-blueprint-cbr ---
> [INFO] Not compiling test sources
> [INFO]
> [INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @
> camel-blueprint-cbr ---
> [INFO] Tests are skipped.
> [INFO]
> [INFO] --- maven-bundle-plugin:3.2.0:bundle (default-bundle) @
> camel-blueprint-cbr ---
> [INFO]
> [INFO] >>> camel-maven-plugin:2.18.1:run (default-cli) > test-compile @
> camel-blueprint-cbr >>>
> [INFO]
> [INFO] --- maven-resources-plugin:3.0.1:resources (default-resources) @
> camel-blueprint-cbr ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @
> camel-blueprint-cbr ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-resources-plugin:3.0.1:testResources (default-testResources)
> @ camel-blueprint-cbr ---
> [INFO] Not copying test resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @
> camel-blueprint-cbr ---
> [INFO] Not compiling test sources
> [INFO]
> [INFO] <<< camel-maven-plugin:2.18.1:run (default-cli) < test-compile @
> camel-blueprint-cbr <<<
> [INFO]
> [INFO] --- camel-maven-plugin:2.18.1:run (default-cli) @ camel-blueprint-cbr
> ---
> [INFO] Using org.apache.camel.test.blueprint.Main to initiate a CamelContext
> [INFO] Starting Camel ...
> [ Thread-2] RawBuilder INFO Copy
> thread finished.
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator starting
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator started
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator starting
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator started
> [ Blueprint Extender: 1] BlueprintContainerImpl INFO Bundle
> cbr218/1.0.0.SNAPSHOT is waiting for namespace handlers
> [http://camel.apache.org/schema/blueprint]
> [ Blueprint Extender: 1] BlueprintCamelContext INFO Apache
> Camel 2.18.1 (CamelContext: cbr-example-context) is starting
> [ Blueprint Extender: 1] ManagedManagementStrategy INFO JMX is
> enabled
> [ Blueprint Extender: 1] DefaultManagementAgent INFO
> ManagementAgent detected JVM system properties:
> {org.apache.camel.jmx.createRmiConnector=true}
> [KTOP-9NT300B:1099/jmxrmi/camel] DefaultManagementAgent INFO JMX
> Connector thread started and listening at:
> service:jmx:rmi:///jndi/rmi://DESKTOP-9NT300B:1099/jmxrmi/camel
> [ Blueprint Extender: 1] DefaultRuntimeEndpointRegistry INFO Runtime
> endpoint registry is in extended mode gathering usage statistics of all
> incoming and outgoing endpoints (cache limit: 1000)
> [ Blueprint Extender: 1] BlueprintCamelContext INFO
> StreamCaching is not in use. If using streams then its recommended to enable
> stream caching. See more details at
> http://camel.apache.org/stream-caching.html
> [ Blueprint Extender: 1] XPathBuilder INFO Created
> default XPathFactory
> com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl@3f24f264
> [ Blueprint Extender: 1] BlueprintCamelContext INFO Route:
> cbr-route started and consuming from: file://work/cbr/input
> [ Blueprint Extender: 1] BlueprintCamelContext INFO Total 1
> routes, of which 1 are started.
> [ Blueprint Extender: 1] BlueprintCamelContext INFO Apache
> Camel 2.18.1 (CamelContext: cbr-example-context) started in 0.535 seconds
> [ead #2 - file://work/cbr/input] cbr-route INFO
> Receiving order ID-DESKTOP-9NT300B-51935-1481791551205-0-1
> [ead #2 - file://work/cbr/input] cbr-route INFO Sending
> order ID-DESKTOP-9NT300B-51935-1481791551205-0-1 to another country
> [ead #2 - file://work/cbr/input] cbr-route INFO Done
> processing ID-DESKTOP-9NT300B-51935-1481791551205-0-1
> [mel.test.blueprint.Main.main()] BlueprintExtender INFO
> Destroying BlueprintContainer for bundle org.apache.aries.blueprint.cm/1.0.6
> [mel.test.blueprint.Main.main()] BlueprintExtender INFO
> Destroying BlueprintContainer for bundle cbr218/1.0.0.SNAPSHOT
> [mel.test.blueprint.Main.main()] BlueprintCamelContext INFO Apache
> Camel 2.18.1 (CamelContext: cbr-example-context) is shutting down
> [mel.test.blueprint.Main.main()] DefaultShutdownStrategy INFO
> Starting to graceful shutdown 1 routes (timeout 300 seconds)
> [text) thread #3 - ShutdownTask] DefaultShutdownStrategy INFO Route:
> cbr-route shutdown complete, was consuming from: file://work/cbr/input
> [mel.test.blueprint.Main.main()] DefaultShutdownStrategy INFO
> Graceful shutdown of 1 routes completed in 0 seconds
> [mel.test.blueprint.Main.main()] BlueprintCamelContext INFO Apache
> Camel 2.18.1 (CamelContext: cbr-example-context) uptime 28.869 seconds
> [mel.test.blueprint.Main.main()] BlueprintCamelContext INFO Apache
> Camel 2.18.1 (CamelContext: cbr-example-context) is shutdown in 0.019 seconds
> [mel.test.blueprint.Main.main()] BlueprintExtender INFO
> Destroying BlueprintContainer for bundle org.apache.aries.blueprint.core/1.4.4
> [mel.test.blueprint.Main.main()] BlueprintExtender INFO
> Destroying BlueprintContainer for bundle
> org.apache.camel.camel-blueprint/2.18.1
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator stopping
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator stopped
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator stopping
> [mel.test.blueprint.Main.main()] Activator INFO Camel
> activator stopped
> [mel.test.blueprint.Main.main()] CamelBlueprintHelper INFO
> Deleting work directory target/bundles/1481791550078
> [ERROR] *************************************
> [ERROR] Error occurred while running main from:
> org.apache.camel.test.blueprint.Main
> [ERROR]
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.apache.camel.maven.RunMojo$1.run(RunMojo.java:472)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: Gave up waiting for BlueprintContainer
> from bundle "MyBundle"
> at
> org.apache.camel.test.blueprint.CamelBlueprintHelper.waitForBlueprintContainer(CamelBlueprintHelper.java:363)
> at org.apache.camel.test.blueprint.Main.doStart(Main.java:111)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at org.apache.camel.main.MainSupport.run(MainSupport.java:138)
> at org.apache.camel.main.MainSupport.run(MainSupport.java:390)
> at org.apache.camel.test.blueprint.Main.main(Main.java:82)
> ... 6 more
> [ERROR] *************************************
> [WARNING] thread
> Thread[ForkJoinPool.commonPool-worker-1,5,org.apache.camel.test.blueprint.Main]
> was interrupted but is still alive after waiting at least 15000msecs
> [WARNING] thread
> Thread[ForkJoinPool.commonPool-worker-1,5,org.apache.camel.test.blueprint.Main]
> will linger despite being asked to die via interruption
> [WARNING] thread
> Thread[ForkJoinPool.commonPool-worker-5,5,org.apache.camel.test.blueprint.Main]
> will linger despite being asked to die via interruption
> [WARNING] NOTE: 2 thread(s) did not finish despite being asked to via
> interruption. This is not a problem with exec:java, it is a problem with the
> running code. Although not serious, it should be remedied.
> [WARNING] Couldn't destroy threadgroup
> org.apache.camel.maven.RunMojo$IsolatedThreadGroup[name=org.apache.camel.test.blueprint.Main,maxpri=10]
> java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.destroy(ThreadGroup.java:778)
> at org.apache.camel.maven.RunMojo.execute(RunMojo.java:505)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 49.194 s
> [INFO] Finished at: 2016-12-15T09:46:35+01:00
> [INFO] Final Memory: 44M/547M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.camel:camel-maven-plugin:2.18.1:run
> (default-cli) on project camel-blueprint-cbr: null: MojoExecutionException:
> InvocationTargetException: Gave up waiting for BlueprintContainer from bundle
> "MyBundle" -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ Thread-1] MainSupport$HangupInterceptor INFO
> Received hang up - stopping the main instance.
> {noformat}
> my first guess is that Camel 2.18.1 is starting faster and that some events
> occurs in the same milliseconds (considering the the jvm precision):
> https://github.com/apache/camel/blame/master/components/camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/CamelBlueprintHelper.java#L344
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
