-
1. Re: JBOSGI Blueprint Class Ref in AS 7.1.3.Final
ulrichromahn Jan 31, 2013 2:43 PM (in response to djchapm)Daniel,
I believe defining an OSGi Service as an Abstract Class will not work at all.
Blueprint will be creating a dynamic proxy for each defined service and then instantiate the actual service object via reflection.
So, if you are using an Interface, Blueprint will use the associated service bean to instantiate the actual service object. However, if you use proxy-method='classes', I believe it assumes that your service definition is already a concrete class and will try to instantiate this class directly.
However, an abstract class cannot be instantiated.
On a different note: I would not consider it good practice anyways to use a concrete class as service definition and not an interface.
In addition, I am generally staying away from abstract classes in conjunction with any IoC container, such as Spring, CDI, or Blueprint, since those frameworks will try to control the lifecycle of Java classes which is not easily possible with abstract classes (since they cannot be directly instantiated).
-Uli
-
2. Re: JBOSGI Blueprint Class Ref in AS 7.1.3.Final
djchapm Jan 31, 2013 4:09 PM (in response to ulrichromahn)Thanks Uli for your response. Regarding Abstract Classes... I'm finding it hard to design w/out them in a meaningful way. I've been using Spring since Spring 1.0 for service layer abstraction and IOC/DI. I am able to use abstact classes to do common coding and abstract methods for custom needs. So I can handle all my services in the same way (Think Command Pattern).
Anyway - I made it work by creating more modules.
Mod1:
BaseInterface
Mod2:
ServiceInterface extends BaseIinterface
-> This is the interface that is exported for clients
Mod3:
Abstract class implements BaseInterface
{
pub final invoke (String msg, Object[] params) {
Command pattern:
doThis(msg, parms); doThat; etc();
}
pub abstract doThis(String msg, Object[] params);
}
Mod 4:
ServiceImplementation extends AbstractClass implements ServiceInterface.
So now I can have classes that work on AbstractClass and fulfill a need common to all services. And the code is in one spot, not 100.
I'm sure you could create Utils or something to handle that invoke method, but I prefer this composition. Functionality is more built in.
I'm fairly new still to OSGI so not adverse to advice. But I don't think I'm breaking any rules. Haven't been able to find any great SOA Patterns for OSGI So far - would be great to see that on an OO level.
Dan C.