date:20161018

Re: Looking for SCR debugging assistance, as usual

2016-10-18 Thread Benson Margulies

Here is another comparison that might be less work to look at. In the
working version, configuration admin gets busy, in the non-working,
not.

A working log:

13:00:13.587 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Registering component with pid [com.basistech.ws.bus] for bundle 103
13:00:13.588 [FelixStartLevel] DEBUG r.1.4.101.201610171848 -
BundleComponentActivator : Bundle [103] ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar)))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar)))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to null
to bundle 
/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Adding configuration
com.basistech.ws.bus
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]getBundleLocation() ==> null
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to * to
bundle 
/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar
--- and a lot of messages about supplying this to other components.

A non-working log:

08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Registering component with pid [com.basistech.ws.bus] for bundle 103
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] May enable component holder
com.basistech.ws.worker.bus.impl.BusService
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] Enabling component holder
com.basistech.ws.worker.bus.impl.BusService
-- sorry silence --
08:37:01.334 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Starting destruction process bundle: rosapi-worker-core/104

On Tue, Oct 18, 2016 at 12:58 PM, Benson Margulies  wrote:
> I have a pile of components that aren't starting because they can't
> satisfy a reference to WorkerBusService, implemented by a class named
> BusService.
>
>  At the bottom of this messages are all the SCR log messages that
> mention BusService -- not much talking about it, and then many things
> that desire it. How do I tell what is preventing BusService from
> activating? It does require a configuration PID, but:
>
> //configurationPolicy = ConfigurationPolicy.REQUIRE,

Looking for SCR debugging assistance, as usual

2016-10-18 Thread Benson Margulies

I have a pile of components that aren't starting because they can't
satisfy a reference to WorkerBusService, implemented by a class named
BusService.

 At the bottom of this messages are all the SCR log messages that
mention BusService -- not much talking about it, and then many things
that desire it. How do I tell what is preventing BusService from
activating? It does require a configuration PID, but:

//configurationPolicy = ConfigurationPolicy.REQUIRE, configurationPid
= "com.basistech.ws.bus"

and here are the CM log events.


08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
location=null)
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to * to
bundle 
/Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
null, null)
08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Updating config
com.basistech.ws.bus with
{licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No
SynchronousConfigurationListeners to send CM_UPDATED event to.
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
ConfigurationEvent: pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
scheduled





  1119:08:37:01.331 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6
- BundleComponentActivator : Bundle [103] descriptor locations
OSGI-INF/com.basistech.ws.worker.bus.impl.BusService.xml
   1121:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
   1122:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
May enable component holder
com.basistech.ws.worker.bus.impl.BusService
   1123:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
Enabling component holder com.basistech.ws.worker.bus.impl.BusService


   1246:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.flinx.FlinxComponentService(-1)] Dependency
Manager created
BusConfiguredinterface=com.basistech.ws.worker.api.WorkerBusService,
filter=null, policy=static, cardinality=1..1, bind=setBusConfigured,
unbind=null, updated=null, field=null, field-option=null,
field-collection-type=null
   1260:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.flinx.FlinxComponentService(11)] New service
tracker for BusConfigured, initial active: false, previous references:
{}, classFilter:
(objectClass=com.basistech.ws.worker.api.WorkerBusService),
eventFilter null, initialReferenceFilter
(objectClass=com.basistech.ws.worker.api.WorkerBusService)
   1262:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - classNameFilter:
(objectClass=com.basistech.ws.worker.api.WorkerBusService) event
filter: null
   1304:08:37:01.354 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.rbl.BaseLinguisticsComponentServiceImpl(-1)]
Dependency Manager created
BusConfiguredinterface=com.basistech.ws.worker.api.WorkerBusService,

Re: how can a bundle stop itself programmatically?

2016-10-18 Thread Raymond Auge

This is probably not a very good approach. Generally you should let some
bundle agent be responsible for the states of bundles.

Perhaps explaining your use case could help us suggest a better alternative.

Sincerely,
- Ray

On Tue, Oct 18, 2016 at 8:35 AM, sid19039  wrote:

> Hello All,
>
> I have trying to stop a bundle from within itself by invoking stop method
> as
> following in its Activator's start method:
> bundleContext.getBundle().stop();
>
> But post this statement is executed, when i check its state via "lb"
> command
> on  felix shell, its state is shown as Active.
> Then when i try to stop it via stop  command, an exception is
> thrown that
> *org.osgi.framework.BundleException: Stopping a starting or stopping
> bundle
> is currently not supported.*And then its state is shown as *stopping*
>
> Please someone tell how i can achieve this..
>
> Regards
> Siddharth
>
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.
> nabble.com/how-can-a-bundle-stop-itself-programmatically-tp5018885.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Looking for SCR debugging assistance, as usual

Looking for SCR debugging assistance, as usual

Re: how can a bundle stop itself programmatically?

3 matches

Site Navigation

Mail list logo

Footer information