On 1/31/11 3:01, teemu kanstren wrote:
2011/1/28 Richard S. Hall<[email protected]>
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..".
The slides do include suggestions if you need to dynamically load classes...
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.
More documentation would definitely be welcome.
-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.
In the slides, I specifically say that your code should not use
resources before its start() is called and should not use any after
stop() is called.
-> richard
Teemu
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
