|
Replies:
5
-
Last Post:
Sep 26, 2007 12:42 AM
by: Kirk Turner
|
|
|
|
|
|
|
Some thoughts about the modules design
Posted:
Sep 24, 2007 9:04 AM
|
|
|
As I noticed in the current implementation, I don't feel good in the modules design.
Currently, the modules object instances are serialized and stored in the SGS server side. When one user connects to the server, it will receive the byte codes from server of these instances. The client will then turn them to the local instances.
Have some noticed something incorrect?
If the objects class stored in server side doesn't exist in the client side, what will happen? Yes, ClassNotFound exception is thrown.
This is a common scenario.
Suppose we are building a extendable virtual community and everything can be added dynamically by both users and server admin. One day the server wants to provide a new module to its users, it will transfer them to the client. But the client's class path doesn't involve the new class. How to resolve it?
In the current design, I'm afraid the server may now send a request to the user to ask user to download the jar file and install them first. But what if user delete the module, how to judge it. In another way, the classpath setup is not so easy for the normal user, end user shouldn't take the responsibility.
So what i'm thinking about is to add a new class loader for the wonder land and all extendable modules and new libraries should be loaded by the new class loader.
It may have the following features:
1. Save the java Class bytes in the local user space in order to avoid the access rights problems.
2. It can compare the server side and client side class difference and handle the version/updated date problems. It means when server updates the module, the client may catch up the update when it connects to the server.
3. It can not only handle the Class bytes but also the referenced libraries. It means when the module relies on a third party library, it can get it properly according server's information and set it up well. The furthur step is to handle the third party's version change and dependancy according the problems provided by server.
4. A certain policies may exist to control whether the client should use or not use the modules, should update or not update the modules,should stick or not stick a certain version, just like the deb management system!
5. The server side should have the ability to send enough control messages to the client side to satisfy the requirements above.
If this is implemented, the wonderland will become an exciting place that users may design their own modules and upload them to the server. The server may dispatch the new modules from time to time. The wonderland world may be empty and lack of interesting stuffs, but the users and server admin can then create them to fill the virtual world! The initial client may be small,but it's powerful because it can plug as many as the user wants. It's just really like a micro-kernel design in user application's impelemtation!
What do you think about the idea? If you're busy to do that, I think I can help to do it if you think it's valuable to do.:)
Message was edited by: popeyelin
|
|
|
|
|
|
|
Re: Some thoughts about the modules design
Posted:
Sep 24, 2007 6:24 PM
in response to: popeyelin
|
|
|
Are there any people being interested in it?
|
|
|
|
|
|
|
|
|
Re: Some thoughts about the modules design
Posted:
Sep 24, 2007 7:02 PM
in response to: popeyelin
|
|
|
This is definitely an interesting area. The existing module system was designed with the thought that we would eventually develop a more fully featured system, like the one you are describing.
Internally, however, we have been using Java Web Start, which does many of the things a module system would need to do. On the client side, Java Web Start manages downloading jar files, handles versioning, and caches files until they change. On the server side, our build scripts contain a "pkg-webstart" target that automatically sets up the appropriate jar and jnlp files. It also creates compressed files for a shorter download. I have been meaning to post a howto about setting up Java Web Start for Wonderland, which I will try to do in the next little bit.
Java Web Start is good, but it has some downsides. Right now, both the client and server must be restarted to recognize a new cell type. Also, the build scripts need to be updated to only rebuild jar files that have changed -- right now they rebuild all jar files. A Servlet should also be written to use the packed jar files.
If you are interested in developing a more complete module system to allow dynamic loading, we would welcome the contribution. I would love to see a design document we can all comment on (like Jordan did with WFS). To help get started, I have also included an email I wrote to the team a while back on the subject of modules.
Goal
The goal of a Wonderland module system is to make it easier for developers to add new cell types to a Wonderland world. Specifically, a developer should be able to create a new cell type, package it into a module, and deploy that module to an existing Wonderland server with minimal modification. Once deployed, a module should allow the use of the custom cell classes, both client and server, in any part of the world from any client connected to that world.
Wonderland module
A module should be a single archive file with a manifest that defines meta-data about that file. I propose using a jar file with a custom extension, such as ".wlm" for Wonderland module. A module should contain the following data:
- all classes and resources required for the server cell
- jar file(s) containing library dependencies
- jar file(s) containing classes and resources required for the client cell
- jar file(s) containing library dependencies for the client
Additionally, the following meta-data should be specified in web.xml:
- the name and version of the module
- the name and class of all new cell types provided by this module
- the name of any module (cell type?) required by this module
- the location in this jar file of any library dependencites
- the location in this jar file of any client jar files or library dependencies needed by the client
Given this data, a Wonderland module can be installed by simply placing the module in a well-known directory and restarting the server. Future work could include dynamically loading and unloading modules.
Within Wondlerland, a CellManager would be provided to allow easy instantiation of new cell types, either from a parent cell class or an XML file.
Implementation
On the server side, the Wonderland modules will need to be read in and loaded at startup time. Each module will need to be loaded into it's own classloader (to prevent problems with overlapping class names and prepare for future unloading). As the modules are unpacked, client jar files should be exported via a web server. The URLs for the client jar files can then be added to the cell setup information for the new custom cell types.
For the server, I've been looking at two approaches. We can either roll our own support, or use an existing module framework.
To create our own module system, we need to handle loading and dependencies ourself, which is not too hard. We will also need to create a Darkstar service to export data to a web server, either using an embedded server like Jetty or an external instance of Apache. This will give us something that fits into the Darkstar framework pretty well, and the Web Server service might be reusable in other contexts.
I've also started looking at the Apache Felix project, which contains an OSGI module system. This would support all the use cases we need, and even has an existing Web Server service based on Jetty. The downside is that the modules are a little more complicated to build and Felix provides a separate service infrastructure that may have issues on the Darkstar server.
On the client side, when a cell is downloaded, the client jar files specified in the cell setup information will be downloaded first, and the class will be dynamically loaded in a new class loader for that cell type (or for the module). This may present limitations on how cells loaded from different modules can interact , but common interfaces should be available.
|
|
|
|
|
|
|
|
|
Re: Some thoughts about the modules design
Posted:
Sep 24, 2007 8:02 PM
in response to: kaplanj
|
|
|
Actually I think it's a more general extendable module design for java system.
JavaWebStart is good but not enough to satisfy these requirements.
The Apache Felix is interesting and I'll try it then to evaluate if it's good to do that.
For the concern about the dark star service, in my opinion and preliminary understand, the dark star service only indicate the client it should update ,where to update and what to update. The client will then turn to proper server to update. The proper update server may be a JavaWebStart server/Apache Felix server/or other servers home brewed by wonderland team. 
I will try to compare these solutions and try them. I hope I could draw a conclusion and write some design that can be commented by others.
|
|
|
|
|
|
|
|
|
Re: Some thoughts about the modules design
Posted:
Sep 25, 2007 5:13 PM
in response to: popeyelin
|
|
|
Great thanks Popeylin, it will be great to have you reviewing the various technologies to determine the most appropriate.
A few others I would suggest you investigate
Java Kernel http://72.5.124.55/developer/technicalArticles/javase/consumerjre/#JavaKernel
The netbeans module system
I'm not sure either can be extracted from their current projects to be used standalone but you never now.....
Cheers
Paul
|
|
|
|
|
|
|
|
|
Re: Some thoughts about the modules design
Posted:
Sep 26, 2007 12:42 AM
in response to: paulby
|
|
|
|
|
>
> Great thanks Popeylin, it will be great to have you reviewing the various
> technologies to determine the most appropriate.
>
> A few others I would suggest you investigate
One more -> LG3D - Paul and I worked on a dynamic class loader for lg3d to
allow dynamic (re)loading of apps from the system. It has a few caching
issues with window's systems (actually related the jar file systems), but it
would be worth looking at to extend (it is based upon the URL Classloader,
so should be appropriate for loading from the server(s)). One of the reasons
for using our own for lg3d was to separate out the user space from the
desktop - and this concept would be useful for wonderland as well, to enable
only certain extensions.
Kirk
[att1.html]
|
|
|
|
|
java.net RSS
