Re: Branding properties file not picked up by Karaf client?

[Jean-Baptiste Onofré]

For the client, you have to use branding-ssh.properties.

Regards
JB



On Sep 21, 2016, 12:38, at 12:38, afbagwe  wrote:
>We are using 4.0.6.
>
>So I can take a pristine tar.gz of Karaf 4.0.6, drop my
>branding.properties
>in the etc folder and get it to show up when I run the server in
>console
>mode. However if I do:
>
>./start
>./client
>(enter default Karaf password)
>
>the console comes up with the default branding instead of the one I've
>dropped into the etc folder.
>
>
>
>
>--
>View this message in context:
>http://karaf.922171.n3.nabble.com/Branding-properties-file-not-picked-up-by-Karaf-client-tp4048143p4048145.html
>Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Branding properties file not picked up by Karaf client?

[afbagwe]

We are using 4.0.6.

So I can take a pristine tar.gz of Karaf 4.0.6, drop my branding.properties
in the etc folder and get it to show up when I run the server in console
mode. However if I do:

./start
./client
(enter default Karaf password)

the console comes up with the default branding instead of the one I've
dropped into the etc folder.




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Branding-properties-file-not-picked-up-by-Karaf-client-tp4048143p4048145.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Branding properties file not picked up by Karaf client?

[Jean-Baptiste Onofré]

Hi Allen,

which Karaf version ?

I fixed ssh branding recently (Karaf 4.0.6).

Regards
JB

On 09/21/2016 07:14 PM, afbagwe wrote:

We've recently switched to using the branding.properties file in the etc
folder which has worked great so far. However when we start Karaf server as
a background process and attempt to connect with the client is still uses
the default Karaf branding page for the console interface instead of our
own. Is there some additional setting we have overlooking and need to set? I
couldn't find anything mentioned in the online documentation.

Thanks,
Allen



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Branding-properties-file-not-picked-up-by-Karaf-client-tp4048143.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Branding properties file not picked up by Karaf client?

[afbagwe]

We've recently switched to using the branding.properties file in the etc
folder which has worked great so far. However when we start Karaf server as
a background process and attempt to connect with the client is still uses
the default Karaf branding page for the console interface instead of our
own. Is there some additional setting we have overlooking and need to set? I
couldn't find anything mentioned in the online documentation.

Thanks,
Allen



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Branding-properties-file-not-picked-up-by-Karaf-client-tp4048143.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Hot deploy priority on first start up?

[afbagwe]

JIRA ticket here. Thanks!

https://issues.apache.org/jira/browse/KARAF-4723


Guillaume Nodet-2 wrote
> Could you raise a JIRA for that please ?
> I think I've just unwillingly reproduced the issue and I have a fix for
> it.
> 
> 2016-09-10 0:51 GMT+02:00 afbagwe 

> afbagwe@

> :
> 
>> I've confirmed that
>>
>> featuresBootAsynchronous=false
>> felix.fileinstall.active.level = 80
>>
>> are indeed the settings that are being used. Oddly enough when I ran it
>> again I couldn't reproduce the error on my build environment. However
>> when
>> I
>> set up the same deployment method in a Docker container, it occurred
>> again.
>> Here is the console output showing the problem:
>>
>> admin@witchdoctor>bundle:list
>> START LEVEL 100 , List Threshold: 50
>>  ID | State | Lvl | Version | Name
>> -
>>  10 | Installed |  80 | 2.1.0   | Framework Library: Core
>>  11 | Installed |  80 | 0.1.0   | nik-hello-world
>>  12 | Active|  50 | 2.6.3   | Jackson-annotations
>>  13 | Active|  50 | 2.6.3   | Jackson-core
>>  14 | Active|  50 | 2.6.3   | jackson-databind
>>  15 | Active|  50 | 2.6.3   | Jackson-JAXRS-base
>>  16 | Active|  50 | 2.6.3   | Jackson-JAXRS-JSON
>>  17 | Active|  50 | 2.6.3   | Jackson-module-JAXB-annotations
>>  22 | Active|  50 | 2.0.1   | javax.ws.rs-api
>>  37 | Active|  50 | 2.16.3  | camel-blueprint
>>  38 | Active|  50 | 2.16.3  | camel-catalog
>>  39 | Active|  50 | 2.16.3  | camel-commands-core
>>  40 | Active|  50 | 2.16.3  | camel-core
>>  41 | Active|  50 | 2.16.3  | camel-cxf
>>  42 | Active|  50 | 2.16.3  | camel-cxf-transport
>>  43 | Active|  50 | 2.16.3  | camel-jackson
>>  44 | Active|  50 | 2.16.3  | camel-mina2
>>  45 | Active|  50 | 2.16.3  | camel-spring
>>  46 | Active|  50 | 2.16.3  | camel-karaf-commands
>>  47 | Active|  50 | 1.10.0  | Apache Commons Codec
>>  48 | Active|  50 | 2.4.0   | Commons IO
>>  49 | Active|  50 | 3.4.0   | Apache Commons Lang
>>  94 | Active|  50 | 2.0.9   | Apache MINA Core
>> 149 | Installed |  80 | 0.1 | standalone
>> admin@witchdoctor>bundle:diag 10
>> Framework Library: Core (10)
>> 
>> Status: Installed
>> Unsatisfied Requirements:
>>
>>
>> admin@witchdoctor>bundle:start 10
>> Error executing command: Error executing command on bundles:
>> Error starting bundle 10: Unable to resolve fwk-lib-core [10](R
>> 10.0):
>> missing requirement [fwk-lib-core [10](R 10.0)] osgi.wiring.package;
>> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
>> version>=1.10.0)(!(version>=2.0.0)))
>> Unresolved requirements: [[fwk-lib-core [10](R 10.0)]
>> osgi.wiring.package;
>> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
>> version>=1.10.0)(!(version>=2.0.0)))]
>>
>> -
>>
>> As you can see, bundle IDs 10 and 11 are my own jar. Bundle ID 149 is my
>> blueprint file. For whatever reason when I run diag on bundle 10 is
>> doesn't
>> list any unsatisfied requirements, but if I try to start it is says I'm
>> missing my dependency on Apache Commons Codec. That bundle (ID 47) is
>> active
>> and a part of the boot features we have installed. My other bundles fail
>> to
>> start for similar reasons.
>>
>> However if I start up my Karaf instance first and then put the two jars
>> and
>> blueprint into the deploy folder, everything activates correctly with no
>> missing dependencies.
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.
>> com/Hot-deploy-priority-on-first-start-up-tp4047948p4047953.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
> 
> 
> 
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
> 
> Email: 

> gnodet@

> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/





--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hot-deploy-priority-on-first-start-up-tp4047948p4048142.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RE: scr:details command

[Leschke, Scott]

I resolved the issue that was causing the misleading display but I’ll spend a 
little time to see if I can recreate it. No promises but I’ll try.

From: Guillaume Nodet [mailto:gno...@apache.org]
Sent: Tuesday, September 20, 2016 1:43 PM
To: user 
Subject: Re: scr:details command

Could you provide the full command output please ?

2016-09-20 18:13 GMT+02:00 Leschke, Scott 
>:
This is the Karaf scr:details command.  It also says that the reference is 
mandatory (Optional : mandatory) and scr:info says Cardinality: 1..1.

So I guess I’m still at how a mandatory reference be unbound but still be 
satisfied?  Hmmm.

From: David Jencks 
[mailto:david.a.jen...@gmail.com]
Sent: Tuesday, September 20, 2016 11:05 AM
To: user@karaf.apache.org
Subject: Re: scr:details command

either
- minimum cardinality 0, so it’s always satisfied
- the component is not satisfied for some other reason so nothing is bound to 
any reference.

I think this is the karaf scr command so I might be wrong about the meaning.

david jencks

On Sep 20, 2016, at 8:33 AM, Leschke, Scott 
> wrote:

I’m confused. What does it mean if scr:details says:

State   : satisfied
Service Reference : No Services bound

How can a reference be satisfied if it’s not bound?




--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Hot deploy priority on first start up?

[Guillaume Nodet]

Could you raise a JIRA for that please ?
I think I've just unwillingly reproduced the issue and I have a fix for it.

2016-09-10 0:51 GMT+02:00 afbagwe :

> I've confirmed that
>
> featuresBootAsynchronous=false
> felix.fileinstall.active.level = 80
>
> are indeed the settings that are being used. Oddly enough when I ran it
> again I couldn't reproduce the error on my build environment. However when
> I
> set up the same deployment method in a Docker container, it occurred again.
> Here is the console output showing the problem:
>
> admin@witchdoctor>bundle:list
> START LEVEL 100 , List Threshold: 50
>  ID | State | Lvl | Version | Name
> -
>  10 | Installed |  80 | 2.1.0   | Framework Library: Core
>  11 | Installed |  80 | 0.1.0   | nik-hello-world
>  12 | Active|  50 | 2.6.3   | Jackson-annotations
>  13 | Active|  50 | 2.6.3   | Jackson-core
>  14 | Active|  50 | 2.6.3   | jackson-databind
>  15 | Active|  50 | 2.6.3   | Jackson-JAXRS-base
>  16 | Active|  50 | 2.6.3   | Jackson-JAXRS-JSON
>  17 | Active|  50 | 2.6.3   | Jackson-module-JAXB-annotations
>  22 | Active|  50 | 2.0.1   | javax.ws.rs-api
>  37 | Active|  50 | 2.16.3  | camel-blueprint
>  38 | Active|  50 | 2.16.3  | camel-catalog
>  39 | Active|  50 | 2.16.3  | camel-commands-core
>  40 | Active|  50 | 2.16.3  | camel-core
>  41 | Active|  50 | 2.16.3  | camel-cxf
>  42 | Active|  50 | 2.16.3  | camel-cxf-transport
>  43 | Active|  50 | 2.16.3  | camel-jackson
>  44 | Active|  50 | 2.16.3  | camel-mina2
>  45 | Active|  50 | 2.16.3  | camel-spring
>  46 | Active|  50 | 2.16.3  | camel-karaf-commands
>  47 | Active|  50 | 1.10.0  | Apache Commons Codec
>  48 | Active|  50 | 2.4.0   | Commons IO
>  49 | Active|  50 | 3.4.0   | Apache Commons Lang
>  94 | Active|  50 | 2.0.9   | Apache MINA Core
> 149 | Installed |  80 | 0.1 | standalone
> admin@witchdoctor>bundle:diag 10
> Framework Library: Core (10)
> 
> Status: Installed
> Unsatisfied Requirements:
>
>
> admin@witchdoctor>bundle:start 10
> Error executing command: Error executing command on bundles:
> Error starting bundle 10: Unable to resolve fwk-lib-core [10](R
> 10.0):
> missing requirement [fwk-lib-core [10](R 10.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
> version>=1.10.0)(!(version>=2.0.0)))
> Unresolved requirements: [[fwk-lib-core [10](R 10.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.commons.codec.binary)(
> version>=1.10.0)(!(version>=2.0.0)))]
>
> -
>
> As you can see, bundle IDs 10 and 11 are my own jar. Bundle ID 149 is my
> blueprint file. For whatever reason when I run diag on bundle 10 is doesn't
> list any unsatisfied requirements, but if I try to start it is says I'm
> missing my dependency on Apache Commons Codec. That bundle (ID 47) is
> active
> and a part of the boot features we have installed. My other bundles fail to
> start for similar reasons.
>
> However if I start up my Karaf instance first and then put the two jars and
> blueprint into the deploy folder, everything activates correctly with no
> missing dependencies.
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Hot-deploy-priority-on-first-start-up-tp4047948p4047953.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Create and manager an instance using Jolokia

[Jean-Baptiste Onofré]

Hi Tom,

Jolokia use the http service port. So, when you install jolokia, it 
installs http feature.


To change the port, you have to provision org.ops4j.pax.web.cfg file 
containing the port property in the etc folder of the instance, or using 
config layer before installing the http/jolokia feature.


Regards
JB

On 09/21/2016 03:23 PM, t...@quarendon.net wrote:

How do I create and then manage a new instance using jolokia?

I can execute the commands on my root instance to create and start a new
instance fine. On create I specify that I want "jolokia" as a feature.

Fundamentally, in order to manage the second instance I have to connect directly
to it don't I? This is fine with the RMI, as I get the opportunity to set the
ports on instance creation. Despite the instance name being in the Mbean object
names (the "name=[instance]" bit), I can't connect to the root instance and
control the second instance simply by setting "name=second" (doesn't work
anyway).

So I'm going to need to set the HTTP port on the second instance to something
other than default, otherwise I won't be able to connect, the second instance
will attempt to bind to 8181, and then fail.

I seem to have two ways I might be able to influence the new instance.
The first is that I have the opportunity to pass in startup options when the
instance is started. Can I influence the port that way? These are presumably
java system options, but I'm not aware you can set OSGi configuration from
system options can you? Or indeed that the HTTP service will pick up a specific
system option?

The second opportunity seems to be that on creating the instance, I can pass in
feature URLs and features to install. Presumably I could pass in the URL of a
feature XML file that contains a feature that just has configuration settings in
it. But in order to do this, I have to have created that feature XML file though
and have in a location that is addressable by a URL from the machine on which
Karaf is running, I can't just pass the information in easily.

Are there any other ways of achieving this that I've missed?

Thanks for any input.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Create and manager an instance using Jolokia

[tom]

How do I create and then manage a new instance using jolokia?

I can execute the commands on my root instance to create and start a new
instance fine. On create I specify that I want "jolokia" as a feature.

Fundamentally, in order to manage the second instance I have to connect directly
to it don't I? This is fine with the RMI, as I get the opportunity to set the
ports on instance creation. Despite the instance name being in the Mbean object
names (the "name=[instance]" bit), I can't connect to the root instance and
control the second instance simply by setting "name=second" (doesn't work
anyway).

So I'm going to need to set the HTTP port on the second instance to something
other than default, otherwise I won't be able to connect, the second instance
will attempt to bind to 8181, and then fail.

I seem to have two ways I might be able to influence the new instance. 
The first is that I have the opportunity to pass in startup options when the
instance is started. Can I influence the port that way? These are presumably
java system options, but I'm not aware you can set OSGi configuration from
system options can you? Or indeed that the HTTP service will pick up a specific
system option?

The second opportunity seems to be that on creating the instance, I can pass in
feature URLs and features to install. Presumably I could pass in the URL of a
feature XML file that contains a feature that just has configuration settings in
it. But in order to do this, I have to have created that feature XML file though
and have in a location that is addressable by a URL from the machine on which
Karaf is running, I can't just pass the information in easily.

Are there any other ways of achieving this that I've missed?

Thanks for any input.

Re: Deploying an application from jenkins for test

[tom]

Achim,Thanks.

I'm trying to use mvn, as it does seem the best option. If I can get it to do
what I want though.
What I'm trying to work out is how to ensure that I get exactly the bundle
that's just been published, and nothing gets cached.

I'm publishing SNAPSHOT builds to our artifactory repository.
With the default configuration, I don't get the latest snapshot. So I:

install the feature
Update the code.
Rebuild.
Publish
uninstall, then reinstall the feature.

I get the same bundle again.
Now I don't know anything about maven works, but there seems to be an "update
policy" that by default is "daily". The implication of this is that if I ran
this cycle over two days I might get what I want.

The PAX URL code seems to have a "globalUpdatePolicy" configuration. I set that
to "always", and now I get a complaint from aether about not being able to
resolve the artifact:

Could not find artifact
simple-osgi:simle.osgi.command:jar:1.0.0-20160921.072458-1 in
artifactory-snapshot(repository URL)
at
shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)[7:org.ops4j.pax.url.mvn:2.4.7]
at
shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)[7:org.ops4j.pax.url.mvn:2.4.7]
at
shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)[7:org.ops4j.pax.url.mvn:2.4.7]
at
shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)[7:org.ops4j.pax.url.mvn:2.4.7]
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:650)[7:org.ops4j.pax.url.mvn:2.4.7]
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)[7:org.ops4j.pax.url.mvn:2.4.7]
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:576)[7:org.ops4j.pax.url.mvn:2.4.7]
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:550)[7:org.ops4j.pax.url.mvn:2.4.7]
at
org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:34)[8:org.apache.karaf.features.core:4.0.6]



The one in the artifactory is now 073344 instead.

So I don't understand what's going on here. Setting "globalUpdatePolicy" seems
to have said "ignore the cached artefacts and go get them again from the
remote", but what it doesn't seem to have said is "check for the latest SNAPSHOT
version", so it's still trying to download the version that it worked out last
time. 


As I say, my knowledge of Maven is minimal at best.
There must be a way of doing this though isn't there? I mean, convince it
somehow to just install whatever is latest on out artefactory repository? I get
the caching thing when you're dealing with release versions, but in this
environment, snapshots ought to not be cached, and attempting to get version
"1.0.0-SNAPSHOT" ought to just go and figure out what the latest version is and
download it (you can cache once you've resolved the SNAPSHOT into its actual
unique version, but not before).

Any ideas?

Thanks.

Re: Deploying an application from jenkins for test

[Achim Nierbeck]

Hi,

usually I use maven as the "transport" it's a much better integration into
the CI/CD pipeline.
So what I've given you as sample is optimized for exactly this.

regards, Achim

[1] -
http://image.slidesharecdn.com/microservices-osgi-running-with-apache-karaf-151001101049-lva1-app6891/95/microservices-osgirunningwithapachekaraf-35-638.jpg?cb=1443694516

2016-09-20 9:22 GMT+02:00 :

> > you can use Pax Exam[1] for that and start Karaf embedded, this will give
> > you a clean state for every run.
>
> Initially I want to do it for testing, but I then want to deploy a
> "snapshot"
> and "release" version of the actual application for general internal demo
> use. I
> currently already have an integration test suite, but what it doesn't test
> is
> the deployment into karaf, so I want to deploy it for testing in a way
> that is
> as close to the real thing as possible.
>
> > The other way would be to have a Karaf with Jolokia running and deploy
> via
> > JMX, I once created a sample for that [2].
>
> As I say, my question was really one of what the transport is for the
> bundles.
> One way of the other I invoke the equivalent of "feature:add-repo", then
> "feature:install", my question is what are the URLs, where does karaf
> actually
> pull stuff from. To use mvn repositories I need to find a way of turning
> off the
> caching, which so far I've failed to do. Pushing the files on to the remote
> machine using SCP and then addressing them with "file:///" URLs seems
> another
> way, but it seems over complicated to push them. Addressing the artifacts
> in
> jenkins directly is another way, but it seems like I'm going to have to
> write
> something bespoke to create a feature repository with the correct URLs in
> from
> some kind of template (substituting the correct build number in all of the
> URLs).
>
> Just hoping there might be a known best way to do this kind of thing, save
> me
> figuring it out!
>
> Thanks.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master