Yes, that allows you to configure each service instance for the
receiver, but technically you could do this simply with ServiceFactory
if you were implementing the service factory yourself. However, since
you are using iPOJO, then you need to implement a custom strategy, which
is effectively equivalent to implementing a service factory.
Your original desire to assign a different service property to each
service is not really possible, since the service only has one service
registration (and associated properties) no matter if it is a service
factory or a single global object.
-> richard
On 5/10/12 05:01 , Adrian Mörchen wrote:
Okay, solved the problem my elf.
The solution is quite simple, when known: Implementing a custom
CreationStrategy:
@Component
@Provides(strategy = "my.service.MyServiceCreationStrategy")
@Instantiate
public class MyServiceImpl implements MyService {
private final String symbolicName;
/**
* Constructor.
*
* @param context
* Context of the current bundle.
*/
public MyServiceImpl(String symbolicName) {
this.symbolicName = symbolicName;
}
...
}
package my.service;
public class MyServiceCreationStrategy extends CreationStrategy {
private final Map<String, MyService> services = new HashMap<String,
MyService>();
/**
* {@inheritDoc}
*/
@Override
public Object getService(Bundle bundle, ServiceRegistration registration) {
String symbolicName = bundle.getSymbolicName();
MyService myService = services.get(symbolicName);
if (myService == null) {
myService = new MyServiceImpl(symbolicName);
services.put(symbolicName, myService);
}
return myService;
}
/**
* {@inheritDoc}
*/
@Override
public void ungetService(Bundle bundle, ServiceRegistration registration,
Object service) {
services.remove(bundle.getSymbolicName());
}
/**
* Does nothing.
*
* {@inheritDoc}
*/
@Override
public void onPublication(InstanceManager instance, String[] interfaces,
Properties props) {
// Do nothing.
}
/**
* Does nothing.
*
* {@inheritDoc}
*/
@Override
public void onUnpublication() {
// Do nothing.
}
-----Ursprüngliche Nachricht-----
Von: Adrian Mörchen [mailto:[email protected]]
Gesendet: Donnerstag, 10. Mai 2012 08:12
An: [email protected]
Betreff: AW: Problem creating separate service for each bundle
Thanks Richard,
yep a basic musunderstanding on my site. But is it still possible to do this?
Creating an instance with information about the bundle requesting it?
-----Ursprüngliche Nachricht-----
Von: Richard S. Hall [mailto:[email protected]]
Gesendet: Mittwoch, 9. Mai 2012 16:43
An: [email protected]
Betreff: Re: Problem creating separate service for each bundle
It sounds like you have a basic misunderstanding. The SERVICE strategy
implements the OSGi Service Factory concept and automatically creates a unique
service object instance for each bundle that requests the service. It doesn't
mean that each requesting bundle will become the provider of the unique service
instance. The provider is always the provider.
-> richard
On 5/9/12 10:24 , Adrian Mörchen wrote:
Hi,
I want to create a separate instance of a service with the bundles symbolic
name as field.
I've read somewhere that this should be possible using "SERVICE" as strategy:
@Component
@Provides(strategy = "SERVICE")
@Instantiate
public class MyServiceImpl implements MyService {
private final String symbolicName;
/**
* Constructor.
*
* @param context
* Context of the current bundle.
*/
public MyServiceImpl(BundleContext context) {
this.symbolicName = context.getBundle().getSymbolicName();
}
...
}
Unfortunately this doesn't work . The bundle context is always the
context of the bundle providing the service, but I want it to be the context of
the bundle requiring the context.
Any hints, how to solve this?
· The only more specific tutorial on this I found:
http://ipojo-dark-side.blogspot.de/2009/04/customized-service-object-creation-with.html
o But it's quite old and
o Not a full working example, which makes it hard to understand
· Also a custom factory method doesn't work.
Thanks,
Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
