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 >>> >>> >
