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.
-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.
-You discuss transitive dependencies and uses constraints. What is a "uses"
constraint? I do not see it explained in the slides and I though it was only
import or export in OSGI.
This isn't explained in the slides. I am still planning to improve those
last few slides. See the discussion here:
http://www.osgi.org/blog/2011/01/error-messages.html
In short, a "uses" constraint is a package-to-package dependency. If you
think about Import-Package and Export-Package, these express
bundle-to-package dependencies. "Uses" constraints go one level deeper
and express the internal package-to-package dependencies. For example,
the org.osgi.service.http package has a "uses" constraint on the
javax.servlet package, because it uses the javax.servlet.Servlet type.
This level of dependency information is necessary to ensure that bundles
do not see more than one version of the same type. Assume I have an HTTP
Service bundle exporting org.osgi.service.http and importing
javax.servlet. Then assume I have a client bundle importing
org.osgi.service.http and javax.servlet. If you satisfy these
dependencies separately, it is possible that the client bundle could
wire to a different version of javax.servlet than the HTTP Service
bundle. If this happened the client and the HTTP Service would receive
class cast exceptions when collaborating. "Uses" constraints make it
possible to detect such situations and avoid them.
-Thanks for the few pointers on using the gogo shell. I never found such an
explanation of how to use the gogo shell on the Felix website so I am always
completely lost with what it is and what I could do with it :). Maybe you
could write something similar for the website, just a bit more extensive?
This would probably be worthwhile too. :-)
-> richard
That's all for me..
Teemu
2011/1/20 Richard S. Hall<[email protected]>
After some recent experiences I had with some developers trying to use OSGi
without even understanding the basics, I decided to work on a presentation
highlighting what you must understand about OSGi to use it. Please find it
on the presentations page:
http://felix.apache.org/site/presentations.html
The direct link to the PDF is here:
http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
Comments welcome.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
