No problem. I'd be happy to elaborate. (Aside: Wow, you actually dug up
the original post.)
BTW, thanks to you and Sekhar for taking the time to guest in a community
forum.
The synchronization that I mention is indeed only for the JavaBeans-style
gets and sets,
not for the process of marshalling/unmarshalling/validating. So, the
content classes
(using the RI as an example, the xxxImpl classes) would be affected, not the
content
interfaces.
Let's say you have this class:
-- ConfigurableComponent.java --
public class ConfigurableComponent {
private ComponentConfiguration configuration = null;
public ComponentConfiguration getConfiguration() {
return this.configuration;
}
public void setConfiguration(ComponentConfiguration configuration) {
this.configuration = configuration;
}
}
-- end --
... and the schema definition...
-- part of some .xsd file --
<xs:complexType name="ComponentConfiguration">
<xs:sequence>
<xs:element name="propertyA" type="xs:string" />
<xs:element name="propertyB" type="xs:nonNegativeInteger" />
<!-- various other elements and so on -->
</xs:sequence>
</xs:complexType>
-- end --
Let's say that you then have multiple threads accessing an instance of
ConfigurableComponent, each of which can get a reference to the
configuration
and manipulated it's properties, it would be helpful to have the
configuration
implementation have synchronized get and set methods. Simply synchronizing
getConfiguration and setConfiguration would not be sufficient, since that
will not synchronize calls on the ComponentConfiguration instance itself.
Currently, to solve the problem, you have to make sure that any code (that
would be executing in those threads) that calls getXXX or setXXX on
ComponentConfiguration executes in a sychronized fashion on the
configuration
instance.
It would be nice to be able to just specify in the schema a customization
like this:
-- part of some .xsd file --
<xs:complexType name="ComponentConfiguration">
<xs:sequence>
<xs:element name="propertyA" type="xs:string">
<xs:annotation><xs:appinfo>
<jaxb:property synchronized="true"/>
</xs:appinfo></xs:annotation>
</xs:element>
<xs:element name="propertyB" type="xs:nonNegativeInteger" />
<!-- various other elements and so on -->
</xs:sequence>
</xs:complexType>
-- end --
While this example shows the customization applying only to a single
element,
it would of course be preferable to have such a customization available on
other scopes.
I hope this clarifies the use case some.
Brian
-----Original Message-----
From: Ryan Shoemaker - JavaSoft East [mailto:Ryan.Shoemaker_at_Sun.COM]
Sent: Tuesday, April 22, 2003 4:35 PM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Binding customization for "synchronized"
Franklin, Brian wrote:
> I have encountered several situations in which it would be helpful to
> have the methods of generated classes be "synchronized" for thread-safe
> behavior.
>
> I am not aware of any current binding customization that will provide
> this functionality. I don't believe it would be too difficult to
> implement, and the scope of its impact is presumably minimal since it
> would not affect any interfaces (it's purely a generated implementation
> feature).
>
> Is there a way that a binding customization for this could be introduced?
> Brian Franklin
>
Sorry for the long delay in replying to this issue.
I agree that it would not be a difficult customization to add on the RI
impl classes, but I think the team is having trouble understanding the
use-case for this feature. Please elaborate...
Roughly speaking, in the case of the RI, the impl classes contain code
responsible for 2 things: 1. interacting with our runtime system to
control marshalling, unmarshalling, and validation and 2. implementing
all of the JavaBean getter/setter API's from the generated interfaces.
From the perspective of the runtime system, I highly doubt that we will
ever be able to support thread-safe marshalling, unmarshalling, and
validation. It just doesn't make sense to talk about simultaneously
marshalling the same content tree object. However, it sounds like you
are interested in making the JavaBean api's synchronized. This is the
use-case we're interested in hearing more about. On the surface, it
seems like there are some potentially tricky issues we would have to
evaluate to determine if this is a safe change to make...
--Ryan