commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gray, Andrew (ITDA)" <andrew.g...@DEFRA.GSI.GOV.UK>
Subject RE: betwixt files doesn't work with inherited Interfaces
Date Fri, 06 Aug 2004 10:55:15 GMT
Hi Robert,

Not sure what you mean by a normalizer, but the other part is certainly
correct - I need the introspecter to discover methods declared in the

I've attached the files I edited to provide me with an immediate workaround
(afraid firewall prevents CVS access, so patch files not easy)

I've not tried this with an abstract class but I think it should be OK

Not sure if this is the best place to apply a fix in the longer term -
overall architecture is still a bit daunting. I'm mainly interested in
unmarshalling XML into objects and an happy to have .betwixt files dotted
about the place so it works for me.
I also inferred that when marshalling java into XML there would be object
instances to play with which must have come from non-abstract classes and in
that case the Introspector would work as expected. - (untill some show-off
is using the Proxy API but they should expect trouble)

-----Original Message-----
From: robert burrell donkin
Sent: 05 August 2004 21:46
To: Jakarta Commons Developers List
Subject: Re: betwixt files doesn't work with inherited Interfaces

hi andrew

i'm a little intrigued by this problem and i'll take a look at adding a 
solution but i'm not likely to be able to have anything ready tonight. 
just to check i've parsed you correctly, you're using a normalizer and 
the introspection needs to pick up the methods on the super-interfaces 
for the given interface, right?

(unfortunately, you'll have to roll your own jar since it'll be too 
late to go into the upcoming 0.6 release.)

- robert

On 5 Aug 2004, at 16:26, Gray, Andrew (ITDA) wrote:

> Hi,
> After some digging I've hit a "limitation" - ultimately due (IMHO) to
> java.beans.Introspector - if you introspect an interface you don't get
> deatils on anything defined in super interfaces  (I'm using jdk 
> All of my javaBean structures are defined by interfaces with the
> implementation classes being context specific.
> public interface Person {
>     String getName();
>     void setName(String name);
> }
> public interface Developer extends Person {
>     int getHackCount();
>     void setHackCount(int hacks);
>     Pet getPet();
>     void setPet(Pet pet);}
> public interface Pet {
>    ...
> }
> public interface DevTeam {
>     Collection getDevelopers();
>     void addDeveloper(Developer dev);
> }
> add some .betwixt files telling the parser what mplementations to use
> DevTeam.betwixt: -
> ...
> <element name='developer' property='developers' class='MyDeveloper'/>
> ...
> and Developer.betwixt: -
> ...
> <element name='pet' property='pet' class='MyPet'/>
> <addDefaults>
> ...
> etc.
> Now I come to unmarshall the following snippet in a xml doc.
> ...
> <devTeam>
>    <developer>
>       <name>Joe Blo</name>
>       <hackCount>32</hackCount>
>       <pet> ... </pet>
>   </developer>
> </devTeam>
> ...
> Trying to get betwixt to parse a Developer is failing as the 
> Introspection
> API is not telling it about the name property defined in Person 
> superinterface.
> Defining specific elements is no better. There is no WriteMethod 
> returned
> from the introspector so no Digester rule is created to parse "name" 
> and it
> ends up null.
> Thoughts appreciated.
> Will DynaBeans get round this?
> Does anyone know if Sun will "fix" the introspector?
> Is there a preferred workaround / approach if they won't (soon)?
> (I don't want to redifine things in subclasses already in superclasses)
> regards
> Andy Gray
> Department for Environment, Food and Rural Affairs (Defra)
> This email and any attachments is intended for the named recipient 
> only. Its
> unauthorised use, disclosure, storage or copying is not permitted. If 
> you have
> received it in error, please destroy all copies and inform the sender. 
> Whilst this
> email and associated attachments will have been checked for known 
> viruses
> whilst within Defra systems we can accept no responsibility once it 
> has left our
> systems. Communications on Defra's computer systems may be monitored
> and/or recorded to secure the effective operation of the system and 
> for other
> lawful purposes.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message