I have a maven + spring based application which I built and deployed in Servicemix.
However, when tried to start the bundle, it remained in the Waiting status for a long time before generating following exception:
16:25:52,219 | DEBUG | Timer-0 | DependencyServiceManager | startup.DependencyServiceManager 339 | 72 - org.springframework.osgi.extender - 1.2.0 | Deregistering service dependency dependencyDetector for OsgiBundleXmlApplicationContext(bundle= abc, config=osgibundle:/META-INF/spring/*.xml)
16:25:52,219 | ERROR | Timer-0 | WaiterApplicationContextExecutor | WaiterApplicationContextExecutor 432 | 72 - org.springframework.osgi.extender - 1.2.0 | Unable to create application context for [abc], unsatisfied dependencies: Dependency on [(objectClass=javax.sql.DataSource)] (from bean [&dataSource])
org.springframework.context.ApplicationContextException: Application context initialization for 'com.vetstreet.pet_mailer' has timed out
Appreciate any help or suggestion.
Spring Extender holds back the startup of an application (setting it's status to Waiting) if a service that you're referencing is unavailable at startup. The reason is that the availability attribute of every referenced service is set to mandatory, and
there's a default-timeout global attribute which is by default set to 5 seconds. If the service you're referring to doesn't appear in that amount of time, Spring Extender will throw an Exception like that you have.
So what I think is something wrong with the service publication of your DataSource. Do you have the corresponding tag in your other application?
<osgi:service ...>
Check out this link: http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html/service-registry.html. It contains a lot of example. Ensure that in both osgi:service and both osgi:reference you have the javax.sql.DataSource interface set. And be aware of not publishing the same interface by 2 different bundles.
One more thing: just to be sure, import the javax.sql package in your manifest:
<Import-Package>javax.sql</Import-Package>
Hope this helps, Gergely
Related
I'm using integration of Spring Boot and Flyway (6.5.5) to run updates for CockroachDB cluster. When several instances of service are starting in the same time, all of them are trying to lock flyway_schema_history table to validate migrations. However, the following exception occurs:
2020-09-09 00:00:00.013 ERROR 1 --- [ main] o.s.boot.SpringApplication :
Application run failed org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]:
Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException:
Unable to obtain table lock - another Flyway instance may be running
I could not find any config property to tweak this. Maybe someone faced with the same issue and solved it somehow?
Workaround: restart service.
After debugging the issue, it's appeared in very weird Flyway behaviour:
org.flywaydb.core.internal.database.cockroachdb.CockroachDBTable
CockroachDB-specific table.
Note that CockroachDB doesn't support table locks. We therefore use a row in the schema history as a lock indicator;
if another process ahs inserted such a row we wait (potentially indefinitely) for it to be removed before
carrying out a migration.
*/
So, in my case during applying migration, service was restarted and this pseudo lock record left forever.
Workaround was delete the "lock" manually:
installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success
-----------------+----------------------------------+------------------------------------------+------+--------------------------------------------------+-------------+--------------------+----------------------------------+----------------+----------
-100 | d9ab17626a4d66a4d8a89fe9bdca98e9 | flyway-lock | | | 0 | | 2020-09-14 11:25:02.874838+00:00 | 0 | true
Hope, it will help someone.
The appropriate ticket has been created: https://github.com/flyway/flyway/issues/2932
I am using Apache Karaf 4.1.1 and Karaf Cellar. I have written two bundles. The first bundle provides a service of type ITrackerManager. The second bundle has a component that references ITrackerManager. My end goal is to witness the component in the second bundle successfully get a reference to the ITrackerManager service in the first bundle which is running on a different node. This is all part of my exploration of distributed OSGi.
What is actually happening when I install that second bundle is that it gets installed but fails to activate due to missing the service reference. I must be conducting my test incorrectly. Any ideas on how I would go about demonstrating my end goal; component in bundle on Node B successfully uses service on Node A?
Here is how I have run my test so far.
Node A
karaf#root()> cluster:node-list
| Id | Alias | Host Name | Port
--+-------------------+-------+--------------+-----
x | 159.4.251.58:5701 | | 159.4.251.58 | 5701
| 159.4.251.58:5702 | | 159.4.251.58 | 5702
Node B
karaf#root()> cluster:node-list
| Id | Alias | Host Name | Port
--+-------------------+-------+--------------+-----
| 159.4.251.58:5701 | | 159.4.251.58 | 5701
x | 159.4.251.58:5702 | | 159.4.251.58 | 5702
So far so good. I am running two karaf instances on my computer. Both instances see each other. Now I want to install that first bundle onto Node A ONLY. To accomplish that, I install the bundle into the cluster, then specifically remove it from Node B.
Node A
karaf#root()> cluster:bundle-install -s default mvn:myCompany/dosgi-example-part1/1.0-SNAPSHOT
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+--------------------------------------------------------------
0 | Active | | cluster/local | | 5.6.2 | System Bundle
...
67 | Active | | cluster/local | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> cluster:service-list
Service Class | Provider Node
--------------------------+------------------
myCompany.ITrackerManager | 159.4.251.58:5701
| 159.4.251.58:5702
Still looking good. My bundle is in the cluster, is local on Node A (and Node B at this point), and the service is recognized by the cluster and is available on both Node A and Node B. Now to remove the bundle from Node B.
Node B
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+-------------------------------------------------------------
67 | Active | | cluster/local | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
---+--------+-----+----------------+-----------------------------------------------
75 | Active | 80 | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> bundle:uninstall 75
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+--------------------------------------------------------------
67 | Active | | cluster | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> cluster:service-list
Service Class | Provider Node
--------------------------+------------------
myCompany.ITrackerManager | 159.4.251.58:5701
Excellent. The first bundle has been removed from Node B but still shows up as being in the cluster. Both nodes agree that my service is only available on Node A now (since the bundle was removed from Node B). Now I will load my second bundle on Node B only. This is where I run into problems. I don't load the second bundle using the cluster:bundle-install command because I don't want it ending up on Node A. So instead I install my second bundle using the normal bundle:install command. This results in an error about an unsatisfied reference.
Node B
karaf#root()> bundle:install -s mvn:otherCompany/dosgi-example-part2/1.0-SNAPSHOT
Bundle ID: 76
Error executing command: Error installing bundles:
Unable to start bundle mvn:otherCompany/dosgi-example-part2/1.0-SNAPSHOT: org.osgi.framework.BundleException: Unable to resolve otherCompany.dosgi-example-part2 [76](R 76.0): missing requirement [otherCompany.dosgi-example-part2 [76](R 76.0)] osgi.wiring.package; (&(osgi.wiring.package=myCompany)(version>=1.0.0)(!(version>=2.0.0))) Unresolved requirements: [[otherCompany.dosgi-example-part2 [76](R 76.0)] osgi.wiring.package; (&(osgi.wiring.package=myCompany)(version>=1.0.0)(!(version>=2.0.0)))]
karaf#root()> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
---+-----------+-----+----------------+-----------------------------------------------------------------------------------------------------
76 | Installed | 80 | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 2
So there it is. I install the second bundle on NodeB only, expecting that it is able to successfully use the required service which resides on Node A only. Unfortunately that does not happen. Instead I get error message stating there are unresolved requirements. It seems to behave as if DOSGI is not available. If I install both bundles on the same node, the second bundle activates without any errors. Any insights you may have would be appreciated.
My problem was two-fold.
Stuff to be sent over DOSGI needs to be serializable. In my case, I was calling a method on a remote service that took an argument. That argument was a class type defined in a common API. That class type was not serializable. Once I made it serializable, it starting getting different errors. Which brings me to...
Normal name space rules apply. I will elaborate below.
My API defined two interfaces.
ITracker
ITrackerManager
That API bundle was installed into the cluster so it is available on all nodes. My Service bundle had a concrete implementation of ITrackerManager. When that bundle is installed locally on Node A, the cluster:service-list command correctly shows that Node A has a service of type ITrackerManager.
My Client bundle has a concrete implementation of ITracker that had a reference to ITrackerManager which was installed on Node B. The first thing the ITracker instance did in its activate method was call ITrackerManager.addTracker(this). What should have happened was that the instance of ITracker on Node B provided itself to the ITrackerManager running on Node A. Initially this failed because ITracker was not serializable. Once that was solved, I started seeing classNotFound exceptions on Node A.
Node A was trying to deserialize the ITracker instance locally. It was attempting to deserailize a concrete class (TheirTracker) which was not defined locally, it was only defined on Node B in the client bundle. This failed.
So the normal namespace rules apply. Even though the client bundle on Node B has a reference to a service running in a bundle Node A, the service bundle in Node A cannot create (i.e. deserialize) an instance of a class that only exists in the client bundle on Node B.
I switched up my interfaces so that ITrackerManager method does not take an ITracker arguement. Instead it takes a string. Invoking that method over DOSGi works fine.
While I understand why this problem exists, this undermines a core capability I was hoping to use with DOSGi. I want clients to be able to register with a central controller which will actively control them. This won't work because even though the clients implement the interface the central controller is looking for, the specific serialization fails at the central controller. The client concrete classes exist in a namespace unknown to the central controller, hence the client cannot successfully pass itself to the central controller.
This must be a way to achieve what I am looking for in DSOGi without making each of the multiple clients an exported DSOGi service. Any ideas?
I'm working on JBossFuse 6.2, have a CXF endpoint for which I needed to setup some special properties through httpj:engine-factory configuration block. Upon trying that I hited this issue
MapMetadataImpl not found by org.apache.cxf.cxf-rt-transports-http-jetty
The error was the following
> ERROR | pool-43-thread-1 | BlueprintContainerImpl | 14 -
> org.apache.aries.blueprint.core - 1.4.2 | Unable to start blueprint
> container for bundle test-ws java.lang.NoClassDefFoundError:
> org/apache/aries/blueprint/reflect/MapMetadataImpl at
> org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parseEngineConnector(JettyServerEngineFactoryParser.java:110)
> at
> org.apache.cxf.transport.http_jetty.blueprint.JettyServerEngineFactoryParser.parse(JettyServerEngineFactoryParser.java:83)
It appeared when trying to add the httpj block for CXF definition.
<httpj:engine-factory bus="cxf">
<httpj:engine port="${port}" host="${host}">
<httpj:threadingParameters minThreads="${minThreads}" maxThreads="${maxThreads}"/>
</httpj:engine>
</httpj:engine-factory>
I tried the solution provided, in the referred posts that is installing the osgi bundle for Blueprint Core Compatibility.
osgi:install mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0
However, after installing the bundle upon container start I get the following exception:
2016-06-22 11:01:13,279 | ERROR | 63859-1-thread-1 | DeploymentAgent | ?? | 83 - io.fabric8.fabric-agent - 1.2.0.redhat-133 | Unable to update agent
java.lang.IllegalStateException: Resource has no uri
at io.fabric8.agent.service.Deployer.getBundleInputStream(Deployer.java:1354)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at io.fabric8.agent.service.Deployer.deploy(Deployer.java:714)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at io.fabric8.agent.service.Agent.provision(Agent.java:348)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at io.fabric8.agent.service.Agent.provision(Agent.java:194)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:642)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:256)[83:io.fabric8.fabric-agent:1.2.0.redhat-133]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_80]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_80]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_80]
Has anybody ever applied the proposed solution in JbossFuse? I don't event understand that much why that exception is being fired.
Thanks in advanced!
I anybody falls into this, I got an answer from someone at Red Hat. The problem I was having is that I was on a Fabric environment, so I had to add the OSGi Blueprint Core Compatibility bundle to the Karaf profile in the Fabric. It can be done from the karaf console by running the following command
profile-edit --bundles mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0 karaf 1.x
Where 1.x is current fabric version in use.
If you are NOT on a fabric environment, then the solution posted above should work just as is.
Hope this helps!
I have (intentionally created situation to test my CI setup) a bundle which does not have all dependencies configured correctly. When I deploy that the deployment fails with an exception as it should:
2014-02-07 09:17:15,738 | ERROR | rint Extender: 3 | BlueprintCamelContext | 103 - org.apache.camel.camel-blueprint - 2.10.7 | Error occurred during starting Camel: CamelContext(ura) due "org.xmlsoap.schemas.soap.envelope" doesnt contain ObjectFactory.class or jaxb.index
javax.xml.bind.JAXBException: "org.xmlsoap.schemas.soap.envelope" doesnt contain ObjectFactory.class or jaxb.index
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_11]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_11]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_11]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_11]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:143)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:310)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at org.apache.camel.dataformat.soap.SoapJaxbDataFormat.createContext(SoapJaxbDataFormat.java:303)[206:org.apache.camel.camel-soap:2.10.7]
at org.apache.camel.converter.jaxb.JaxbDataFormat.doStart(JaxbDataFormat.java:254)[187:org.apache.camel.camel-jaxb:2.10.7]
at org.apache.camel.dataformat.soap.SoapJaxbDataFormat.doStart(SoapJaxbDataFormat.java:101)[206:org.apache.camel.camel-soap:2.10.7]
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)[100:org.apache.camel.camel-core:2.10.7]
at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:62)
The problem is that the bundle status is still "Active". Why?
karaf#root> osgi:list
START LEVEL 100 , List Threshold: 50
ID State Blueprint Spring Level Name
[ 242] [Active ] [Created ] [ ] [ 80] integraatiot-foo (1.0.0.SNAPSHOT)
I would like to setup my CI builds to that they detect failed bundles using http://code.citytechinc.com/osgi-bundle-status-maven-plugin/. This idea fails since bundle status is always "Active".
The bundle is active because it has been activated. This is normal. If an error occurred in some code within the bundle, that is nothing to do with the OSGi active state.
So you need to work out some way to report your internal failure such that it can be picked up by a CI build. I suggest using the OSGi LogService.
You'll need to make sure all your dependencies are required and with the correct version.
In this case it might be that the package your importing does existing in the wrong version.
Or better did you make sure you only import the right version of the package with [2,3.0) for example. Especially the stack trace makes it suspicious to me that your using import without version range and therefore do import the JRE jaxb classes which usually do have version 0.0.0
To check which bundles are actually used for import log in the shell and do a bundle:header [bundleID]
I'm using Maven for dependency management. When I run the test cases an exception occurs at the end of test cases though test cases pass successfully.
Following is my stack trace:
2013-10-08 16:04:22,839 [Thread-15] ERROR plugins.DefaultGrailsPlugin - Error configuration scaffolding: Error creating bean with name 'instanceControllersApi': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
Message: Error creating bean with name 'instanceControllersApi': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
Line | Method
->> 662 | run in java.lang.Thread
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I'm using Grails 2.1.3. I have tried both, "static" and "dynamic" scaffolding but it did not resolve the issue.
I also referred to What does this exception mean? issue but no luck.
One user with a similar error fixed it by deleting the project folder in his ~/.grails directory.
http://grails.1312388.n4.nabble.com/Database-migration-plugin-Running-dbm-gorm-diff-results-Error-creating-bean-with-name-instanceContro-td4637567.html
A good ol' grails clean might help too, and be less invasive.
Also, if you can share the project through source control (git, mercurial, svn), you might try reproducing the issue on another machine. If you can't, that's a good sign that the issue is peculiar to your environment, and could be resolved through some sort of cleanup.
I have resolved my issue. I am not sure why it was occurring but i had many controller where scaffold=true. I generated the all controller and view and it resolved my issue.