Eclipse Community Forums: Virgo » I Don't Get This...

Home » Eclipse Projects » Virgo » I Don't Get This...(A bundle declared as singleton but logging shows more than one object.)

Show: Today's Messages :: Show Polls :: Message Navigator

I Don't Get This... [message #754295]

Tue, 01 November 2011 21:14

Geoffry Roberts

Messages: 29
Registered: March 2011

Junior Member

All,

Why am I getting (at least) two object instantiations in a singleton bundle?

I am trying to use blueprint and I have setup a simple set of bundles to work with.

I have an interface bundle and an implementation bundle. I then have a bundle that contains an implementation of CommandProvider. This bundle is declared as a singleton. The idea is to execute a command that calls a method in the interface bundle.

During execution, I am encountering at least two CommandProviders. (1) Is being instantiated by the blueprint framework, but another (2) shows itself when the aforementioned command is issued.

NOTE: cmdapi.CommandSet implements CommandProvider.

This is from the log file. Notice the text that says, this==>1433741306 and this==>517116146, the numbers are the objects' hashcodes indicating there are two different objects. Why is this? especially considering that the bundle is a singleton?

This is what logs when the CommandSet class is instatiated:

[2011-11-01 12:41:18.946] INFO iniBlueprintExtenderThread-8 cmdapi.CommandSet setAPI==>blue!!
[2011-11-01 12:41:18.946] INFO iniBlueprintExtenderThread-8 cmdapi.CommandSet this==>1433741306
[2011-11-01 12:41:18.946] INFO iniBlueprintExtenderThread-8 cmdapi.CommandSet <==setAPI

...left out...

hread-8 cmdapi.CommandSet startUp=====>cmdapi.CommandSet
[2011-11-01 12:41:18.947] INFO iniBlueprintExtenderThread-8 cmdapi.CommandSet this==>1433741306
[2011-11-01 12:41:18.947] INFO iniBlueprintExtenderThread-8 cmdapi.CommandSet getBlue==>blue!!

This is what logs when I execute the command:

[2011-11-01 12:42:06.802] INFO Equinox Console Session cmdapi.CommandSet this==>517116146

This is the code being executed:

public class CommandSet implements CommandProvider {
Logger Log = LoggerFactory.getLogger(CommandSet.class);
API blueAPI = null;

// First, this method is being called upon instantiation. At this point, the value
// api is not null. The object is i.e this==>1433741306

public void setBlue(API api) {
Log.info("setAPI==>" + api.getAPI());
Log.info("this==>" + this.hashCode());
this.blueAPI = api;
Log.info("<==setAPI");
}

// Second, this method is also being called upon instantiation. At this point, the
// value blueAPI is not null. The object is i.e this==>1433741306

public void startUp() {
Log.info("startUp=====>" + this.getClass().getName());
Log.info("this==>" + this.hashCode());
Log.info("getBlue==>" + blueAPI.getAPI());
}

// Third, this method is the command, which is called from the OSGi command line.
// At this point the value blueAPI is null. Why? because we now have a different
// object i.e this==>517116146. Why do we have a different object?

public Object _blue(CommandInterpreter itrp) {
itrp.println("going blue!!" + blueAPI);
Log.info("this==>" + this.hashCode());
Log.info("getBlue==>" + blueAPI.getAPI());
itrp.println("getBlue==>" + blueAPI.getAPI());
return null;
}

@Override
public String getHelp() {
// TODO Auto-generated method stub
return null;
}
}

Report message to a moderator

Re: I Don't Get This... [message #754338 is a reply to message #754295]

Wed, 02 November 2011 09:01

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Marking a bundle as a singleton simply ensures that one and only one version of a bundle with that bundle symbolic name may be resolved (and therefore only one version may be started). It doesn't otherwise constrain the behaviour of the bundle such as how many instances of an object it can instantiate.

So it seems your issue is more likely to be associated with your application and its use of blueprint.

I suggest attaching a debugger to Virgo (explained in the Virgo User Guide) and setting a breakpoint (with "suspend VM" selected) on the constructor(s) of CommandProvider (if it only has an implicit default constructor, you may need to make this explicit in order to put a breakpoint on it). Then you should be able to see what calling sequences are constructing the instances.

Report message to a moderator

Re: I Don't Get This... [message #754514 is a reply to message #754338]

Wed, 02 November 2011 20:45

Geoffry Roberts

Messages: 29
Registered: March 2011

Junior Member

Thanks for the response.

I now realize the problem with double instantiations. I'll post my finding for the benefit of the community.

This how I was setting up my command service. Old school, pre-blueprint:

// I was using an explicit Activator.
public class CmdAct implements BundleActivator {

public void start(BundleContext bundleContext) throws Exception {
CmdAct.context = bundleContext;

// This is where I was getting my second instantiation.
CommandProvider service = new CommandSet();
context.registerService(CommandProvider.class.getName(),
service, null);
}

I got rid of the above and replaced it with this in my blueprint.xml file:

<service ref="cmdapi" interface="org.eclipse.osgi.framework.console.CommandProvider" />

Here is the whole file:

<?xml version="1.0" encoding="UTF-8"?>

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<reference id="blueAPI" interface="api.API" component-name="blueAPI" />
<reference id="redAPI" interface="api.API" component-name="redAPI" />

<service ref="cmdapi" interface="org.eclipse.osgi.framework.console.CommandProvider" />

<bean id="cmdapi" class="api.CommandSet" init-method="startUp">
<property name="blue" ref="blueAPI" />
<property name="red" ref="redAPI" />
</bean>
</blueprint>

Report message to a moderator