[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some question about OODBMS,JDO,J2EE EJB

On Tue, 15 May 2001, Sean Allen wrote:
> On 15 May 2001 11:31:52 +0200, Falko Braeutigam wrote:
> > On Sun, 14 May 2000, shiyiying wrote:
> > > I think I can do .But At frist, I must take some time to study ozone's source code.And 
> > > Can somebody give some guidance on how to start development about ozone?
> > > My mother language is chinese, and my english is poor,so I'm afraid I can't express my 
> > > idea with english well.
> > 
> > Ha, that's the problem of many, if not most people here (including me). So,
> > don't worry!
> > 
> > > If someone can put  deployment principles in a proposal , I can implements it and extend
> > > these principles in the development process.
> > 
> > In fact, today a real deployment model does not exist in ozone. Two things
> > just have to be completed to make classes run in ozone:
> > 
> > 1) build the proxies for the database classes (using OPP)
> > 
> > 2) make the classes (database, ordinary and proxies) available to the VM of the
> > ozone server (simply via CLASSPATH)
> > 
> > This is easy and straight forward but has some drawbacks:
> > 
> > 1) the classes has to be in the CLASSPATH
> > 
> > 2) in some environments (servlet container) the ClassLoader does not work "as
> > expected"
> > 
> > 3) proxies must be generated explicitly
> > 
> > 4) the server cannot distinguish between one and another application. This is
> > useful if we want to have more than one app running in one server.
> > 
> > Before we are going to try to make a deployment model we should throw
> > together and discuss the drawbacks of the current solution and make a list of
> > things that the future solution should be able to handle. So, please, your
> > comments guys!
> > 
> I have used jBoss EJB server recently, and they have a "deploy"
> directory that automagiacally picks up jar files you put into it, 
> I guess ejb has deployment descriptors and the semantics of those helps
> the container do this, 
> but would there be any reason something like this wouldn't work with
> ozone, assuming classes were developed normally (i.e. Foo, FooImpl then
> OPP) 
> say by
> polling a directory under the tree with a low priority thread.
> if a jar file appears in directory
> 
>     if so, instantiate OzoneDeployClassLoader and add the classes in the
>     file to the VM.
>     do the classes extend OzoneObject and OzoneRemote 
>     if so, add them to the Database
>     .   
> any reason you can think of Falko, why something like this wouldn't
> work?

Just one, so far. There are still ClassLoader issues in ozone. It's tricky to
rework the code in order to be able to use CLassLoaders to drop and reload
classes. All 'relevant' classes have to be loaded by the same CLassLoader.
Otherwise things like 'instanceof' operator, which is widely used, does not
work as expected.

To come around this (and as a possible improvement) we could initialize an
_entire_ ozone instance for each deployed app. Using one ClassLoader for the
entire ozone instnance and drop the entire ozone instance when un/redeploying.
This would also allow to share one VM for several 'servers'.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com