Re: Log4j NTEventLogAppender in Karaf 4.0.5

[Achim Nierbeck]

Hi Bengt,

I'll try to find out if one of the bundles in that feature depends on
log4j2 ... but I'm not aware of such a dependency.

Your suspicion about dynamic loading of DLLs is correct in case of the
location of the dll is inside of a bundle and does have dependencies to
another dll. If it's a dll loaded via the root classloader that shouldn't
be of an issue.

regards, Achim


2016-07-04 16:04 GMT+02:00 Bengt Rodehav :

> Another theory: Looking at the stack trace this seems to be triggered by a
> configuration update. Could the problem be that Pax-logging is trying to
> load the DLL again and failing since it is already loaded? Perhaps the
> initial load works but subsequent configuration updates does not?
>
> I tried to verify this...
>
> After successful start of Karaf (after step 9 in my previous post), I edit
> org.ops4j.pas.logging.cfg (by changing the root logger between INFO and
> DEBUG). This causes no error.
>
> But after having installed feature pax-jetty (after step 10 in my previous
> post), every change in org.ops4j.pas.logging.cfg causes the same error to
> appear (the stack trace included in my previous post).
>
> It's as if installing the pax-jetty feature takes gives control of
> org.ops4j.pas.logging.cfg to someone who cannot load the DLL. I have no
> idea how this could happen.
>
> Anyone else has an idea?
>
> /Bengt
>
>
>
>
>
>
>
> /Bengt
>
> 2016-07-04 15:51 GMT+02:00 Bengt Rodehav :
>
>> A theory: Could one of the bundles installed by feature pax-jetty be
>> using log4j 2.x directly without using Pax-logging? If so, would it too try
>> to read the log4j configuration file? I guess it would fail to load the DLL
>> since it is probably not compatible with log4j 2.x.
>>
>> Could this happen? If so, how can I find out which bundle?
>>
>> /Bengt
>>
>> 2016-07-04 15:15 GMT+02:00 Bengt Rodehav :
>>
>>> Back to the Karaf mailing list
>>>
>>> I can actually get this problem on a standard vanilla Karaf 4.0.5. It
>>> seems to be triggered when installing the feature pax-jetty.
>>>
>>> *1. Install standard Karaf 4.0.5*
>>>
>>> *2. Replace org.ops4j.pax.logging.cfg with the following:*
>>>
>>> log4j.rootLogger=INFO, stdout
>>>
>>> # CONSOLE appender
>>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p |
>>> %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
>>> log4j.appender.stdout.threshold=ERROR
>>>
>>> # Windows event log
>>> log4j.appender.nteventlog=org.apache.log4j.nt.NTEventLogAppender
>>> log4j.appender.nteventlog.source=Test source
>>> log4j.appender.nteventlog.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.nteventlog.layout.ConversionPattern=Time:
>>> %d{ISO8601}%n%nSeverity: %p%n%nThread: %t%n%n%m%n
>>> log4j.appender.nteventlog.threshold=DEBUG
>>>
>>> *3. Start Karaf: "bin\karaf clean"*
>>>
>>> This should work.
>>>
>>> *4. Exit Karaf*
>>>
>>> *5. Change the root looger line to:*
>>>
>>> log4j.rootLogger=INFO, stdout, nteventlog
>>>
>>> *6. Start Karaf again*
>>>
>>> I get the following error:
>>>
>>> 2016-07-04 15:05:39,534 | ERROR | s4j.pax.logging) | configadmin
>>>  | ?? | [org.osgi.service.log.LogService,
>>> org.knopflerfish.service.log.LogService,
>>> org.ops4j.pax.logging.PaxLoggingService,
>>> org.osgi.service.cm.ManagedService, id=12,
>>> bundle=6/mvn:org.ops4j.pax.logging/pax-logging-service/1.8.5]: Unexpected
>>> problem updating configuration org.ops4j.pax.logging
>>> java.lang.UnsatisfiedLinkError: no NTEventLogAppender in
>>> java.library.path
>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>> at java.lang.System.loadLibrary(System.java:1122)
>>> at
>>> org.apache.log4j.nt.NTEventLogAppender.(NTEventLogAppender.java:179)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>> at
>>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>> at java.lang.Class.newInstance(Class.java:442)
>>> at
>>> org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:336)
>>> at
>>> org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:123)
>>> at
>>> org.apache.log4j.PaxLoggingConfigurator.parseAppender(PaxLoggingConfigurator.java:97)
>>> at
>>> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:735)
>>> at
>>> org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:615)
>>> at
>>> 

Re: How to secure Karaf

[Jean-Baptiste Onofré]

By default bin/client tries (in this order):
1. to read etc/users.properties when possible
2. to use karaf/karaf
3. to use -u and prompt for the password

bin/client is a SSH client (written in Java). The host.key is the same 
file as for SSH and containing the trusted hosts (you also have 
.sshkaraf/known_hosts for that).


Regards
JB

On 07/06/2016 08:50 PM, Elliot Huntington wrote:

This makes sense. So, I gather from this explanation that the container
is secure (in as much as the default password has been changed and the
default private key has been deleted) but the bin/client command will
still use whatever password is specified in the etc/users.properties
file? If so, this would explain why on 4.0.5 bin/client was able to
successfully log into the container without having to explicitly specify
a password. But if this is true, then I'm still curious: what is the
purpose of the etc/host.key file that is created by the container (or
maybe the bin/client command) if the etc/keys.properties file is
missing? What is the point of that file if the bin/client command is
using the password specified in etc/users.properties to connect to the
container?

On Wed, Jul 6, 2016 at 12:43 PM, Jean-Baptiste Onofré > wrote:

Previously, bin/client embedded a default key (as you can see in
etc/keys.properties). It's now disable.

However, bin/client assumes username karaf and password karaf,
that's why you don't have to provide anything.

You can change the default password in etc/users.properties.

Regards
JB

On 07/06/2016 01:16 AM, Kevin Schmidt wrote:

I just followed the instructions to secure the container and using
bin/client does now require a password and doesn't successfully
connect
to the container.  I did this with Karaf 3.0.6.  Perhaps something
changed with Karaf 4?

Kevin

On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington

>> wrote:

 I wrote a question


(http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
 on stack overflow pertaining to Christian Schneider's blog
post, How
 to hack into any default apache karaf installation


.
 After following his instructions to secure the container the
 `bin/client` command, rather than failing, appears to
create a new
 file `etc/host.key` and successfully connects to the
container. This
 was unexpected according to the blog post.

 It would be helpful if someone would answer this question
on stack
 overflow.

 Thanks,
 Elliot



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




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

Re: How to secure Karaf

[Elliot Huntington]

This makes sense. So, I gather from this explanation that the container is
secure (in as much as the default password has been changed and the default
private key has been deleted) but the bin/client command will still use
whatever password is specified in the etc/users.properties file? If so,
this would explain why on 4.0.5 bin/client was able to successfully log
into the container without having to explicitly specify a password. But if
this is true, then I'm still curious: what is the purpose of the
etc/host.key file that is created by the container (or maybe the bin/client
command) if the etc/keys.properties file is missing? What is the point of
that file if the bin/client command is using the password specified in
etc/users.properties to connect to the container?

On Wed, Jul 6, 2016 at 12:43 PM, Jean-Baptiste Onofré 
wrote:

> Previously, bin/client embedded a default key (as you can see in
> etc/keys.properties). It's now disable.
>
> However, bin/client assumes username karaf and password karaf, that's why
> you don't have to provide anything.
>
> You can change the default password in etc/users.properties.
>
> Regards
> JB
>
> On 07/06/2016 01:16 AM, Kevin Schmidt wrote:
>
>> I just followed the instructions to secure the container and using
>> bin/client does now require a password and doesn't successfully connect
>> to the container.  I did this with Karaf 3.0.6.  Perhaps something
>> changed with Karaf 4?
>>
>> Kevin
>>
>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
>> > wrote:
>>
>> I wrote a question
>> (
>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation
>> )
>> on stack overflow pertaining to Christian Schneider's blog post, How
>> to hack into any default apache karaf installation
>> <
>> http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation
>> >.
>> After following his instructions to secure the container the
>> `bin/client` command, rather than failing, appears to create a new
>> file `etc/host.key` and successfully connects to the container. This
>> was unexpected according to the blog post.
>>
>> It would be helpful if someone would answer this question on stack
>> overflow.
>>
>> Thanks,
>> Elliot
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: How to secure Karaf

[Jean-Baptiste Onofré]

Previously, bin/client embedded a default key (as you can see in 
etc/keys.properties). It's now disable.


However, bin/client assumes username karaf and password karaf, that's 
why you don't have to provide anything.


You can change the default password in etc/users.properties.

Regards
JB

On 07/06/2016 01:16 AM, Kevin Schmidt wrote:

I just followed the instructions to secure the container and using
bin/client does now require a password and doesn't successfully connect
to the container.  I did this with Karaf 3.0.6.  Perhaps something
changed with Karaf 4?

Kevin

On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
> wrote:

I wrote a question

(http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
on stack overflow pertaining to Christian Schneider's blog post, How
to hack into any default apache karaf installation

.
After following his instructions to secure the container the
`bin/client` command, rather than failing, appears to create a new
file `etc/host.key` and successfully connects to the container. This
was unexpected according to the blog post.

It would be helpful if someone would answer this question on stack
overflow.

Thanks,
Elliot




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

Re: How to secure Karaf

[Jean-Baptiste Onofré]

Hi Kevin,

you have to use the -k option:

-k [keyFile]specify the private keyFile location when using key 
login, need have BouncyCastle registered as security provider using this 
flag


On the Karaf side, you need bouncycastle provider and populate the 
etc/keys.properties.


It's documented there:

http://karaf.apache.org/manual/latest/#_managing_authentication_by_key

Regards
JB

On 07/06/2016 05:56 PM, Kevin Schmidt wrote:

I have a follow up question.

It is good that one can disable this feature, but if someone would like
to use this feature of bin/client to connect without a password but do
so with their own public/private key pair, how would bin/client be told
to use it?  Is that possible or is the private key built in to
org.apache.karaf.client.Main?

On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt > wrote:

I just followed the instructions to secure the container and using
bin/client does now require a password and doesn't successfully
connect to the container.  I did this with Karaf 3.0.6.  Perhaps
something changed with Karaf 4?

Kevin

On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
>
wrote:

I wrote a question

(http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
on stack overflow pertaining to Christian Schneider's blog post,
How to hack into any default apache karaf installation

.
After following his instructions to secure the container the
`bin/client` command, rather than failing, appears to create a
new file `etc/host.key` and successfully connects to the
container. This was unexpected according to the blog post.

It would be helpful if someone would answer this question on
stack overflow.

Thanks,
Elliot





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

Re: How to secure Karaf

[Kevin Schmidt]

I have not tried with 4.0.5 but will try to.

And didn't mean to hi-jack the thread, but it appears bin/client does have
a -k command line option to specify a different file with the private key
that should work.

On Wed, Jul 6, 2016 at 11:29 AM, Elliot Huntington <
elliot.hunting...@gmail.com> wrote:

> I appreciate Kevin's follow up question and am eager to know the answer to
> it myself. But I hope this separate question does not hijack this thread.
> I'm still looking for an answer to my stack overflow question.
>
> Kevin, are you able to reproduce securing the container with version
> 4.0.5. I'm going to test this with 3.0.6 to see if I get the same results
> you got.
>
> On Wed, Jul 6, 2016 at 9:56 AM, Kevin Schmidt  wrote:
>
>> I have a follow up question.
>>
>> It is good that one can disable this feature, but if someone would like
>> to use this feature of bin/client to connect without a password but do so
>> with their own public/private key pair, how would bin/client be told to use
>> it?  Is that possible or is the private key built in to
>> org.apache.karaf.client.Main?
>>
>> On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt 
>> wrote:
>>
>>> I just followed the instructions to secure the container and using
>>> bin/client does now require a password and doesn't successfully connect to
>>> the container.  I did this with Karaf 3.0.6.  Perhaps something changed
>>> with Karaf 4?
>>>
>>> Kevin
>>>
>>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
>>> elliot.hunting...@gmail.com> wrote:
>>>
 I wrote a question (
 http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
 on stack overflow pertaining to Christian Schneider's blog post, How
 to hack into any default apache karaf installation
 .
 After following his instructions to secure the container the `bin/client`
 command, rather than failing, appears to create a new file `etc/host.key`
 and successfully connects to the container. This was unexpected according
 to the blog post.

 It would be helpful if someone would answer this question on stack
 overflow.

 Thanks,
 Elliot

>>>
>>>
>>
>

Re: How to secure Karaf

[Elliot Huntington]

I appreciate Kevin's follow up question and am eager to know the answer to
it myself. But I hope this separate question does not hijack this thread.
I'm still looking for an answer to my stack overflow question.

Kevin, are you able to reproduce securing the container with version 4.0.5.
I'm going to test this with 3.0.6 to see if I get the same results you got.

On Wed, Jul 6, 2016 at 9:56 AM, Kevin Schmidt  wrote:

> I have a follow up question.
>
> It is good that one can disable this feature, but if someone would like to
> use this feature of bin/client to connect without a password but do so with
> their own public/private key pair, how would bin/client be told to use it?
> Is that possible or is the private key built in to
> org.apache.karaf.client.Main?
>
> On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt  wrote:
>
>> I just followed the instructions to secure the container and using
>> bin/client does now require a password and doesn't successfully connect to
>> the container.  I did this with Karaf 3.0.6.  Perhaps something changed
>> with Karaf 4?
>>
>> Kevin
>>
>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
>> elliot.hunting...@gmail.com> wrote:
>>
>>> I wrote a question (
>>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>>> on stack overflow pertaining to Christian Schneider's blog post, How to
>>> hack into any default apache karaf installation
>>> .
>>> After following his instructions to secure the container the `bin/client`
>>> command, rather than failing, appears to create a new file `etc/host.key`
>>> and successfully connects to the container. This was unexpected according
>>> to the blog post.
>>>
>>> It would be helpful if someone would answer this question on stack
>>> overflow.
>>>
>>> Thanks,
>>> Elliot
>>>
>>
>>
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

SIgh. I can't repro the problem that's interesting to you, and the
more CXF-ish problem  needs to be chased at CXF.


On Wed, Jul 6, 2016 at 12:29 PM, Benson Margulies  wrote:
> If I can repro it, I'll endeavor to produce.
>
>
> On Wed, Jul 6, 2016 at 12:25 PM, David Jencks  
> wrote:
>> I’m wondering what the DS implementation bundle is getting it’s Config Admin 
>> packages from in each case.
>>
>> thanks
>> david jencks
>>
>>> On Jul 6, 2016, at 9:20 AM, Benson Margulies  wrote:
>>>
>>> I can dump a bunch of wiring. But I'd have to repro the problem.
>>> which, after being quite reproducible for some time, has gone into
>>> hiding to be replaced by a different problem. Just what bundle's
>>> wiring are you interested in?
>>>
>>>
>>> On Wed, Jul 6, 2016 at 12:18 PM, David Jencks  
>>> wrote:
 There has been another report of a similar problem that I haven’t been 
 able to reproduce (outside karaf).  Does Karaf provide any way of looking 
 at the bundle wiring?  I’d like to see how the DS bundle is wired in the 
 working and non working cases.  I’m wondering if in the non working case 
 DS gets wired correctly to config admin.

 thanks
 david jencks

> On Jul 6, 2016, at 9:10 AM, Benson Margulies  wrote:
>
> com.basistech.worker.service.cfg exists.
>
> And when I stopped and started karaf, the component got itself activated.
>
>
>
> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
> wrote:
>> You have configuration policy require and there is no component 
>> configuration shown, so the configuration is missing.
>>
>> If at least one matching configuration were available to DS you’d see 
>> one component configuration for each configuration, and then you could 
>> tell if the references were satisfied or not from the references section 
>> of the component configuration.
>>
>> thanks
>> david jencks
>>
>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies  
>>> wrote:
>>>
>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>> clues?
>>>
>>>
>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>> Component Details
>>> Name: com.basistech.ws.worker.service.WorkerService
>>> State   : UNSATISFIED
>>> Properties  :
>>>  service=worker
>>> References
>>>
>>> -
>>>
>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>> Component Description:
>>> Name: com.basistech.ws.worker.service.WorkerService
>>> Default State: enabled
>>> Activation: immediate
>>> Configuration Policy: require
>>> Activate Method: activate
>>> Deactivate Method: deactivate
>>> Modified Method: -
>>> Configuration Pid: [com.basistech.worker.service]
>>> Services:
>>>com.basistech.ws.common.WebServiceAvailable
>>> Service Scope: singleton
>>> Reference: CxfTransport
>>>  Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>  Cardinality: 1..1
>>>  Policy: static
>>>  Policy option: reluctant
>>>  Reference Scope: bundle
>>> Reference: Metrics
>>>  Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>  Cardinality: 1..1
>>>  Policy: static
>>>  Policy option: reluctant
>>>  Reference Scope: bundle
>>> Reference: Worker
>>>  Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>  Cardinality: 1..1
>>>  Policy: static
>>>  Policy option: reluctant
>>>  Reference Scope: bundle
>>> Properties:
>>>  service = worker
>>

>>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

If I can repro it, I'll endeavor to produce.


On Wed, Jul 6, 2016 at 12:25 PM, David Jencks  wrote:
> I’m wondering what the DS implementation bundle is getting it’s Config Admin 
> packages from in each case.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 9:20 AM, Benson Margulies  wrote:
>>
>> I can dump a bunch of wiring. But I'd have to repro the problem.
>> which, after being quite reproducible for some time, has gone into
>> hiding to be replaced by a different problem. Just what bundle's
>> wiring are you interested in?
>>
>>
>> On Wed, Jul 6, 2016 at 12:18 PM, David Jencks  
>> wrote:
>>> There has been another report of a similar problem that I haven’t been able 
>>> to reproduce (outside karaf).  Does Karaf provide any way of looking at the 
>>> bundle wiring?  I’d like to see how the DS bundle is wired in the working 
>>> and non working cases.  I’m wondering if in the non working case DS gets 
>>> wired correctly to config admin.
>>>
>>> thanks
>>> david jencks
>>>
 On Jul 6, 2016, at 9:10 AM, Benson Margulies  wrote:

 com.basistech.worker.service.cfg exists.

 And when I stopped and started karaf, the component got itself activated.



 On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
 wrote:
> You have configuration policy require and there is no component 
> configuration shown, so the configuration is missing.
>
> If at least one matching configuration were available to DS you’d see one 
> component configuration for each configuration, and then you could tell 
> if the references were satisfied or not from the references section of 
> the component configuration.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 8:52 AM, Benson Margulies  
>> wrote:
>>
>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>> clues?
>>
>>
>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>> Component Details
>> Name: com.basistech.ws.worker.service.WorkerService
>> State   : UNSATISFIED
>> Properties  :
>>  service=worker
>> References
>>
>> -
>>
>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>> Component Description:
>> Name: com.basistech.ws.worker.service.WorkerService
>> Default State: enabled
>> Activation: immediate
>> Configuration Policy: require
>> Activate Method: activate
>> Deactivate Method: deactivate
>> Modified Method: -
>> Configuration Pid: [com.basistech.worker.service]
>> Services:
>>com.basistech.ws.common.WebServiceAvailable
>> Service Scope: singleton
>> Reference: CxfTransport
>>  Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>> Reference: Metrics
>>  Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>> Reference: Worker
>>  Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>> Properties:
>>  service = worker
>
>>>
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

It's the same karaf. I fear that in Karaf 4.0.4 there is a coin being
flipped to decide which set of gogo commands to use. I do not know how
to get Karaf to use the real SCR command and not its own by changing
what I type, maybe there's a way. It's another bundle start order
business.



On Wed, Jul 6, 2016 at 12:24 PM, David Jencks  wrote:
> Is that the same karaf?  The first scr:list looks like the new format and the 
> second like the really old format.  There have been some shenanigans where 
> karaf thought they knew better than DS how to write a gogo command, so maybe 
> only the command is the wrong one rather than the DS implementation, but 
> something appears really different on restart.
>
> david jencks
>
>> On Jul 6, 2016, at 9:18 AM, Benson Margulies  wrote:
>>
>> Here's how I got into this.
>>
>> I have this Karaf assembly. If I start if just after it is built, it
>> works fine. If I stop and restart it, it fails, because the CXF HTTP
>> transport does not start in time.
>>
>> So, I added @References to ensure that the transport starts first.
>> Then, I hit the problem reported in this thread: a component refuses
>> to start for lack of a configuration pid whose file is sitting right
>> there.
>>
>> If I delete the karaf data directory again, everything is fine.
>>
>> scr:list goes:
>>
>> karaf@root>scr:list
>> BundleId Component Name Default State
>>Component Id State  PIDs (Factory PID)
>> [  44]   com.basistech.ws.common.InitializeS3FSService  enabled
>>[   1] [active  ]
>> [  44]   com.basistech.ws.common.metrics.MetricsRegistryServiceImpl  enabled
>>[   2] [active  ] com.basistech.ws.metrics
>> [  45]   com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
>> enabled
>>[  19] [active  ] com.basistech.ws.transport.http
>> ...
>>
>>
>> If I stop and start again,
>>
>> scr:list switches format to:
>>
>> karaf@root>scr:list
>> ID | State   | Component Name
>> ---
>> -1 | UNSATISFIED |
>> com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker
>> 1  | ACTIVE  | com.basistech.ws.common.InitializeS3FSService
>> 2  | ACTIVE  | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl
>> 3  | ACTIVE  |
>> com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
>> 4  | ACTIVE  |
>> com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver
>> 5  | ACTIVE  | com.basistech.ws.embeddedworker.impl.EmbeddedTransport
>> 6  | ACTIVE  | com.basistech.ws.usage.impl.LocalUsageTracker
>> ...
>>
>> (That first component is supposed to be unsatisfied) All my components
>> appear to be alive.
>>
>> and
>>
>> But a swath of my CXF services stop working, even though their
>> components are activated and they have made the call to start the
>> service.
>>
>>
>> On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies  
>> wrote:
>>> com.basistech.worker.service.cfg exists.
>>>
>>> And when I stopped and started karaf, the component got itself activated.
>>>
>>>
>>>
>>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
>>> wrote:
 You have configuration policy require and there is no component 
 configuration shown, so the configuration is missing.

 If at least one matching configuration were available to DS you’d see one 
 component configuration for each configuration, and then you could tell if 
 the references were satisfied or not from the references section of the 
 component configuration.

 thanks
 david jencks

> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
>
> Folks, I have a service that isn't starting, and  I cannot see why. Any 
> clues?
>
>
> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
> Component Details
> Name: com.basistech.ws.worker.service.WorkerService
> State   : UNSATISFIED
> Properties  :
>   service=worker
> References
>
> -
>
> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
> Component Description:
> Name: com.basistech.ws.worker.service.WorkerService
> Default State: enabled
> Activation: immediate
> Configuration Policy: require
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [com.basistech.worker.service]
> Services:
> com.basistech.ws.common.WebServiceAvailable
> Service Scope: singleton
> Reference: CxfTransport
>   Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>   Cardinality: 1..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> 

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[David Jencks]

I’m wondering what the DS implementation bundle is getting it’s Config Admin 
packages from in each case.

thanks
david jencks

> On Jul 6, 2016, at 9:20 AM, Benson Margulies  wrote:
> 
> I can dump a bunch of wiring. But I'd have to repro the problem.
> which, after being quite reproducible for some time, has gone into
> hiding to be replaced by a different problem. Just what bundle's
> wiring are you interested in?
> 
> 
> On Wed, Jul 6, 2016 at 12:18 PM, David Jencks  
> wrote:
>> There has been another report of a similar problem that I haven’t been able 
>> to reproduce (outside karaf).  Does Karaf provide any way of looking at the 
>> bundle wiring?  I’d like to see how the DS bundle is wired in the working 
>> and non working cases.  I’m wondering if in the non working case DS gets 
>> wired correctly to config admin.
>> 
>> thanks
>> david jencks
>> 
>>> On Jul 6, 2016, at 9:10 AM, Benson Margulies  wrote:
>>> 
>>> com.basistech.worker.service.cfg exists.
>>> 
>>> And when I stopped and started karaf, the component got itself activated.
>>> 
>>> 
>>> 
>>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
>>> wrote:
 You have configuration policy require and there is no component 
 configuration shown, so the configuration is missing.
 
 If at least one matching configuration were available to DS you’d see one 
 component configuration for each configuration, and then you could tell if 
 the references were satisfied or not from the references section of the 
 component configuration.
 
 thanks
 david jencks
 
> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
> 
> Folks, I have a service that isn't starting, and  I cannot see why. Any 
> clues?
> 
> 
> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
> Component Details
> Name: com.basistech.ws.worker.service.WorkerService
> State   : UNSATISFIED
> Properties  :
>  service=worker
> References
> 
> -
> 
> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
> Component Description:
> Name: com.basistech.ws.worker.service.WorkerService
> Default State: enabled
> Activation: immediate
> Configuration Policy: require
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [com.basistech.worker.service]
> Services:
>com.basistech.ws.common.WebServiceAvailable
> Service Scope: singleton
> Reference: CxfTransport
>  Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>  Cardinality: 1..1
>  Policy: static
>  Policy option: reluctant
>  Reference Scope: bundle
> Reference: Metrics
>  Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>  Cardinality: 1..1
>  Policy: static
>  Policy option: reluctant
>  Reference Scope: bundle
> Reference: Worker
>  Interface Name: com.basistech.ws.worker.api.WorkerInterface
>  Cardinality: 1..1
>  Policy: static
>  Policy option: reluctant
>  Reference Scope: bundle
> Properties:
>  service = worker
 
>> 

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[David Jencks]

Is that the same karaf?  The first scr:list looks like the new format and the 
second like the really old format.  There have been some shenanigans where 
karaf thought they knew better than DS how to write a gogo command, so maybe 
only the command is the wrong one rather than the DS implementation, but 
something appears really different on restart.

david jencks

> On Jul 6, 2016, at 9:18 AM, Benson Margulies  wrote:
> 
> Here's how I got into this.
> 
> I have this Karaf assembly. If I start if just after it is built, it
> works fine. If I stop and restart it, it fails, because the CXF HTTP
> transport does not start in time.
> 
> So, I added @References to ensure that the transport starts first.
> Then, I hit the problem reported in this thread: a component refuses
> to start for lack of a configuration pid whose file is sitting right
> there.
> 
> If I delete the karaf data directory again, everything is fine.
> 
> scr:list goes:
> 
> karaf@root>scr:list
> BundleId Component Name Default State
>Component Id State  PIDs (Factory PID)
> [  44]   com.basistech.ws.common.InitializeS3FSService  enabled
>[   1] [active  ]
> [  44]   com.basistech.ws.common.metrics.MetricsRegistryServiceImpl  enabled
>[   2] [active  ] com.basistech.ws.metrics
> [  45]   com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
> enabled
>[  19] [active  ] com.basistech.ws.transport.http
> ...
> 
> 
> If I stop and start again,
> 
> scr:list switches format to:
> 
> karaf@root>scr:list
> ID | State   | Component Name
> ---
> -1 | UNSATISFIED |
> com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker
> 1  | ACTIVE  | com.basistech.ws.common.InitializeS3FSService
> 2  | ACTIVE  | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl
> 3  | ACTIVE  |
> com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
> 4  | ACTIVE  |
> com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver
> 5  | ACTIVE  | com.basistech.ws.embeddedworker.impl.EmbeddedTransport
> 6  | ACTIVE  | com.basistech.ws.usage.impl.LocalUsageTracker
> ...
> 
> (That first component is supposed to be unsatisfied) All my components
> appear to be alive.
> 
> and
> 
> But a swath of my CXF services stop working, even though their
> components are activated and they have made the call to start the
> service.
> 
> 
> On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies  
> wrote:
>> com.basistech.worker.service.cfg exists.
>> 
>> And when I stopped and started karaf, the component got itself activated.
>> 
>> 
>> 
>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
>> wrote:
>>> You have configuration policy require and there is no component 
>>> configuration shown, so the configuration is missing.
>>> 
>>> If at least one matching configuration were available to DS you’d see one 
>>> component configuration for each configuration, and then you could tell if 
>>> the references were satisfied or not from the references section of the 
>>> component configuration.
>>> 
>>> thanks
>>> david jencks
>>> 
 On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
 
 Folks, I have a service that isn't starting, and  I cannot see why. Any 
 clues?
 
 
 karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
 Component Details
 Name: com.basistech.ws.worker.service.WorkerService
 State   : UNSATISFIED
 Properties  :
   service=worker
 References
 
 -
 
 karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
 *** Bundle: com.basistech.ws.rosapi-worker-service (144)
 Component Description:
 Name: com.basistech.ws.worker.service.WorkerService
 Default State: enabled
 Activation: immediate
 Configuration Policy: require
 Activate Method: activate
 Deactivate Method: deactivate
 Modified Method: -
 Configuration Pid: [com.basistech.worker.service]
 Services:
 com.basistech.ws.common.WebServiceAvailable
 Service Scope: singleton
 Reference: CxfTransport
   Interface Name: org.apache.cxf.transport.http.DestinationRegistry
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Reference: Metrics
   Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Reference: Worker
   Interface Name: com.basistech.ws.worker.api.WorkerInterface
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Properties:
   service = worker
>>> 

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

I can dump a bunch of wiring. But I'd have to repro the problem.
which, after being quite reproducible for some time, has gone into
hiding to be replaced by a different problem. Just what bundle's
wiring are you interested in?


On Wed, Jul 6, 2016 at 12:18 PM, David Jencks  wrote:
> There has been another report of a similar problem that I haven’t been able 
> to reproduce (outside karaf).  Does Karaf provide any way of looking at the 
> bundle wiring?  I’d like to see how the DS bundle is wired in the working and 
> non working cases.  I’m wondering if in the non working case DS gets wired 
> correctly to config admin.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 9:10 AM, Benson Margulies  wrote:
>>
>> com.basistech.worker.service.cfg exists.
>>
>> And when I stopped and started karaf, the component got itself activated.
>>
>>
>>
>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
>> wrote:
>>> You have configuration policy require and there is no component 
>>> configuration shown, so the configuration is missing.
>>>
>>> If at least one matching configuration were available to DS you’d see one 
>>> component configuration for each configuration, and then you could tell if 
>>> the references were satisfied or not from the references section of the 
>>> component configuration.
>>>
>>> thanks
>>> david jencks
>>>
 On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:

 Folks, I have a service that isn't starting, and  I cannot see why. Any 
 clues?


 karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
 Component Details
 Name: com.basistech.ws.worker.service.WorkerService
 State   : UNSATISFIED
 Properties  :
   service=worker
 References

 -

 karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
 *** Bundle: com.basistech.ws.rosapi-worker-service (144)
 Component Description:
 Name: com.basistech.ws.worker.service.WorkerService
 Default State: enabled
 Activation: immediate
 Configuration Policy: require
 Activate Method: activate
 Deactivate Method: deactivate
 Modified Method: -
 Configuration Pid: [com.basistech.worker.service]
 Services:
 com.basistech.ws.common.WebServiceAvailable
 Service Scope: singleton
 Reference: CxfTransport
   Interface Name: org.apache.cxf.transport.http.DestinationRegistry
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Reference: Metrics
   Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Reference: Worker
   Interface Name: com.basistech.ws.worker.api.WorkerInterface
   Cardinality: 1..1
   Policy: static
   Policy option: reluctant
   Reference Scope: bundle
 Properties:
   service = worker
>>>
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

Here's how I got into this.

I have this Karaf assembly. If I start if just after it is built, it
works fine. If I stop and restart it, it fails, because the CXF HTTP
transport does not start in time.

So, I added @References to ensure that the transport starts first.
Then, I hit the problem reported in this thread: a component refuses
to start for lack of a configuration pid whose file is sitting right
there.

If I delete the karaf data directory again, everything is fine.

scr:list goes:

karaf@root>scr:list
 BundleId Component Name Default State
Component Id State  PIDs (Factory PID)
 [  44]   com.basistech.ws.common.InitializeS3FSService  enabled
[   1] [active  ]
 [  44]   com.basistech.ws.common.metrics.MetricsRegistryServiceImpl  enabled
[   2] [active  ] com.basistech.ws.metrics
 [  45]   com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
 enabled
[  19] [active  ] com.basistech.ws.transport.http
...


If I stop and start again,

scr:list switches format to:

karaf@root>scr:list
ID | State   | Component Name
---
-1 | UNSATISFIED |
com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker
1  | ACTIVE  | com.basistech.ws.common.InitializeS3FSService
2  | ACTIVE  | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl
3  | ACTIVE  |
com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
4  | ACTIVE  |
com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver
5  | ACTIVE  | com.basistech.ws.embeddedworker.impl.EmbeddedTransport
6  | ACTIVE  | com.basistech.ws.usage.impl.LocalUsageTracker
...

(That first component is supposed to be unsatisfied) All my components
appear to be alive.

and

But a swath of my CXF services stop working, even though their
components are activated and they have made the call to start the
service.


On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies  wrote:
> com.basistech.worker.service.cfg exists.
>
> And when I stopped and started karaf, the component got itself activated.
>
>
>
> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
> wrote:
>> You have configuration policy require and there is no component 
>> configuration shown, so the configuration is missing.
>>
>> If at least one matching configuration were available to DS you’d see one 
>> component configuration for each configuration, and then you could tell if 
>> the references were satisfied or not from the references section of the 
>> component configuration.
>>
>> thanks
>> david jencks
>>
>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
>>>
>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>> clues?
>>>
>>>
>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>> Component Details
>>>  Name: com.basistech.ws.worker.service.WorkerService
>>>  State   : UNSATISFIED
>>>  Properties  :
>>>service=worker
>>> References
>>>
>>> -
>>>
>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>> Component Description:
>>>  Name: com.basistech.ws.worker.service.WorkerService
>>>  Default State: enabled
>>>  Activation: immediate
>>>  Configuration Policy: require
>>>  Activate Method: activate
>>>  Deactivate Method: deactivate
>>>  Modified Method: -
>>>  Configuration Pid: [com.basistech.worker.service]
>>>  Services:
>>>  com.basistech.ws.common.WebServiceAvailable
>>>  Service Scope: singleton
>>>  Reference: CxfTransport
>>>Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Reference: Metrics
>>>Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Reference: Worker
>>>Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Properties:
>>>service = worker
>>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[David Jencks]

There has been another report of a similar problem that I haven’t been able to 
reproduce (outside karaf).  Does Karaf provide any way of looking at the bundle 
wiring?  I’d like to see how the DS bundle is wired in the working and non 
working cases.  I’m wondering if in the non working case DS gets wired 
correctly to config admin.

thanks
david jencks

> On Jul 6, 2016, at 9:10 AM, Benson Margulies  wrote:
> 
> com.basistech.worker.service.cfg exists.
> 
> And when I stopped and started karaf, the component got itself activated.
> 
> 
> 
> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  
> wrote:
>> You have configuration policy require and there is no component 
>> configuration shown, so the configuration is missing.
>> 
>> If at least one matching configuration were available to DS you’d see one 
>> component configuration for each configuration, and then you could tell if 
>> the references were satisfied or not from the references section of the 
>> component configuration.
>> 
>> thanks
>> david jencks
>> 
>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
>>> 
>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>> clues?
>>> 
>>> 
>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>> Component Details
>>> Name: com.basistech.ws.worker.service.WorkerService
>>> State   : UNSATISFIED
>>> Properties  :
>>>   service=worker
>>> References
>>> 
>>> -
>>> 
>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>> Component Description:
>>> Name: com.basistech.ws.worker.service.WorkerService
>>> Default State: enabled
>>> Activation: immediate
>>> Configuration Policy: require
>>> Activate Method: activate
>>> Deactivate Method: deactivate
>>> Modified Method: -
>>> Configuration Pid: [com.basistech.worker.service]
>>> Services:
>>> com.basistech.ws.common.WebServiceAvailable
>>> Service Scope: singleton
>>> Reference: CxfTransport
>>>   Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>   Cardinality: 1..1
>>>   Policy: static
>>>   Policy option: reluctant
>>>   Reference Scope: bundle
>>> Reference: Metrics
>>>   Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>   Cardinality: 1..1
>>>   Policy: static
>>>   Policy option: reluctant
>>>   Reference Scope: bundle
>>> Reference: Worker
>>>   Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>   Cardinality: 1..1
>>>   Policy: static
>>>   Policy option: reluctant
>>>   Reference Scope: bundle
>>> Properties:
>>>   service = worker
>> 

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

com.basistech.worker.service.cfg exists.

And when I stopped and started karaf, the component got itself activated.



On Wed, Jul 6, 2016 at 12:01 PM, David Jencks  wrote:
> You have configuration policy require and there is no component configuration 
> shown, so the configuration is missing.
>
> If at least one matching configuration were available to DS you’d see one 
> component configuration for each configuration, and then you could tell if 
> the references were satisfied or not from the references section of the 
> component configuration.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
>>
>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>> clues?
>>
>>
>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>> Component Details
>>  Name: com.basistech.ws.worker.service.WorkerService
>>  State   : UNSATISFIED
>>  Properties  :
>>service=worker
>> References
>>
>> -
>>
>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>> Component Description:
>>  Name: com.basistech.ws.worker.service.WorkerService
>>  Default State: enabled
>>  Activation: immediate
>>  Configuration Policy: require
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.worker.service]
>>  Services:
>>  com.basistech.ws.common.WebServiceAvailable
>>  Service Scope: singleton
>>  Reference: CxfTransport
>>Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: Metrics
>>Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: Worker
>>Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Properties:
>>service = worker
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[David Jencks]

You have configuration policy require and there is no component configuration 
shown, so the configuration is missing.

If at least one matching configuration were available to DS you’d see one 
component configuration for each configuration, and then you could tell if the 
references were satisfied or not from the references section of the component 
configuration.

thanks
david jencks

> On Jul 6, 2016, at 8:52 AM, Benson Margulies  wrote:
> 
> Folks, I have a service that isn't starting, and  I cannot see why. Any clues?
> 
> 
> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
> Component Details
>  Name: com.basistech.ws.worker.service.WorkerService
>  State   : UNSATISFIED
>  Properties  :
>service=worker
> References
> 
> -
> 
> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
> Component Description:
>  Name: com.basistech.ws.worker.service.WorkerService
>  Default State: enabled
>  Activation: immediate
>  Configuration Policy: require
>  Activate Method: activate
>  Deactivate Method: deactivate
>  Modified Method: -
>  Configuration Pid: [com.basistech.worker.service]
>  Services:
>  com.basistech.ws.common.WebServiceAvailable
>  Service Scope: singleton
>  Reference: CxfTransport
>Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: Metrics
>Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: Worker
>Interface Name: com.basistech.ws.worker.api.WorkerInterface
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Properties:
>service = worker

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[David Bosschaert]

Hi Benson,

Could it be that the configuration with pid com.basistech.worker.service is
missing? Or otherwise one of the services that it depends on isn't there
(or isn't visible)?

Cheers,

David

Re: How to secure Karaf

[Kevin Schmidt]

I have a follow up question.

It is good that one can disable this feature, but if someone would like to
use this feature of bin/client to connect without a password but do so with
their own public/private key pair, how would bin/client be told to use it?
Is that possible or is the private key built in to
org.apache.karaf.client.Main?

On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt  wrote:

> I just followed the instructions to secure the container and using
> bin/client does now require a password and doesn't successfully connect to
> the container.  I did this with Karaf 3.0.6.  Perhaps something changed
> with Karaf 4?
>
> Kevin
>
> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
> elliot.hunting...@gmail.com> wrote:
>
>> I wrote a question (
>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>> on stack overflow pertaining to Christian Schneider's blog post, How to
>> hack into any default apache karaf installation
>> .
>> After following his instructions to secure the container the `bin/client`
>> command, rather than failing, appears to create a new file `etc/host.key`
>> and successfully connects to the container. This was unexpected according
>> to the blog post.
>>
>> It would be helpful if someone would answer this question on stack
>> overflow.
>>
>> Thanks,
>> Elliot
>>
>
>

What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

Folks, I have a service that isn't starting, and  I cannot see why. Any clues?


karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
Component Details
  Name: com.basistech.ws.worker.service.WorkerService
  State   : UNSATISFIED
  Properties  :
service=worker
References

-

karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
*** Bundle: com.basistech.ws.rosapi-worker-service (144)
Component Description:
  Name: com.basistech.ws.worker.service.WorkerService
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.worker.service]
  Services:
  com.basistech.ws.common.WebServiceAvailable
  Service Scope: singleton
  Reference: CxfTransport
Interface Name: org.apache.cxf.transport.http.DestinationRegistry
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Metrics
Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Worker
Interface Name: com.basistech.ws.worker.api.WorkerInterface
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Properties:
service = worker

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[kotoole]

I am using felix.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129p4047134.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Problems with Karaf 4.0.5 vs. Karaf 4.0.4

[Christian Lutz]

Issue Karaf-4608. I do know that the exception is different. But I saw the same 
exception if the blueprint is different. 

Christian

> Am 06.07.2016 um 07:20 schrieb Jean-Baptiste Onofré :
> 
> Thanks Christian for the Jira,
> 
> I will take a look and fix in Blueprint (or downgrade for Karaf 4.0.6).
> 
> Regards
> JB
> 
>> On 07/06/2016 07:12 AM, Christian Lutz wrote:
>> I created a bug report for this yesterday. I dont have the issue number by 
>> hand. So just look in jira. I guess the problem is because of a chaning in 
>> aries blueprint 1.6.1.
>> 
>> Which framework did you use felix or equinox?
>> 
>>> Am 06.07.2016 um 05:43 schrieb kotoole :
>>> 
>>> With Karaf 4.0.5, it appears Internet access is required to resolve
>>> namespaces.
>>> 
>>> When Internet access is disabled, I receive the following error among
>>> others:
>>> 21:56:21,785 | WARN  |  1.6.1 |  | Dynamically adding namespace handler
>>> http://cxf.apache.org/configuration/parameterized-types to bundle xxx/1.0.0
>>> 21:56:42,778 | ERROR |  1.6.1 |  | Unable to start blueprint container for
>>> bundle xxx/1.0.0
>>> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
>>> 'pt:ParameterizedBoolean' to a(n) 'simpleType definition' component.
>>>at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
>>>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
>>> 
>>> Also, I am unable to use shell commands using old schemas:
>>> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute,
>>> 'http://schemas.xmlsoap.org/wsdl/', of an  element information item
>>> must be identical to the targetNamespace attribute,
>>> 'http://karaf.apache.org/xmlns/shell/v1.1.0', of the imported document.
>>>at
>>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
>>> Source)[:]
>>>at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
>>>at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://karaf.922171.n3.nabble.com/Problems-with-Karaf-4-0-5-vs-Karaf-4-0-4-tp4047129.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