classpath
[Top][All Lists]
Advanced

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

Re: please test: XMLEncoder patch - version 2


From: Stuart Ballard
Subject: Re: please test: XMLEncoder patch - version 2
Date: Mon, 9 Jan 2006 16:04:29 -0500

In a 1.5 world you could define an annotation to put on classes that
have persistence delegates so that you only have to handle them when
an object of that type is encountered, and the central code doesn't
have to be aware of them at all.

I'm not directly familiar with the Java syntax for such things, only
the .NET equivalent, as I haven't done any Java 1.5 coding yet, but I
think it would look something like this:

@interface PersistenceDelegateClass {
  Class delegateClass();
}

...

@PersistenceDelegateClass(delegateClass=JButtonDelegate.class)
class JButton extends ... {
  ...
}

Then you have some code in the XMLEncoder that looks for the
annotation on the class of each object it tries to persist and finds
the encoder that way.

Stuart.

On 1/9/06, Robert Schuster <address@hidden> wrote:
> Hi Roman,
> the PDs have to be registered to make out-of-the-box encoders (new
> XMLEncoder(...)) be able to process instances of those classes. However: If 
> you
> want to split Swing out of the class library there is no point in trying to
> register a PD for them since the class isnt there anyway.
>
> I prepare a patch that will resolve this issue by using Class.forName() which 
> is
> allowed to fail for such classes.
>
> Btw: Currently the encoder relies on the StAX implementation. If someone 
> decides
> to rip that out one has to provide an alternative 
> gnu.java.beans.encoder.Writer
> implementation.
>
> cya
> Robert
>
> Roman Kennke wrote:
> > Hi Robert,
> >
> > Is it really necessary to directly reference all those classes in
> > java.beans.Encoder.setupDefaultPersistenceDelegates()? Can you explain
> > what this method does and why the encoder won't work without these
> > persistent delegates? I am asking, because we had discussions about
> > breaking down the class library in the past, and pulling in e.g. Swing
> > by dependencies in java.beans looks ugly to me. Can the same effect be
> > achieved without directly refererring to those classes?
> >
> > Cheers,
> > /Roman
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
>
>
>
>


--
http://sab39.dev.netreach.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]