users@jaxb.java.net

RE: Three problems: how to solve?

From: George Datuashvili <George.Datuashvili_at_Siebel.com>
Date: Thu, 11 Dec 2003 14:00:15 -0700

For a vendor-specific solution you can look at IBM SDO implementation,
which is based on EMF and is part of WSTK. You can generate EMF model
out of XSD schema and then generate SDO classes for it. It will have
strongly type proxies, efficient storage, change notifications, change
logs, parent tracking, xpath on objects, and can read/write to xml.

> -----Original Message-----
> From: Alan Wessman [mailto:alanyst_at_hotmail.com]
> Sent: Monday, December 08, 2003 10:16 PM
> To: users_at_jaxb.dev.java.net
> Subject: Three problems: how to solve?
>
> Here are some problems I commonly need to solve in my
> customized subclasses of JAXB-generated classes:
> 1. Given an unmarshalled object, return its parent object
> (the parent element in the serialized XML) 2. Generate an
> event when a field (attribute or child element) is changed 3.
> Intervene with custom execution immediately after an element
> has been completely unmarshalled (i.e., execute under a
> guarantee that all child attributes and elements have been
> unmarshalled and that no other code intervenes between the
> time this condition is met and the custom execution
> begins)
>
> For #1, is there a native way to do this? My current
> approach is to define a setParent() method in the custom
> superclass, and after the entire document has been
> unmarshalled I call setParent() on the root which propagates
> the call down the tree. This is inefficient and requires
> extra coding in the custom subclasses, so it would be nice
> not to have to do this.
>
> For #2, I currently override the setter methods in the custom
> subclasses to detect changes, call super.setXYZ(), and then
> fire a PropertyChangeEvent.
> This works during runtime manipulation of the object tree but
> not during unmarshalling, because the unmarshaller does not
> call the setter method but instead assigns directly to the
> field in the class. It would be nice to be able to guarantee
> that the event can be fired whenever the underlying field
> changes, including during unmarshalling. Is there a good
> reason for the unmarshaller not to invoke the setter?
>
> For #3, I don't know of a good solution. (Tie in somehow to
> the SAX event
> handler?) The problem is that I need to be able to code with
> an assurance that all child attributes and elements are set,
> but to ensure that my custom code is executed before other
> instance methods so that pre-conditions for the custom
> subclasses may be established.
>
> Thanks in advance for any insight you might share.
>
> Alan
>
> _________________________________________________________________
> Don't worry if your Inbox will max out while you are enjoying
> the holidays.
> Get MSN Extra Storage! http://join.msn.com/?PAGE=features/es



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net