You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2001/03/16 01:34:16 UTC
Proposed Store changes...
I've talked this over with the big Guns of Avalon, some month back and tried a couple of suggested
solutions (including thread context based ones), but nothing worked for the unique situation I had
at the time.
The problem re-interated is that Jesktop (block) mounts many of it's own classloaders for
hot-installable and hot-upgradable apps. Some of them want to persist data, and the persistence
store is the obvious place to do it. The trouble is that a ClassNotFoundException was always
thrown because the Store couldn't work out which of the ten or so different classloaders had the
definition of the class. Thread.setContextClassLoader(..) didn't work either.
What was tested at the time, but objected to because of inelegance was a way of passing in the
classloader for use _during_ the internal store code to deserialize objects. I tested it and it
worked, but under pressure from said guns, tried other things. Then I moved countries, jobs, went
on a diet and saw thru a heavy winter ;-) Now, older and wiser, I'd like to re-propose a tuned
additonal get() method for store:
1) ObjectRepository (interface ) -> new method ->
Object get( String key , ClassLoader classLoader );
2) File_Persistent_Object_Repository (class) new method :
public synchronized Object get( final String key , final ClassLoader classLoader )
{
......
}
3) File_Persistent_Object_Repository (class) new inner class :
/**
* A special ObjectInputStream to handle highly transient classes hosted by Avalon components
* that are juggling many classloaders.
*/
private class FileStoreObjectInputStream extends ObjectInputStream
{
private ClassLoader classLoader;
private FileStoreObjectInputStream(ClassLoader classLoader, InputStream in)
throws IOException, StreamCorruptedException
{
super(in);
this.classLoader = classLoader;
}
protected Class resolveClass(ObjectStreamClass v)
throws IOException, ClassNotFoundException
{
Class cl = Class.forName(v.getName(), false, classLoader);
if (cl !=null)
{
return cl; // the classloader knows of the class
}
else
{
// classloader knows not of class, let the super classloader do it.
return super.resolveClass(v);
}
}
}
What's thought of this?
=====
Regards - Paul H
====
CVS -1, Perforce +1
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed Store changes...
Posted by Charles Benett <Ch...@benett1.demon.co.uk>.
+0 ie go for it!
Paul Hammant wrote:
>
> I've talked this over with the big Guns of Avalon, some month back and tried a couple of suggested
> solutions (including thread context based ones), but nothing worked for the unique situation I had
> at the time.
>
> The problem re-interated is that Jesktop (block) mounts many of it's own classloaders for
> hot-installable and hot-upgradable apps. Some of them want to persist data, and the persistence
> store is the obvious place to do it. The trouble is that a ClassNotFoundException was always
> thrown because the Store couldn't work out which of the ten or so different classloaders had the
> definition of the class. Thread.setContextClassLoader(..) didn't work either.
>
> What was tested at the time, but objected to because of inelegance was a way of passing in the
> classloader for use _during_ the internal store code to deserialize objects. I tested it and it
> worked, but under pressure from said guns, tried other things. Then I moved countries, jobs, went
> on a diet and saw thru a heavy winter ;-) Now, older and wiser, I'd like to re-propose a tuned
> additonal get() method for store:
>
> 1) ObjectRepository (interface ) -> new method ->
>
> Object get( String key , ClassLoader classLoader );
>
> 2) File_Persistent_Object_Repository (class) new method :
>
> public synchronized Object get( final String key , final ClassLoader classLoader )
> {
> ......
> }
>
> 3) File_Persistent_Object_Repository (class) new inner class :
>
> /**
> * A special ObjectInputStream to handle highly transient classes hosted by Avalon components
> * that are juggling many classloaders.
> */
> private class FileStoreObjectInputStream extends ObjectInputStream
> {
> private ClassLoader classLoader;
> private FileStoreObjectInputStream(ClassLoader classLoader, InputStream in)
> throws IOException, StreamCorruptedException
> {
> super(in);
> this.classLoader = classLoader;
> }
> protected Class resolveClass(ObjectStreamClass v)
> throws IOException, ClassNotFoundException
> {
> Class cl = Class.forName(v.getName(), false, classLoader);
> if (cl !=null)
> {
> return cl; // the classloader knows of the class
> }
> else
> {
> // classloader knows not of class, let the super classloader do it.
> return super.resolveClass(v);
> }
> }
> }
>
> What's thought of this?
>
> =====
> Regards - Paul H
> ====
> CVS -1, Perforce +1
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Proposed Store changes...
Posted by Peter Donald <do...@apache.org>.
+1 but don't use inner classes as not all compilers deal with them
gracefully ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org