tag:blogger.com,1999:blog-1375633167426904536.post2455536646539100782..comments2023-12-21T10:45:27.103+00:00Comments on The Impala Blog: Spring Exchange 2008 in LondonPhil Zoiohttp://www.blogger.com/profile/06867992322338887577noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1375633167426904536.post-35959002375214374172008-01-17T16:29:00.000+00:002008-01-17T16:29:00.000+00:00Peter,I am not faulting OSGi in these comments. En...Peter,<BR/><BR/>I am not faulting OSGi in these comments. <BR/><BR/>Enterprise apps have been developed for years without OSGi. Libraries used in enterprise development have been developed for years without OSGi. When you have libraries and frameworks which have idiosyncrasies designed for a pre-OSGi world - I'm thinking of classloaders mostly, but also coding and library design conventions - it is not always straightforward to retrofit these into a new technology where these tweaks are not relevant. <BR/><BR/>On to the examples. I understand that it is difficult to get Hibernate to work with OSGi. Hibernate, for it's faults, is more established in Java enterprise world than OSGi. Another is in the export of packages. Libraries work better with OSGi if they separate put their interface and implementation classes in separate packages. This of course is good practice, but library developers would not necessarily have paid such close attention to it in a pre-OSGi environment. Another example, I understand, is there are difficulties with OSGi and marshalling RMI. Another example is bundles: where am I going to get OSGi compliant bundles for libraries, nicely set up to export all necessary packages, for all the libraries I use on a day to day basis? Perhaps there is a Maven-style repository somewhere which reflects all the necessary hard work - done - but I somehow doubt it.<BR/><BR/>Unfortunately for me, I don't understand enough about these problems to know how much of a problem they are, or indeed whether they are problems at all. <BR/>My concrete examples are based largely on anecdotal evidence, based on speaking to people who <I>have</I> had real experience. But therein lies the problem - the immaturity of OSGi is largely an immaturity of knowledge, rather than the technology itself. Most of the developers I work with in my day job have never heard of OSGi, let alone used it. At the Spring exchange I don't remember seeing more than a handful of hands go up when people were asked if they had used OSGi (of course, everybody uses Eclipse, but that's different).<BR/><BR/>My impression, and I have to confess it is only an impression, is that there is still a plenty of pain to go through, plenty of best practices to figure out, and plenty of conceptual hurdles to leap before OSGi is a smooth out the box experience which truly delivers without draining productivity. A couple of books on the subject would be nice! <BR/><BR/>In the meantime, somebody still has to go through the pain. At the end of the day, I'm sure we will all decide that it has been worth it.<BR/><BR/>For me, it is not a question of the immaturity of OSGi, but of the maturity of combination of OSGi as and existing enterprise libraries as a potential lingua franca of Java enterprise development.<BR/><BR/>I don't mean to sound negative. It's a good thing for OSGi that after all these years, it's threatening to make the breakthrough. But don't expect it to be painless.<BR/><BR/>Regards,<BR/>PhilPhil Zoiohttps://www.blogger.com/profile/06867992322338887577noreply@blogger.comtag:blogger.com,1999:blog-1375633167426904536.post-62515777016185622012008-01-17T15:41:00.000+00:002008-01-17T15:41:00.000+00:00You comment that OSGi has to go through many growi...You comment that OSGi has to go through many growing pains in the Enterprise market. Could you give some concrete examples?<BR/><BR/>We have gone through a requirements phase in the OSGi and have found very few deficiencies in the core. There are obviously many interesting optional functions to add but I am curious why you think OSGi requires more maturity after almost 10 years ...<BR/><BR/>Kind regards,<BR/><BR/> Peter KriensPeter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.com