The issue is with the code generation for unmarshalling these references inside a collection. Collection handling in the 1.0 code is a mess in some ways, and there are no easy fixes I can see. I've been planning for a long time on completely replacing the code generation implemented by JiBX, along with a number of other changes. Most of the other changes are now in place, but that final piece of replacing the code generation is something I decided to postpone to a 2.0 release. The reasons for this are that: (1) the current code has limits on what works, but is stable and I believe reliable enough within those limits to be a decent production release; (2) in the process of making the code generation changes I'll also want to clean up some of the inconsistencies that have accumulated in the binding definition structure (since this is the basis for the code generation) and even restructure the internal marshalling and unmarshalling implementation, which means breaking both existing bindings and marshaller/unmarshaller extensions - I'd rather do that as a 1.0 to 2.0 release change than in a beta; and (3) I want to make the new code generation flexible enough to handle both bytecode and source code enhancement usages, so that people who want to be able to debug through the JiBX code will be able to do so by having the binding code generated into their source files, and this is something that's going to take time to get right.

So what it comes down to is that the custom marshaller/unmarshaller is a work around for an area of the JiBX 1.0 code that doesn't work and would be too messy to fix properly in the current codebase. A generic class won't do because there's no way to pass the information about the particular property used for the id (which is needed when marshalling) into that class, and it's not something that's exposed within the code JiBX adds to the class. There is one alternative that would be easy to implement, if you don't mind making changes to your classes: Define an Id interface with a getId() method and implement this in the classes you're using. Then you could modify the code I provided to just use this interface method to get the id and would not need to subclass it for each specific class handled.

 - Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA  425.885.7197



Mocky Habeeb wrote:

Thanks Dennis,

My understanding of why I'd need to create an IdRefMapperBase subclass
for each object (as opposed to having a Mapper class that can do it on
it's own if I specify it in my binding without having to subclass it),
and why that subclass has to have information I've already put into my
binding definition (how to get an id value from my object) is because
when I run the binding compiler it updates my class files directly with
that info and as such it is not available via method calls at marshal
time. Because my class is updated to know how to marshal itself fully
but it doesn't know how to marshal itself with just its 'ref' in the
tag. Is that correct? And if so then potential source support in version
2.0 might alleviate that requirement?

Mocky


-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sosnoski Sent: Monday, March 21, 2005 5:55 PM To: jibx-users@lists.sourceforge.net Subject: Re: [jibx-users] put values with ident="ref" directly into a collection


I've added a pair of base class marshaller/unmarshallers for this in org.jibx.extras package in the current CVS code. The IdRefMapperBase one


should be usable with beta 3c; to use this you need to create your own subclass which extends the base class and implements a three-argument constructor and one abstract method to retrieve the ID value from an instance of the object class being handled. This is usable directly within a collection, as:

   <collection name="references" field="m_references" usage="optional">
     <structure name="name" marshaller="extras.NameArray$RefMapper"
         unmarshaller="extras.NameArray$RefMapper"/>
   </collection>

where:

public class NameArray
{
...
public ArrayList m_references;
public static class Name
{
public String m_id;
public String m_first;
public String m_last;
}
private static class RefMapper extends IdRefMapperBase
{
public RefMapper(String uri, int index, String name) {
super(uri, index, name);
}


       protected String getIdValue(Object item) {
           return ((Name)item).m_id;
       }
   }
}

handles:

 <references>
   <name ref="c0001"/>
   <name ref="c0002"/>
   <name ref="c0004"/>
 </references>

This won't allow forward references - to do that you'd need a marshaller/unmarshaller that handles the whole collection so it could set up the appropriate backfill structures - but the IdDefRefMapperBase allows define-on-first-use handling.

 - Dennis




------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ jibx-users mailing list jibx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jibx-users





-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users

Reply via email to