Rickard wrote:
>
> Keith Visco wrote:
>
> > How about: We're very busy...and we try to handle everyone's question,
> > but it just takes time...and sometimes over the weekend questions might
> > get lost among the flurry of e-mail sent on monday morning.
>
> Fair enough :-)
>
> > As far as using Castor XML to fill an existing object: This is not yet
> > supported, though we do plan on allowing the "Root" element to be mapped
> > to an existing object.
>
> Alright, no biggie, I'll just copy it manually.
>
> > As far as you using elements as the IDREF...no this is not
> > supported...only attributes can be IDREF at this time.
>
> Alright, that's not good, but livable. How about collections of IDREF's?
Currently we handle this the way it's handled in XML Schema, and that is
using IDREFS,...which is simply a space delimited string of IDREF:
such as:
<foo bar="BAR1 BAR2 BAR3"/>
It could get really ugly if you have many items in your collection, but
it's all we support for now.
>
> > As far as using interfaces..it should be possible, but this will require
> > a test case to know for sure. I've never tried it. I don't currently
> > have time right now to look into it. If you wish to supply a
> > short-as-possible test case, I can look into it when I have a chance.
>
> Will do.
>
> > As far as you not having it working as described it in a previous
> > e-mail...I can't help you there..I already sent you my mapping file for
> > my example which is working fine for me. I can't really fix something if
> > I can't see that it's broken.
>
> Well, I assume your example was for beans2beans and not
> beans2interfaces. Could that be the difference? I've looked in the
> source, but can't figure out what the rules for invoking an IDResolver are.
Currently...when Castor encounters an attribute that has a type of IDREF
(or reference="true") it will ask the internal IDResolver to (see the
inner class UnmarshalHandler.IDResolverImpl) resolve the reference.
If you set your own IDResolver, the instance of IDResolverImpl that
UnmarshalHandler is using will hold a reference to it. If and only if it
cannot resolve your reference, then the IDResolverImpl will ask your
IDResolver to do it.
>
> > Sorry for the inconvenience...
>
> No problem, I'm just a little surprised that noone has run into this
> before. Since both of these issues (root object filling and interface
> references) are vital to getting this to work with EJB's I assume noone
> has actually used it for this before.
Other people have certainly asked about filling the root object before.
We do plan on supporting this, but we don't yet support it.
As far as interface references, I've never seen any complaints, until
yours. Concrete class references are definately working as my test case
continues to work properly. However, there may or may not be an issue
with interfaces, it just hasn't been tested, at least not by me.
>
> It sounds like what I'll have to do right now is to map the references
> to duplicate reference field being simple strings, and then do
> post-processing to resolve the actual reference.
>
I am not sure what the best approach would be, but if you do send me a
sample test case, I will definately look into it. If it doesn't work
with interfaces, then I would prefer to get it working, as I see no
limitation as to why we shouldn't be able to get it working.
Thanks,
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
