karaf@root()> scr:info
Error executing command: Cannot coerce info() to any of [(String)]
You have to use 4.0.4-SNAPSHOT as I fixed an issue in shell-compat.
Regards
JB
On 12/09/2015 02:06 PM, Benson Margulies wrote:
karaf@root>feature:install shell-compat
karaf@root>
karaf@root>scr:info
Command not found: scr:info
On Wed, Dec 9, 2015 at 8:03 AM, Jean-Baptiste Onofré <[email protected]> wrote:
Gogo commands should work if shell-compat feature is installed.
Regards
JB
Sent from my Samsung device
-------- Original message --------
From: Benson Margulies <[email protected]>
Date: 09/12/2015 12:34 (GMT+01:00)
To: [email protected]
Subject: Re: Bundle in mysterious scr state
JB, I have some related issues for which I would really benefit from
using the 'real gogo scr' command. Is there some method I'm missing to
get to it?
On Tue, Dec 8, 2015 at 9:00 PM, Benson Margulies <[email protected]>
wrote:
Bingo! Thank you very much!
On Tue, Dec 8, 2015 at 8:57 PM, Benson Margulies <[email protected]>
wrote:
On Tue, Dec 8, 2015 at 8:49 PM, David Jencks <[email protected]>
wrote:
The simplest explanation for the behavior change is that no-service
components are immediate (there’s no service to request to trigger creation
of the component) whereas components exposing a service are delayed unless
you explicitly specify immediate. You could have put your system into a
state where no one has actually requested the WebServiceAvailable service,
so none of the network of components gets activated, and as soon as
something gets the service, everything will start up. If you specify
immediate=true and you get the old behavior, this is what happened :-).
Then you can decide how lazily you want all these services to be
instantiated.
I guess I misread the doc on immediate to be 'true' when there was no
factory. Let me go turn it on.
As a reported, I'm momentarily stumped on the scr:info command, having
done what you suggested to no good effect.
I bet that if you removed the karaf scr command and rebuilt (or left out
the bundle its in if that wouldn’t kill the console) you’d see the felix scr
gogo command…. I thought I remember JB saying recently that karaf supported
both karaf and gogo commands, so maybe the karaf one is hiding the
same-named felix one.
Felix scr logs way more info than you get in the info command, but it’s
harder to interpret. You need to make sure the log service is recording
debug level, and you need to set the felix scr configuration property
ds.loglevel=debug
If you are configuring ds using config admin, put this in the
configuration. Otherwise you can set it as a framework property (not sure
how to do this in karaf, but I imagine it’s possible).
hope this helps
david jencks
On Dec 8, 2015, at 5:26 PM, Benson Margulies <[email protected]>
wrote:
The component state is '2' (ENABLED).
I can now describe what brings on this mess. Here's a diff. In a
different bundle, in a different component, I change it from services
= {} to service = { some interface }.
Thereafter, a whole slew of bundles get into this stuck state. In
particular, a bundle that is absolutely not depending on the one I
change.
I don't think that plain gogo commands can be run in Karaf, but I
could be misinformed.
David, short of doing the work of porting the modern SCR display code
from Felix into Karaf, any ideas about what to look at?
Does SCR log anything I could enable to get a clue?
diff --git
a/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java
b/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java
index 572bcc6..9f7f22f 100644
---
a/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java
+++
b/worker/service/src/main/java/com/basistech/ws/worker/service/WorkerService.java
@@ -15,6 +15,7 @@
package com.basistech.ws.worker.service;
import com.basistech.rosette.RosetteRuntimeException;
+import com.basistech.ws.common.WebServiceAvailable;
import com.basistech.ws.common.json.JsonUtils;
import com.basistech.ws.common.ticket.Ticket;
import com.basistech.ws.worker.api.WorkerInterface;
@@ -51,9 +52,11 @@ import java.util.concurrent.atomic.AtomicLong;
* This registers itself upon activation as a CXF JAX-RS Service.
*/
@Component(configurationPid = "com.basistech.ws.worker",
- /* No services; we're here to register with CXF. */
- service = {})
-public class WorkerService {
+ // this service simply allows tests to wait for this thing to
be started.
+ service = { WebServiceAvailable.class },
+ property = { "service=worker" }
+)
+public class WorkerService implements WebServiceAvailable {
private static final Logger LOG =
LoggerFactory.getLogger(WorkerService.class);
private static final String APPLICATION_X_JACKSON_SMILE =
"application/x-jackson-smile";
private static final MediaType APPLICATION_X_JACKSON_SMILE_TYPE
On Tue, Dec 8, 2015 at 8:09 PM, David Jencks <[email protected]>
wrote:
The gogo scr command is packaged in felix ds itself. If karaf
supports gogo
commands you ought to be able to see it.
Most of those states haven’t existed in years. Are you trying to use
the
backwards compatibility bundle to avoid updating your command to show
the
new spec-defined state info from the DTOs? The model the backwards
compatibility bundle relies on is really bogus.
david jencks
On Dec 8, 2015, at 4:38 PM, Benson Margulies <[email protected]>
wrote:
Dependencies are too big. I will debug the command and tell you what I
see
when I get back home
On Dec 8, 2015 7:29 PM, "Jean-Baptiste Onofré" <[email protected]>
wrote:
I mean share your code or bundle jar in order for me to try to
reproduce
and check the actual component state ;)
Regards
JB
On 12/09/2015 01:27 AM, Benson Margulies wrote:
What do you mean by 'send the bundles'?
On Dec 8, 2015 7:18 PM, "Jean-Baptiste Onofré" <[email protected]
<mailto:[email protected]>> wrote:
Just checked, the two states that the command doesn't deal is the
deprecated state: STATE_ENABLED, and STATE_DESTROYED
Maybe the component are in this state.
@Benson: can you send the bundles to test if the component is not
in
the "deprecated" state ?
Thanks,
Regards
JB
On 12/09/2015 01:14 AM, Jean-Baptiste Onofré wrote:
The ScrDetails command basically does:
- component.getState()
- then a switch on the int to display human readable string.
switch (componentState) {
case Component.STATE_ACTIVE:
retVal = "ACTIVE";
break;
case Component.STATE_ACTIVATING:
retVal = "ACTIVATING";
break;
case Component.STATE_DEACTIVATING:
retVal = "DEACTIVATING";
break;
case Component.STATE_DISABLED:
retVal = "DISABLED";
break;
case Component.STATE_DISABLING:
retVal = "DISABLING";
break;
case Component.STATE_DISPOSED:
retVal = "DISPOSED";
break;
case Component.STATE_DISPOSING:
retVal = "DISPOSING";
break;
case Component.STATE_ENABLING:
retVal = "ENABLING";
break;
case Component.STATE_FACTORY:
retVal = "FACTORY";
break;
case Component.STATE_REGISTERED:
retVal = "REGISTERED";
break;
case Component.STATE_UNSATISFIED:
retVal = "UNSATISFIED";
break;
So, it would mean that the component is not in the previous
state
(another one maybe missing in the switch).
Regards
JB
On 12/09/2015 01:03 AM, David Jencks wrote:
I have no idea what this command you are using is, can
you
show the
output from the gogo scr:info command for this component?
thanks
david jencks
On Dec 8, 2015, at 3:51 PM, Benson Margulies
<[email protected] <mailto:[email protected]>>
wrote:
I have one particular bundle that gets into this
stuck
state since I
made some changes that should be completely unrelated
to
it. I badly
want to explain why it's stuck. I am reduced to a
sort
of 'bisect'
procedure of carefully remaking the changes to see if
I
can isolate
the problem, since the scr:details command does not
explain why it's
left 'null'.
On Tue, Dec 8, 2015 at 6:48 PM, Jean-Baptiste Onofré
<[email protected] <mailto:[email protected]>> wrote:
Karaf 4.0.2 already uses SCR 2.0.2.
Does it always occur or just on some bundles ?
Regards
JB
On 12/09/2015 12:44 AM, Benson Margulies wrote:
Karaf 4.0.2 ... It's scr 2.0.2, but I guess
the
command is not so hot.
eature:info scr
Feature scr 4.0.2
Description:
Declarative Service support
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.apache.felix/org.apache.felix.metatype/1.1.2 start-level=30
mvn:org.apache.felix/org.apache.felix.scr/2.0.2
start-level=30
mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
start-level=30
Feature contains followed conditionals:
Conditional(management) has no configuration
Conditional(management) has no configuration
files
Conditional(management) has no dependencies.
Conditional(management) contains followed
bundles:
mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.2
start-level=30
Conditional(webconsole) has no configuration
Conditional(webconsole) has no configuration
files
Conditional(webconsole) has no dependencies.
Conditional(webconsole) contains followed
bundles:
mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
start-level=30
Conditional(shell) has no configuration
Conditional(shell) has no configuration files
Conditional(shell) has no dependencies.
Conditional(shell) contains followed bundles:
mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.2
start-level=30
On Tue, Dec 8, 2015 at 6:11 PM, David Jencks
<[email protected]
<mailto:[email protected]>>
wrote:
This looks like a back level scr? maybe
1.8.x? The info from those
makes it really hard to tell what’s going
on. Is it
configuration required
and no configuration?
david jencks
On Dec 8, 2015, at 2:39 PM, Benson
Margulies <[email protected]
<mailto:[email protected]>>
wrote:
Here's a bundle. The bundle is
active,
its references are satisfied,
but its state is null. What's it
stuck
on?
36 | Active | 80 |
0.7.105.v20151208100035 |
rosapi-worker-bus
karaf@root>scr:details
com.basistech.ws.worker.bus.impl.BusService
Component Details
Name :
com.basistech.ws.worker.bus.impl.BusService
State : null
References
Reference : Bus
State : satisfied
Multiple : single
Optional : mandatory
Policy : static
Service Reference : No Services
bound
Reference : ConfigAdmin
State : satisfied
Multiple : single
Optional : mandatory
Policy : static
Service Reference : No Services
bound
karaf@root>
--
Jean-Baptiste Onofré
[email protected] <mailto:[email protected]>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected] <mailto:[email protected]>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
