tag:blogger.com,1999:blog-9889008.comments2012-05-31T06:42:58.198+03:00Toshohttp://www.blogger.com/profile/15953962426979160976noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-9889008.post-26015438293835004472012-05-31T06:42:58.198+03:002012-05-31T06:42:58.198+03:00Wer&#39;e building a framework which is OSGi-ready from scratch: http://nibiru.googlecode.com<br /><br />:)Lautarohttp://www.blogger.com/profile/14686482914510075595noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-87435311977224451352011-03-14T03:22:54.877+02:002011-03-14T03:22:54.877+02:00Having used OSGI in a few web projects, I can certainly say that getting started with OSGI is certainly a pain. This is especially true when you mix frameworks (like Hibernate) that needs requires looking up classes from configurations.<br />The web support (atleast two years ago when I started using it) is/was certainly lacking as Spring DM for OSGI doesn&#39;t support (out of the box) commercial (atleast Weblogic) WASes.<br /><br />Still, I think it&#39;s worth the effort because once you set it all up (atleast with Spring DM for OSGI for us), there really isn&#39;t too much interfacing with OSGI anyways, but you still get the nice modular infrastructure.Uhyon Chunghttp://www.blogger.com/profile/12350781560598367516noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-11048021422297771092010-03-09T16:24:00.283+02:002010-03-09T16:24:00.283+02:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-89744925552774254492010-01-22T23:20:12.835+02:002010-01-22T23:20:12.835+02:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-87092266808484337832010-01-11T23:25:00.797+02:002010-01-11T23:25:00.797+02:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-23234427873352788132009-11-21T19:21:14.347+02:002009-11-21T19:21:14.347+02:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-47423717661815447622009-11-21T05:20:05.559+02:002009-11-21T05:20:05.559+02:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-1543623461156933202009-07-14T12:22:02.780+03:002009-07-14T12:22:02.780+03:00Yes, you&#39;re right, it is supposed to be fixed, but I didn&#39;t check it. <br /><br />Concerning your additions... very important things to consider. I think there is little to no documentation of best practices, so here are my 2 cents:<br />- in what order (if any) should extenders act: I don&#39;t think there should be any constraints at all. OSGi is so dynamic, we should keep it as flexible as possible without putting more and more constrains in, not obvious for users and developers<br />- what to do when multiple versions of the same extender are around: Just don&#39;t do it or if there is a chance of having such scenario use the singleton flag to enforce only one (of course only the bundle provider can do this)<br />- what to do when an extender goes away or is updated: Interesting one! Well, I set a specific flag for registered services by the extender. When the extender gets updated it checks if such a service was already registered. Depending on the update, it might be necessary that the new extender removes the old services and registers newer versions, but this should be part of the updated extender logic - dealing with updates.<br /><br />A last, but interesting edge case is when a fragment has the meta data for the extender and the host should get certain services registered. Tracking changes and updates suddenly gets a little more complicated then ;-)<br /><br />However, great summary!Mirkohttp://www.blogger.com/profile/05180331822627058711noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-40885617546192139442009-07-14T09:57:17.391+03:002009-07-14T09:57:17.391+03:0010x for the supplements :) <br /><br />I believe the concurrent class loading issue was recently fixed, but I&#39;m not sure in which JDK we can find the fix. Still there are plenty of JVM&#39;s out there, which can deadlock :P<br /><br />There are is in fact a greater problems with extenders: how does a bundle require an extender, in what order (if any) should extenders act, what to do when multiple versions of the same extender are around, what to do when an extender goes away or is updated... Naturally none of these should stop us from having fun extending. <br /><br />These issues have recently started their way through the OSGi alliance specification pipeline. I hope in the near future we will have a specification that cements the extender model as an equal peer to the current service model.Toshohttp://www.blogger.com/profile/15953962426979160976noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-83180621679751950442009-07-14T00:45:37.387+03:002009-07-14T00:45:37.387+03:00Great article! Just two minor things worth mentioning. <br /><br />1. The upcoming OSGi R4.2 will include an API to track bundles (which is the perfect method creating extenders)<br />2. Having multiple extenders in the same OSGi runtime can cause problems. When loading classes, the JVM puts a lock on the class loader rather than the actual class, which might cause two extenders in different threads creating a deadlock. Eclipse has a property to set the lock on the ClassName to work around this issue. (just a property that has to be set)Mirkohttp://www.blogger.com/profile/05180331822627058711noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-80803868826299486512009-06-26T09:05:57.443+03:002009-06-26T09:05:57.443+03:00I appreciate the praise :)<br />Do read the refinements to this entry:<br /><br />http://rinswind.blogspot.com/2009/06/shutdown-deterministic-vs-fuzzy.htmlToshohttp://www.blogger.com/profile/15953962426979160976noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-51766965479205533452009-06-25T17:16:36.083+03:002009-06-25T17:16:36.083+03:00That was a pretty awesome writeup. Thanks!Holger Hoffstättenoreply@blogger.comtag:blogger.com,1999:blog-9889008.post-24995161330485648142009-06-24T10:01:59.220+03:002009-06-24T10:01:59.220+03:00As the first official commenter on my blog you deserve a response :)<br /><br />To be completely honest I did scorn Eclipse a bit too much. The main reason being to point out that life is simpler with the classical OSGi services. People using Eclipse as their introduction to OSGi confuse the complexity of Eclipse architecture with complexity within OSGi itself.<br /><br />As for the Eclipse registry: as far as I know although it is maintained by a bundle Eclipse extensions and OSGi services can not interoperate. One way to transparently mix extensions and services appeared quite recently:<br /><br />http://code.google.com/p/peaberry/wiki/EclipseRegistry<br /><br />Otherwise I was thoroughly amazed when I discovered what was going on with Eclipse. Now I look at the active part of the bundle lifecycle: starting-&gt;active-&gt;stopping as &quot;the extender realm&quot;. The OSGi service layer itself can be viewed simply as the default/bootstrap extender. I have plans to blog about this some day.Toshohttp://www.blogger.com/profile/15953962426979160976noreply@blogger.comtag:blogger.com,1999:blog-9889008.post-62881653513332688082009-06-23T19:35:06.055+03:002009-06-23T19:35:06.055+03:00I disagree a bit. I think Eclipse is a great example of what you can do with OSGi. The extension registry itself is exposed as an OSGi service... and built upon the service layer... just like things like DS. The extension registry was available before Eclipse really moved to OSGi, so there is some legacy there.<br /><br />In the end, I think Eclipse demonstrates the power of OSGi and modularity. The Eclipse SDK evolves and maintains backward compatibility due to the power of OSGi.<br /><br />I think Caucho&#39;s main problem was that modular architectures aren&#39;t easy... especially when you come from a world that didn&#39;t have them before. Also, your point of &quot;you either let OSGi manage all the class loading for you or not use OSGi&quot; is very important and people coming from legacy backgrounds usually get bit with this problem.<br /><br />Oh well, in the end it&#39;s fun to see people finally discussing OSGi ;)Chris Aniszczyk (zx)http://www.blogger.com/profile/14067673601779593093noreply@blogger.com