Here is a snippet from the log that might be relevant
2016-09-08 21:52:42,941 | INFO | ool-188-thread-1 | FeaturesServiceImpl
| 11 - org.apache.karaf.features.core - 4.0.5 | Changes to perform:
2016-09-08 21:52:42,945 | INFO | ool-188-thread-1 | FeaturesServiceImpl
|
Here's another series of errors that occurs inconsistently at startup with
Karaf 4.0.5
karaf@root>ERROR: Bundle org.eclipse.jetty.plus [157] Error starting
mvn:org.eclipse.jetty/jetty-plus/9.2.15.v20160210
(org.osgi.framework.BundleException: Unable to resolve
org.eclipse.jetty.plus [157](R 157.0)
I'm running into this error occasionally when starting some customer features
in Karaf 4.0.5
ERROR: Bundle com.trusphere.auth.key-mgr-prov [68] Error starting
mvn:com.trusphere.auth/key-mgr-prov/2.0.1.SNAPSHOT
(org.osgi.framework.BundleException: Resolver hook service unregistered
during resolve.)
Hi,
IMO the username/password stored in etc/users.properties should be only used on
the jaas server side with PropertiesLoginModule, that’s the backend storage for
server side thing, so the bin/client which basically is a ssh client should
never rely on it by default. Although we ship both clie
Hi,
I'd like to announce a small project I've just released, Etcetera.
Typically, OSGi configuration files are limited to the filesystem and don't
support directory overlaying. Etcetera addresses this by allowing to stack
arbitrary storage backends to read and write configuration.
My main motiva
When I install my kar i see empty output and this in log:
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=lorien-niichi;
type=karaf.feature; version="[0.1.0.SNAPSHOT,0.1.0.SNAPSHOT]";
filter:="(&(osgi.identity=lorien-ni
I just updated from 4.0.5 to 4.0.6 and some automated scripts I had which use
the bin/client shell script are now no longer working.
I traced the issue down to https://issues.apache.org/jira/browse/KARAF-3859
The previous functionality let me specify the user with the -u flag, and then
it would
OK, I guess I figured out what my issue is/was. I thought the default values
were returned if a specified property doesn’t exist in the .cfg file OR if the
property does exist but doesn’t have a value. Experimentation shows me that the
latter isn’t true.
I assume this is proper behavior.
From
Hi Jens,
It looks that some interpolations have been performed on Jenkins (during
nightly build).
Let me check.
Thanks
Regards
JB
On 09/08/2016 05:15 PM, Jens Offenbach wrote:
Hallo,
I am working with the current snapshot of Karaf 4.1
(https://repository.apache.org/content/groups/snapshots
Hallo,
I am working with the current snapshot of Karaf 4.1
(https://repository.apache.org/content/groups/snapshots-group/org/apache/karaf/apache-karaf/4.1.0-SNAPSHOT/apache-karaf-4.1.0-20160817.085104-183.tar.gz).
There seems to be a problem in the shell scripts "/bin/shell", "/bin/start",
"/bin
Thanks so much. Of course, I neglected to try the one thing that is actually
somewhat obvious in hindsight.
-Original Message-
From: Oliver Lietz [mailto:apa...@oliverlietz.de]
Sent: Thursday, September 08, 2016 8:39 AM
To: user@karaf.apache.org
Subject: Re: configuration property type w
On Friday 02 September 2016 14:26:30 Leschke, Scott wrote:
> Can one/how does one define a value in a property file such that the value
> is converted to an array of values (specifically a String[]) when using
> Configuration Property Types? I've been gradually moving my blueprint code
> over to C
12 matches
Mail list logo
