When trying to install my application as an osgi bundle with the install command in karaf on the command line, everything seems fine. When I then type start (id) everything still seems fine, but my application does not seem to accept requests. When I then type log:display, I get this:
2016-04-20 13:49:38,251 | INFO | Thread-19 | bundle | 37 - org.apache.aries.spifly.dynamic.bundle - 1.0.1 | Bundle Considered for SPI providers: oms-integrations
2016-04-20 13:49:38,251 | INFO | Thread-19 | bundle | 37 - org.apache.aries.spifly.dynamic.bundle - 1.0.1 | No 'SPI-Provider' Manifest header. Skipping bundle: oms-integrations
I'm new and I have no clue what this means ("No 'SPI-Provider' Manifest header.") or how to solve it?
This is not a problem. It just means that you have Aries spi-fly installed. It scans all bundles for this header and enhances the ones with the header to be able to use the ServiceLoader in OSGi. If you do not use ServiceLoader then you can safely ignore these messages.
You can also configure this logger to WARN to suppress the messsages.
Related
I have just started exploring substrate and I am following this tutorial, (https://docs.substrate.io/tutorials/v3/add-a-pallet/).
Under step Implement the Nicks pallet Config trait -> Add Nicks to the construct_runtime! macro., I added Nicks pallet to my runtime, as shown in the screenshot.
Now, when I run cargo check -p node-template-runtime, I get a lot of errors;
asad#asad-Z440:~/Dev/Blockchain/polkadot/substrate-node-template$ cargo check -p node-template-runtime
warning: /home/asad/Dev/Blockchain/polkadot/substrate-node-template/node/Cargo.toml: version requirement `3.0.0-monthly-2021-09+1` for dependency `node-template-runtime` includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion
warning: /home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime/Cargo.toml: version requirement `3.0.0-monthly-2021-09+1` for dependency `pallet-template` includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion
Updating git repository `https://github.com/paritytech/substrate.git`
Updating crates.io index
Updating git repository `https://github.com/paritytech/substrate.git`
Compiling node-template-runtime v3.0.0-monthly-2021-09+1 (/home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime)
error: failed to run custom build command for `node-template-runtime v3.0.0-monthly-2021-09+1 (/home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime)`
Caused by:
process didn't exit successfully: `/home/asad/Dev/Blockchain/polkadot/substrate-node-template/target/debug/build/node-template-runtime-c9c48352bd7ed47e/build-script-build` (exit status: 1)
--- stdout
Information that should be included in a bug report.
Executing build command: "rustup" "run" "nightly" "cargo" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=/home/asad/Dev/Blockchain/polkadot/substrate-node-template/target/debug/wbuild/node-template-runtime/Cargo.toml" "--color=always" "--release"
Using rustc version: rustc 1.57.0-nightly (aa7aca3b9 2021-09-30)
--- stderr
warning: /home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime/Cargo.toml: version requirement `3.0.0-monthly-2021-09+1` for dependency `pallet-template` includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion
Updating git repository `https://github.com/paritytech/substrate.git`
Compiling node-template-runtime v3.0.0-monthly-2021-09+1 (/home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime)
warning: unused doc comment
--> /home/asad/Dev/Blockchain/polkadot/substrate-node-template/runtime/src/lib.rs:253:1
|
253 | /// Nicks Config:
| ^^^^^^^^^^^^^^^^^ rustdoc does not generate documentation for macro invocations
|
= note: `#[warn(unused_doc_comments)]` on by default
= help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion
error: duplicate lang item in crate `sp_io` (which `frame_support` depends on): `panic_impl`.
.........
310 | / construct_runtime!(
311 | | pub enum Runtime where
312 | | Block = Block,
313 | | NodeBlock = opaque::Block,
... |
327 | | }
328 | | );
| |__^
note: required by a bound in `sp_runtime::generic::UncheckedExtrinsic`
--> /home/asad/.cargo/git/checkouts/substrate-7e08433d4c370a21/20a9bbb/primitives/runtime/src/generic/unchecked_extrinsic.rs:39:40
|
39 | pub struct UncheckedExtrinsic<Address, Call, Signature, Extra>
| ^^^^ required by this bound in `sp_runtime::generic::UncheckedExtrinsic`
= note: this error originates in the macro `construct_runtime` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0277`.
warning: `node-template-runtime` (lib) generated 1 warning
error: could not compile `node-template-runtime` due to 112 previous errors; 1 warning emitted
Things I have tried:
Removing Cargo.lock file and then running cargo check -p node-template-runtime.
PS: I am just starting with rust and substrate, so spare me if i am asking something obvious here.
If you are working on a latest MacBook pro with M1 chip. Installing Cassandra and starting it might throw an error.
Steps
1: Installed Jdk8
2: Installed Cassandra 4.0.1
How to start: /opt/homebrew/opt/cassandra/bin/cassandra -f
Output:
ERROR [main] 2021-10-08 00:03:12,568 NativeLibraryDarwin.java:64 - Failed to link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: /opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: dlopen(/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp, 1): no suitable image found. Did find:
/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: no matching architecture in universal wrapper
/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: no matching architecture in universal wrapper
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.<clinit>(Native.java:195)
at com.sun.jna.NativeLibrary.<clinit>(NativeLibrary.java:87)
at org.apache.cassandra.utils.NativeLibraryDarwin.<clinit>(NativeLibraryDarwin.java:55)
at org.apache.cassandra.utils.NativeLibrary.<clinit>(NativeLibrary.java:98)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:763)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:887)
INFO [main] 2021-10-08 00:03:12,596 MonotonicClock.java:199 - Scheduling approximate time conversion task with an interval of 10000 milliseconds
INFO [main] 2021-10-08 00:03:12,597 MonotonicClock.java:335 - Scheduling approximate time-check task with a precision of 2 milliseconds
WARN [main] 2021-10-08 00:03:12,597 StartupChecks.java:143 - jemalloc shared library could not be preloaded to speed up memory allocations
WARN [main] 2021-10-08 00:03:12,597 StartupChecks.java:187 - JMX is not enabled to receive remote connections. Please see cassandra-env.sh for more info.
ERROR [main] 2021-10-08 00:03:12,597 CassandraDaemon.java:909 - The native library could not be initialized properly.
Solution:
Find where is jna-..*.jar located. you can do this using
find /opt/homebrew/ -name '*.jar' | grep cassandra
Browse to https://search.maven.org/artifact/net.java.dev.jna/jna/5.8.0/jar and download the jar from top-right downloads button on the page.
Replace your jna-..*.jar file with the one you downloaded. In my case i replaced jna-5.6.0.jar. Remember to keep the file name as your previous file name. Example I moved jna-5.8.0.jar and renamed as jna-5.6.0.jar
mv /Users/mansooralikhan/Downloads/jna-5.8.0.jar /opt/homebrew/Cellar/cassandra/4.0.1/libexec/jna-5.6.0.jar
Restart cassandra
To echo Mansoor's answer, I'll add that the version of JNA shipped with Apache Cassandra 4.0 unfortunately is not compatible with the M1 architecture.
To remedy this, head to the "downloads" section of the JNA GitHub repo, where you should find the latest version of the JNA jar file.
https://github.com/java-native-access/jna#jna
Download JNA version 5.8 or higher, and replace the existing jna-5.6.0.jar file in Cassandra's lib/ directory (tarball-based installs).
Just to add to the answers here, I wanted to note for posterity that the issue with arm64 on Apple M1 devices not supported by JNA 5.6.0 has been raised with the Apache Cassandra project previously.
More recently, it has been reported in CASSANDRA-17019. I brought it up with the project devs/contributors and hopefully it gets reviewed and resolved soon. Cheers!
I have a mac application (Eg. Sample.pkg containing Sample.app) along with few pkg dependencies (Eg. A.pkg and B.pkg ). Whenever the user runs the dmg/product archive bundled with these three packages, A.pkg and B.pkg has to be run first before Sample.pkg is installed.
Is there a way where I can specify this dependency while packaging the mac application, without need the user to manually check and install them in the right order?
Solution
There is a way.
You can add such entry to your distribution.xml
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<installer-gui-script minSpecVersion="1">
<title>Application name</title>
<organization>com.organization</organization>
....
<volume-check>
<required-bundles description="Some message which UI Installer doesn't show :(">
<!-- bundle 1 -->
<bundle id="com.organization.app1" path="Applications/App1.app" />
<!-- bundle 2 -->
<bundle id="com.organization.app2" path="Applications/App2.app" />
</required-bundles>
</volume-check>
....
</installer-gui-script>
This is documented here (required-bundles).
Some examples can be found on github.
Disadvantage
There is some bug in Apple Installer, required-bundles description says:
Attributes
|----------------|------------------|------------------------------------------------------------|
| Attribute name | Type | Description |
|----------------|------------------|------------------------------------------------------------|
| | | _Optional._ Values: `true` (default) to require all of |
| `all` | Boolean | the specified bundles, or `false` to require at least one |
| | | of them. |
|----------------|------------------|------------------------------------------------------------|
| `description` | String, | _Optional._ A description of the required bundles, |
| | localization key | displayed to the user if the requirement is not met. |
|----------------|------------------|------------------------------------------------------------|
So the message from description should be shown, but I can't see it anywhere, so user can be confused why he is unable to install application.
It just warns: You can't install <your application> here, <your application> do not allow it. (sorry translation from my localization back to English).
Alternative
I've seen some installation package which was running custom script form installation-check invoking it from installation JavaScript, using system.run('script_name').
I am trying to install and start the Apache Felix implementation of the OSGi UserAdmin interface in Karaf 2.3.3.
karaf#root> install mvn:org.apache.felix/org.apache.felix.useradmin/1.0.3
However, the bundle never gets resolved and I get the following error on start:
Unable to start bundle 89: Activator start error in bundle org.apache.felix.useradmin [89].
[...]
Caused by: java.lang.NoClassDefFoundError: org.osgi.service.useradmin.UserAdminListener
at org.apache.felix.useradmin.osgi.UserAdminListenerListHelper.class$(UserAdminListenerListHelper.java:38)
at org.apache.felix.useradmin.osgi.UserAdminListenerListHelper.<init>(UserAdminListenerListHelper.java:38)
at org.apache.felix.useradmin.osgi.Activator.createServiceContext(Activator.java:68)
at org.apache.felix.useradmin.osgi.Activator.start(Activator.java:37)
at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1605)
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_51]
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:636)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 16 more
As I read in this thread from the Karaf mailing list, Karaf already embeds the OSGi Compendium API but doesn't export all packages by default. I changed the config.properties file to explicitly export the UserAdmin package:
org.osgi.framework.system.packages= \
[...]
org.osgi.service.permissionadmin;uses:="org.osgi.framework";version="1.1", \
org.osgi.service.useradmin;uses:="org.osgi.framework";version="1.1", \
[...]
The package org.osgi.service.useradmin seems to be exported by Karaf, as I can see upon running packages:exports.
I kept getting the error until I removed the line from the config file and deployed the OSGi Compendium API bundle as suggested in this other thread.
However, embedding the complete Compendium API seems somewhat overkill to me (though I may be wrong). And I now have 4 bundles exporting the UserAdmin package:
karaf#root> packages:exports | grep useradmin
0 # org.osgi.service.useradmin; version=1.1.0
20 org.osgi.jmx.service.useradmin; version=1.1.0
82 org.osgi.service.useradmin; version=1.1.0 --> OSGi Compendium osgi.cmpn (5.0.0.201305092017)
89 org.apache.felix.useradmin; version=1.0.0 --> Apache Felix User Admin Service (1.0.3)
Do you know of a better/simpler way to achieve this?
karaf#root> packages:exports | grep useradmin
0 # org.osgi.service.useradmin; version=1.1.0
20 org.osgi.jmx.service.useradmin; version=1.1.0
82 org.osgi.service.useradmin; version=1.1.0 --> OSGi Compendium osgi.cmpn (5.0.0.201305092017)
89 org.apache.felix.useradmin; version=1.0.0 --> Apache Felix User Admin Service (1.0.3)
That first bundle you listed, 0, that is exporting useradmin, I suspect isn't actually exporting anything. The second one is exporting a completely unrelated package. The third one is exporting the actual useradmin API. And the fourth one is exporting the apache felix specific classes.
Karaf doesn't actually contain the useradmin package anywhere in the standard download.
apache-karaf-2.3.3 sartrip -> gfind -iname \*jar | parallel unzip -l {} | grep userad
0 01-23-13 14:59 org/osgi/jmx/service/useradmin/
4462 01-23-13 14:59 org/osgi/jmx/service/useradmin/UserAdminMBean.class
822 01-23-13 14:59 org/osgi/jmx/service/useradmin/packageinfo
0 02-08-13 11:24 org/apache/aries/jmx/useradmin/
12187 02-08-13 11:24 org/apache/aries/jmx/useradmin/UserAdmin.class
1828 02-08-13 11:24 org/apache/aries/jmx/useradmin/UserAdminMBeanHandler.class
That means you must install the a bundle containing the useradmin API, either by installing the OSGI compendium API bundle or building your own JAR containing just the parts you want (org.osgi.service.useradmin).
EDIT:
I'll also point out that the not-yet-released version of apache felix useradmin will contain the org.osgi.service.useradmin (as it should!) meaning eventually your dependency on the compendium API jar will go away. https://github.com/apache/felix/blob/trunk/useradmin/useradmin/pom.xml#L81
I have strange problem with Servicemix version Fuse ESB 4.4.1.
Sometimes the part of the commands will not load and be not available. Usually this happens with quite often used by me command, grep. This looks as following:
karaf#root> list | grep spring
Command not found: grep
It seems to be random, restart usually helps. With previous versions of Fuse ESB it happened sometimes, but quite rare, now it happens quite often. Can someone help, what is causing the problem?
Perhaps completely unrelated, but I've encountered a number of boot-time race conditions in Karaf and its dependencies. Most importantly, this one that I filed:
https://issues.apache.org/jira/browse/KARAF-910
"Race between FeatureService and ConfigAdmin for resolving mvn: URLs?"
That particular defect only manifests if you have some non-standard settings for pax-url-mvn, but it's a symptom of the general problem that configadmin applies settings asynchronously, so it matters if the configadmin thread is faster or slower than the main OSGi bundle-starting thread.
I have not seen any Karaf Command problems related to that race, but my problem is superficially similar in that some bundle services randomly don't start.
The 'grep' command has a full name - shell:grep. You might try that to see if e.g. another command has been installed with the same short (unqualified) name and it's getting confused.
The other possibility is that the bundle that provides the grep service has stopped, possibly by accident.
osgi:list -t 0 -s
will show you a list of all the bundles by symbolic name, which includes this one: (the number may be different):
[ 18] [Active ] [Created ] [ 30] org.apache.karaf.shell.commands (2.2.3)
karaf#root> osgi:stop 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
Command not found: grep
karaf#root> osgi:start 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
shell:grep
As for why that bundle is being stopped -- maybe something (or someone) is explicitly stopping it? Or it's being stopped by accident?