Sam Chance wrote:
Gregg,
It is not my desire or intention to try to play "technology ping-pong." I'm
only introducing another viewpoint. Frankly, I don't have time to read
long, verbose emails. I've touted enough OSGi technology attributes to
intrigue those who might be interested in learning more. The answers to
your questions can be found on the OSGi Alliance's web site - and I promise
you there are solid answers. Additionally, a number of books that provide
ample OSGi coverage are either recently published or nearing publication.
Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and others
offer a lot of informative OSGi literature as well. Neal Bartlett also
provides a lot of OSGi resources. Eclipse [Equinox] and Apache Felix are
great places as well.
Happy Learning! :-)
Sam
On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <[email protected]> wrote:
Sam Chance wrote:
In fact, OSGi does help a lot with "Classpath Hell".
I didn't see a reply from my earlier request for more information on the
issues that the OSGi experienced think OSGi helps the most with regarding
this issue. I'd really like to see what issues you all have had and that
OSGi has addressed.
Is it just that packaging encloses the set of things you need to make
things work and you don't have to worry about that, or is it something else?
Many containers use ClassLoader hierarchies of various shapes to isolate
and "interrelate" different types of package structures. I'm just
interested in knowing more about the issues and benefits you all recognize
from your experiences.
OSGi also adds another layer of security above the standard Java.
What do you feel is important about this? Authentication vs Authorization
issues would be great to have your opinions and experience on.
Versioning is a "first-class function" in OSGi.
This is a big deal for separating old and new. I think we have a good bit
of this in the PreferredClass mechanisms in Jini 2.x so that implementations
can be forced into use for bug fixing and interfacing with different
versions of difference services. Is there anything else beside classloader
based separation that you all find important in what OSGi provides?
There seems to be two or three topics here getting confused?
Firstly, the classloader is the source of many problems isn't it?
Thanks Gregg, for the info on the PreferredClass mechanisms in Jini, it
gave me something with some meat to follow up, I wasn't aware of it
until now.
I'm reading Gregg's email as well as yours Sam and following up on the
links, please be considerate/respectful of others viewpoints.
When I mentioned class versioning support changes in the JRE required to
support project Jigsaw, I hadn't realised that the Module versioning
information of Jigsaw didn't extend all the way down to bytecode and
class files, my misunderstanding, I had hoped that class file versioning
could provide an answer to problems with new codebases and old objects
and vica versa.
Thanks to the tip from Gregg, I've found a good research paper (Michael
Warres) that describes the issues with Classloading and their relevance
to Jini at: http://research.sun.com/techrep/2006/smli_tr-2006-149.pdf
PS are we authorised to upload this onto the River site? Are there other
similar papers?
My original thought process was along the lines of being able to discern
between different versions of classes loaded from codebases with the
same fully qualified class names.
Could we create a tool that added codebaseVersionID final variables to
class files for exteral sourced libraries, perhaps using ASM? This
along with the serialVersionUID could be used to determine the
compatibility and dependency tree of the codebases for individual
classes. We could use Annotations as suggested by Michael Warres in our
own code then to manage inter class and package dependencies? Then
perhaps we could cache available codebases in clients in case http
codebase servers go down or maybe make the codebase servers more dynamic
so codebases don't go missing when some codebase servers fail?
How hard would it be to create a tool that parses the source code for
new developers to do this for them, you know all javadoc comments must
have a @version number at the top of the class? After they compile
their code and confirm its working, the tool could create the
codebaseVersionID variables for them, based on a configuration file for
external libs? You said that code mobility is difficult how can we make
it easier? classdep?
How can we fix the above problem based on reccommendations by Michael
Warres?
Secondly:
OSGi - uses a services model to solve single VM packaging problems,
doesn't it? That is; export services that can be used by other OSGi
modules (independant applications / libraries of services) to build
applications from.
River - uses a services model for distributed computing.
Was there proposal to create an OSGi compatible module that acts as a
Facade to host River distributed services to OSGi applications that
otherwise wouldn't be capable of taking advantage of network aware (the
8 fallacies of distribute computing) redundancy capabilities? What is
the use case for this? Is this for a service that is critical to a
particular application (from performance or redundancy perspective) that
may be subject to failure and the abilities of River to run multiple
services. An OSGi based application that has outgrown it's roots so to
speak, parts of it can be rewritten based on River? What issues would
arrise due to remote objects?
So this OSGi module could then act as a Facade, that used the Lookup
Service to make redundant services available to OSGi to improve the QOS,
service reliability, performance to OSGi based applications?
Is this what the debate is about or have I missed something? I doesn't
require changes to River, just a new OSGi module that can be downloaded
by the OSGi application developer who can start writing some River
services for his/her existing OSGi based application?
Going in the other direction, someone could write an OSGi based
application that provides services to a distributed River network for
the export of value objects (simple data objects) over a River service
yes? In which case the distributed applications running on River don't
need to be OSGi aware? The http codebase server would need to have
class file copies of the value objects however.
Cheers,
Peter.
Gregg Wonderly
