Some time while starting a bundle (basecomponent) I am getting the below error. It seems it is because of the two different versions of fasterxml.jackson.annotations . basecomponent bundle is using fasterxml.jackson.annotations 2.7.4 . basecomponent bundle is also using camel-aws which may be using fasterxml.jackson.annotation 2.5.0.
smx#root>bundle:start 277
Error executing command: Error executing command on bundles:
Unable to execute command on bundle 277: Uses constraint violation. Unable to resolve bundle revision basecomponent [277.0] because it is exposed to package 'com.fasterxml.jackson.annotation' from bundle revisions com.fasterxml.jackson.core.jackson-annotations [284.0] and com.fasterxml.jackson.core.jackson-annotations [125.0] via two dependency chains.
Chain 1:
basecomponent [277.0]
import: (&(osgi.wiring.package=com.fasterxml.jackson.annotation)(version>=2.7.0)(!(version>=3.0.0)))
|
export: osgi.wiring.package=com.fasterxml.jackson.annotation
com.fasterxml.jackson.core.jackson-annotations [284.0]
Chain 2:
basecomponent [277.0]
import: (osgi.wiring.package=com.amazonaws)
|
export: osgi.wiring.package=com.amazonaws; uses:=com.fasterxml.jackson.annotation
org.apache.servicemix.bundles.aws-java-sdk [254.0]
import: (&(osgi.wiring.package=com.fasterxml.jackson.annotation)(version>=2.5.0)(!(version>=3.0.0)))
|
export: osgi.wiring.package=com.fasterxml.jackson.annotation
com.fasterxml.jackson.core.jackson-annotations [125.0]
Can some one let me know how can I get around this dependency conflict? I am using Karaf 3.0.5 running under Servicemix 6.1.0.
As suggested in Karaf Mailing List. Moving to Karaf 4.0.5 (under Servicemix 7.0.0.M2 ) and setting dependency=true in feature.xml I am not observing the issue now.
Related
I have a ASP.NET WebForms application that uses some Ninject packages, but I am stuck at a certain version. When I try to upgrade to the latest version, I get "Unable to resolve dependencies" issues.
The packages in question are:
Package InstalledVer LatestVer
------------------------------------------------------
Ninject v3.2.2 v3.3.4
Ninject.Web v3.2.1 ✔ v3.2.1
Ninject.Web.Common v3.2.3 v3.3.1
Ninject.Web.Common.WebHost v3.2.3 v3.3.1
If I try updating Ninject, I get:
Unable to resolve dependencies. 'Ninject 3.3.4' is not compatible with
'Ninject.Web 3.2.1 constraint: Ninject (>= 3.2.0 && < 3.3.0)'
but Ninject.Web is already at the latest version!
Should I change the Dependency behaviour of Ninject.Web or would this be unsafe? If I do, what should I change the Dependency behavior to?
Thanks
Okay, so this is how to fix:
Remove the Ninject.Web package completely. This package is no longer required as it is now integrated into Ninject.Web.Common (well, version v3.3+ anyway)
Update the packages Ninject, Ninject.Web.Common and Ninject.Web.Common.WebHost. These should now upgrade okay. For me, they are both v3.3.1.
As part of the package upgrade a new file App_Start\Ninject.Web.Common.cs will have been added. This is just a rename of the existing App_Start\NinjectWeb.Common.cs so either [a] delete the new file or [b] migrate over your Ninject module registrations and remove the old file.
In web.config, you should now remove the OnePerRequestModule module:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="OnePerRequestModule" type="Ninject.Web.Common.OnePerRequestHttpModule" />
</modules>
</system.webServer>
This is because this module, is registered dynamically on loadup in the App_Start\Ninject.Web.Common.cs file's Start() method:
public static void Start()
{
DynamicModuleUtility.RegisterModule(typeof(OnePerRequestHttpModule));
DynamicModuleUtility.RegisterModule(typeof(NinjectHttpModule));
bootstrapper.Initialize(CreateKernel);
}
If you don't remove this entry from web.config then you can expect a type exception when launching your application, not least because as part of the version update, the class has moved from the Ninject.Web.Common namespace to Ninject.Web.Common.WebHost.
You can also remove the file App_Start\NinjectWeb.cs for the same reason (registering NinjectHttpModule)
If OnePerRequestHttpModule doesn't resolve in App_Start\Ninject.Web.Common.cs then add the following using statement to the file using Ninject.Web.Common.WebHost; (I think this is a missing reference in v3.3.1 of the package.
Hope this helps others.
I need to update libvncserver and libvncclient libraries to 0.9.11.
I am running CentOS 7.3, currently, the latest libvncserver RPM is 0.9.9
So I took the libvncserver SRPM, modified the spec file, and updated the libvncserver tarball to create a 0.9.11 version of libvncserver and libvncclient RPM's.
I'm having a dependency challenge upon install.
Loaded plugins: fastestmirror
Examining ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm as an update to libvncserver-0.9.9-9.el7_0.1.x86_64
Examining ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Examining ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-devel-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package libvncserver.x86_64 0:0.9.9-9.el7_0.1 will be updated
--> Processing Dependency: libvncclient.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
Loading mirror speeds from cached hostfile
--> Processing Dependency: libvncserver.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
---> Package libvncserver.x86_64 0:0.9.11-1.el7.centos.1 will be an update
---> Package libvncserver-debuginfo.x86_64 0:0.9.11-1.el7.centos.1 will be installed
---> Package libvncserver-devel.x86_64 0:0.9.11-1.el7.centos.1 will be installed
--> Finished Dependency Resolution
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncclient.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncclient.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncclient.so.1()(64bit)
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncserver.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncserver.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncserver.so.1()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
x11vnc is using libvncserver.so.0 and libvncclient.so.0 from 0.9.9
[localhost SPECS]$ sudo ldd /usr/bin/x11vnc | grep -i vnc
libvncserver.so.0 => /lib64/libvncserver.so.0 (0x00007fee9387d000)
libvncclient.so.0 => /lib64/libvncclient.so.0 (0x00007fee9365f000)
Running the above in verbose, rpm tries to update x11vnc (to there is none)
Potential Provider: libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode is ud for provider of libvncserver.so.0()(64bit): libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode for pkg providing libvncserver.so.0()(64bit): ud
Trying to update x11vnc-0.9.13-11.el7.x86_64 to resolve dep
No update paths found for x11vnc-0.9.13-11.el7.x86_64. Failure!
Searching pkgSack for dep: libvncserver.so.0()(64bit)
I could "force-install" but before I do so I'm interested is there a better way to do this? Is it possible to specify dependency checker to not highlight the dependency? Another approach is to create a custom x11vnc RPM, just to update the library path.
The problem is that your package does not provide libvncserver.so.0, but replaces libvncserver, which provides libvncserver.so.0. The easiest solution is to rename your package, so that it can be installed along with the existing libvncserver package.
The -devel subpackage will probably have to conflict with libvncserver-devel because some of the files will overlap, but for the main package, you should be able to enable parallel installation.
You already mentioned the other clean solution: Port all packages from libvncserver.so.0 to libvncserver.so.1. But that could involve quite a bit of unnecessary work and makes your system less similar to others.
(You could also keep the libvncserver package name and create a compat-libvncserver package with the old library, but that's again quite a bit of work for very little benefit.)
In InSpec 1.9.0 I defined the following profile with dependency, including all controls from the dependent profile.
However, when executing I get the error indicating the profile "is not listed as dependency"
What am I missing?
inspec.yml:
name: my-profile
version: 0.0.1
supports:
- os-family: unix
depends:
- name: ssh-baseline
url: https://github.com/dev-sec/ssh-baseline/archive/master.zip
controls/include_ssh_baseline.rb:
include_controls 'ssh-baseline'
Command:
inspec exec my-profile -t ssh://user#host.domain
The result of executing the profile:
Cannot load ssh-baseline since it is not listed as a dependency
of my-profile.
Dependencies available from this context are:
(two empty lines)
I don't see a syntax error. It's almost copy-paste example from InSpec Profiles page.
The following dependency definition (git instead of url) also caused the same error message as above:
depends:
- name: ssh-baseline
git: https://github.com/dev-sec/ssh-baseline.git
inspec.lock file is created on the first profile execution and contains a reference to the dependencies. If you build your profile incrementally you might end up with an inspec.yml file containing no dependencies (from the first run):
---
lockfile_version: 1
depends: []
You need to delete the file if you want changes to the inspec.yml to be reflected or run the following inside the profile directory:
inspec vendor --overwrite
See Vendoring dependencies (it doesn't mention --overwrite, but it immediately throws an error if it's not present):
When you execute a local profile, the inspec.yml file will be read in order to source any profile dependencies. It will then cache the dependencies locally and generate an inspec.lock file. If you add or update dependencies in inspec.yml, please refresh the lock file by either:
running inspec vendor inside the profile directory; or
deleting inspec.lock before running inspec exec
I just created it a profile based on your post and it works without any issues. I used inspec 1.9.0. Just to be sure, can you try inspec exec ./my-profile -t ssh://user#host.domain?
I'm new to Purescript and am following the tutorial for installation. Purescript itself is working and I can start the CLI using pulp psci, but installing purescript-list runs into trouble.
Having entered the command bower install purescript-lists --save, I get a long list of package names, but when it gets to purescript-eff and purescript-prelude I run into some version conflicts:
bower purescript-eff#^2.0.0 cached https://github.com/purescript/purescript-eff.git#2.0.0
bower purescript-eff#^2.0.0 validate 2.0.0 against https://github.com/purescript/purescript-eff.git#^2.0.0
Unable to find a suitable version for purescript-eff, please choose one by typing one of the numbers below:
1) purescript-eff#^1.0.0 which resolved to 1.0.0 and is required by purescript-console#1.0.0
2) purescript-eff#^2.0.0 which resolved to 2.0.0 and is required by purescript-st#2.0.0
Prefix the choice with ! to persist it to bower.json
? Answer
A similar message is shown for purescript-prelude. No matter which options I choose, both pulp build and pulp run fail with:
$ pulp build
* Building project in /Developer/purescript/training1
Error found:
in module PSCI.Support
at /Developer/purescript/training1/bower_components/purescript-psci-support/src/PSCI/Support.purs line 10, column 34 - line 10, column 53
Cannot import value unsafeInterleaveEff from module Control.Monad.Eff.Unsafe
It either does not exist or the module does not export it.
See https://github.com/purescript/purescript/wiki/Error-Code-UnknownImport for more information,
or to contribute content related to this error.
Compiling PSCI.Support
* ERROR: Subcommand terminated with exit code 1
What have I missed here?
Thanks
Chris W
If you are using psc version 0.10.* you should go with prelude, lists and eff v2*.
If you are using psc version 0.9.* you should go with prelude, lists and eff v1*.
If you are using psc 0.10.* you might want to update pulp to version 9.1.0
The problem occurs due to breaking changes between psc 0.9 and 0.10 and the relevant libraries. by writing bower install purescript-lists --save you are asking bower for the latest dependencies which conflict with the dependency versions specified in your bower.json.
I am using Karaf 2.3.1. I was following Apache Karaf Manual exercise "Extending the console" page no. 105. I followed all the instruction ditto, with a few deviations. I am able to load the bundle HelloShellCommand into Karaf. It threw me a bundle Id. But the command "test.hello" is not working.
karaf#root> osgi:classes is showing org/apache/karaf.shell/samplesHelloShellCommand.class
karaf#root> test.hello is showing command not found
karaf#root> osgi:list is showing Blueprint "Failure" for the given bundle.
I did deviate from the given instruction in "Compiling the JAR" section in following steps:
Let's try to build the jar: I did build the jar from Eclipse. File-Export-Java-Jar File.
Then run "mvn install": This is where I did not understand how Maven will use the .jar file. It is looking for pom.xml. So, I went into root directory and ran "mvn install". It went through successfully.
osgi:install .., also went through successfully. But I suspect Blueprint.xml did not go through.
I need help in:
How to resolve this?
How to know in Karaf what commands are installed with each bundle?
.jar file created in step-1 is different from "mvn install" which uses pom.xml. Is there something I am missing? How to make mvn use the .jar?
And why blueprint.xml did not load?
Thanks in advance
Further, we have this stackoverflow:
2013-07-27 19:44:30,733 | ERROR | rint Extender: 2
| BlueprintContainerImpl
| container.BlueprintContainerImpl 393
| 7 - org.apache.aries.blueprint.core - 1.1.0
| Unable to start blueprint container for bundle null
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:570)[:1.7.0-ea]
at java.util.ArrayList.get(ArrayList.java:348)[:1.7.0-ea]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.readDirectives
(BlueprintContainerImpl.java:211)[7:org.apache.aries.blueprint.core:1.1.0]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun
(BlueprintContainerImpl.java:283)[7:org.apache.aries.blueprint.core:1.1.0]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run
(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0]
at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:471)[:1.7.0-ea]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0-ea]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0-ea]
at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run
(ExecutorServiceWrapper.java:106)[7:org.apache.aries.blueprint.core:1.1.0]
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run
(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.1.0]
at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:471)[:1.7.0-ea]
at java.util.concurrent.FutureTask$Sync.innerRun (FutureTask.java:334)[:1.7.0-ea]
at java.util.concurrent.FutureTask.run (FutureTask.java:166)[:1.7.0-ea]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201
(ScheduledThreadPoolExecutor.java:178)[:1.7.0-ea]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run
(ScheduledThreadPoolExecutor.java:292)[:1.7.0-ea]
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1110)[:1.7.0-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:603)[:1.7.0-ea]
at java.lang.Thread.run(Thread.java:717)[:1.7.0-ea]
Regarding 1)
Is the bundle started? Did you use osgi:install -s with starting? If not you should start the bundle with start [bundleId]
Regarding 2)
Issue help at command line, it'll list all available commands. Using command -h will give you a overview of the command itself.
Regarding 3)
forget about creating a jar file from eclipse that won't work. Only with the maven pom you'll have a bundle that contains a valid Manifest unless you added this yourself (which I didn't see in your description)
Regarding 4)
Most likely your bundle either isn't started or it doesn't contain a valid manifest which in turn doesn't start the blueprint extender.
Besides that all those questions are usually best asked at the karaf users mailinglist
EDIT:
For finding the reason why a bundle did fail do a bundle:info on the bundle with the given ID
it should also show you why a blueprint failed.