2011/1/28 Richard S. Hall <he...@ungoverned.org> > On 1/28/11 8:56, teemu kanstren wrote: > >> Thanks Richard for the nice set of slides and congrats. Just a few >> comments >> on the slides (I admit I do not know that much about OSGI but at least I >> read some docs sometime :)) >> >> -In the beginning you mention legacy code and how it is naughty to use >> stuff >> like Class.forName. I think several frameworks use such reflection tricks >> and whether they are legacy code or not sometimes I need to use them. >> Recently my experience has been so at least with Apache XMLRPC and some >> REST >> frameworks (Jersey/Restlet). This seems really hard to fix when there is >> no >> support from the framework but if you need that technology what do you do? >> Is everything legacy if it is not OSGI tested? >> > > Legacy code is anything that was not written with OSGi in mind, but > problematic legacy code is code that makes assumptions about type visibility > or code lifecycle. > > Legacy code is not always problematic. If you just have a library that > provides types and doesn't try to dynamically load other classes, then it > will probably work fine once you convert it to a bundle. > > OK, thanks for the clarifications on the slides! Since, for me, this seems to be one of the most common issues to run into, I think it would be great to see some "best practices" documented somewhere for how to deal with this. Perhaps even some pointers for "if you need this, here are some experiences from some user on how to make it work..". Could be general cases or specific to some libraries etc. Would greatly help me "ignore" OSGI. Not really something to do for your slides but I think to help people use OSGI these are maybe the more painful things that they will need to manage. For me it has been anyway.
> > -You talk about lifecycle and how you can implement your own, mentioning >> that the rules will just be enforced by "you" then. The previous slide >> talks >> about resource management. Does OSGI actually enforce some resource >> management rules such as checking what threads/files/etc are created and >> when? >> > > No, there is no enforcement, mainly because this is difficult, if not > impossible, to do in Java. For OSGi, the bundle activator is the contract > that says you won't do stuff like threads, sockets, etc. until you are > started and not after you are stopped. > > The resource management would be great, but I agree it is too hard without better support from the JVM. But for the slides I was left a bit wondering what was the contract management that Felix (or OSGI in general) would do for me. Of course, someone will probably present the slides so that should be no problem to explain. Teemu
