Today, I found OSGi RFC 193-CDI Integration Draft has been available , and this is a very exciting news, and I have waited for long time, :).
I have spent two hours on understanding and reviewing the draft, and I want to share my some point of view with you. Maybe some of these viewpoints are a litter childish.
Firstly, I will repeat to say what the draft does:
[RFC 193]
"While OSGi services are very powerful, consuming them has been a challenge for many OSGi users. There have been a number of solutions to this problem both in OSGi specifications as well as in non-standardized technologies. OSGi Declarative Services and Blueprint are popular specifications in this area, however they provide new programming models that users need to learn. As of JavaEE 6, CDI (JSR 299) is included as a standard injection technology for JavaEE components. The CDI programming model seems suitable for interaction with the OSGi service layer as well and has the benefit that developers who are familiar with CDI don't need to learn a new technology in order to interact with the OSGi service registry."
Simply saying, the goal of OSGi/CDI Integration is to,
1) [More standardized]closely combining with JavaEE 6, 7,....
2) Reducing the learing burden of JavaEE developer who will come into OSGi world
3) Simplyfying programming model using JavaEE's power
Nextly, let us start this reviewing travel,
1 About RFC 193's reference implementation
Maybe being not final , the draft has been not stated reference implementation related things. However, I have a strong feeling that Weld-OSGi has some possibility being RFC 193's reference implementation.
Why I mentioned the issue?
If Weld-OSGi finally is the RFC 193's reference implementation, whether meaning Glassfish OSGi/CDI will be abandoned, instead, using Weld-OSGi.
2 About OSGi/CDI API's Standardization
In the whole draft, I only found the following annotation from "5 Technical Solution",
1) @OSGiComponent
2) @OSGiService
3) a group of dependency injection callbacks
4) @OSGiServiceFilter
Frankly speaking, I like the "5 Technical Solution" very much! , However, I have a question as following:
"where are these APIs's prefix(package name) ? And whether there is a plan to publish these apis's full name? And put these apis into which OSGi version? "
Of course, there is another possiblity that OSGi EEG will leave these to OSGi/CDI providers.
3 About "4.1 Functional Requirements"
1) the most important requirement of them I think
"CDI002 – The specification MUST make it possible to access all CDI managed beans from the OSGi Service Registry."
How to understand it correctly?
I have seen many times that an user has such a requirement from glassfish community.
Eg. today's afternoon, Sahoo and I together invesitigated an OSGi/CDI issue from glassfish community. Let us see how the user does,
He has a bundle called "A" as OSGi Service provider, and I list the logic of one of publishing OSGi Service,
@Named
@RequestScoped
@Log
@TimeStamp
@Component(name = "Item Processor")
@Service
public class ItemProcessor implements ItemProcessorSvc {
@Inject
@Demo
private ItemDao itemDao;
@Inject
private ItemValidator itemValidator;
@Inject
@Notify
private ItemErrorHandler itemErrorHandler;
@Inject
private Event<Item> eventProcessor;
...
Here, he uses Declarative Services to register ItemProcessor as an OSGi service, and being more important, he wishes that before registering, the instance of ItemProcessor can inject ItemDao using normal CDI way. However, up to now, I have not still seen this SCR-CDI's bridge, so, after registering ItemProcessor as an OSGi service, once you use @OSGiService to obtain the service and try to invoke ItemProcessor's method, you will see a NPE happen because at the point, itemDao field of this ItemProcessor service is NULL.
So, not only being Declarative Services , OSGi/CDI integration also needs this bridge and this is why CDI002 is very important! And just as "2.3 Declarative Services, Blueprint and CDI" saying:
"...It also makes sense to consider creating similar complementary relationship between their containers and the CDI container for runtime injection processing..."
2) not understanding requirements
Among these function requirements, there are some requirements I can not still understand as following:
- "CDI006 – The specification MUST make it possible to write a portable CDI jar that runs both in JavaEE as well as in OSGi."
I want to ask that here, "portable" has any special meaning?
- "CDI007 – The specification MUST consider the thread-safety issues that can arise when migrating CDI beans from JavaEE to OSGi."
Here, I think that Specification should state a concrete scene about "thread-safety issues" .
4 About "5 Technical Solution"
1) a miss?
I found that on the image "Publish CDI bean as OSGi Service", whether "@OSGiService" should be "OSGiComponent" or not?
2) about "Dependency injection callbacks"
I like these callbacks very much because this made our applications more felixable and dynamical. I have seen many times that an user wants to use such callbacks to dynamiclly extend his application rather than re-deploying the whole application. However, it seems to miss a group of callback apis - Service Updating Callback Apis
Finally, I felt that the draft has forward a big step to the final!
Thanks OSGi EEG's hard effort!
Comments