Overiding default JAXB mappings
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Overiding default JAXB mappings
by rubinod
::
Rate this Message:
Hi,
Say I have the following: <xs:element name="Platforms"> <xs:complexType> <xs:sequence> <xs:element name="platform" minOccurs="0" maxOccurs="unbounded" type="c:PlatformType"/> </xs:sequence> </xs:complexType> </xs:element> when I run the schema through JAXB to generate the class files I get: @XmlRootElement(name = "Platforms") public class Platforms implements Serializable { @XmlElement(name = "platform") protected List<Platform> platforms; public List<Platform> getPlatforms() { if (platforms == null) { platforms = new ArrayList<Platform>(); } return this.platforms; } } I would like to be able to override the default List implementation as I dont want an ArrayList- is this possible? Thanks |
|
|
Re: Overiding default JAXB mappings
by Wolfgang Laun-2
::
Rate this Message:
This depends on PlatformType - is it an xs:simpleType?
What would you like to have instead of ArrayList, and why? -W On Wed, Sep 30, 2009 at 6:28 PM, rubinod <webaccounts@...> wrote:
|
|
|
Re: Overiding default JAXB mappings
by rubinod
::
Rate this Message:
Hi,
I need something thread safe so even a Vector or something from java.util.concurrent would be more useful. Thanks
|
|
|
Re: Overiding default JAXB mappings
by MrKimi
::
Rate this Message:
I could use this too.
I had a recent performance issue with ArrayList, it goes slow as the size gets past a certain point. Had to change it to a TreeSet (or similar, I forget the details). It wasn't anywhere near JAXB so that was easy, but it might have been, in which case I would looking for an answer to this question. Regards rubinod wrote: --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...Hi, I need something thread safe so even a Vector or something from java.util.concurrent would be more useful. Thanks Wolfgang Laun-2 wrote:This depends on PlatformType - is it an xs:simpleType? What would you like to have instead of ArrayList, and why? -W On Wed, Sep 30, 2009 at 6:28 PM, rubinod webaccounts@... wrote: |
|
|
Re: Overiding default JAXB mappings
by Wolfgang Laun-2
::
Rate this Message:
Serializing Java using XML is bound to have limits, even with all the customizing and plugin features. XML Schema isn't a design tool for Java classes. Using objects created from the xjc generated classes in an application where thread safety (or any other facet of dynamic behaviour) matters obviously raises issues that are not addressed by the JAXB specification.
One way to go would be to avoid Java class generation from a schema and to annotate Java classes with JAXB annotations. This way it would be easy to deal with synchronisation, or use better strategies for list allocations, etc. If you want to stick with generating classes, you might consider using a design pattern akin to Decorator or Proxy to deal with synchronisation or other dynamic behaviour issues. And you always have the option of not using some or all of the document classes in your application's business logic at all. Transforming between related objects does create an overhead, but it'll also effectively decouple the XML representation from the business logic. .W On Fri, Oct 2, 2009 at 2:47 AM, Roger Parkinson <roger@...> wrote:
|
|
|
Re: Overiding default JAXB mappings
by MrKimi
::
Rate this Message:
Sure, I understand the limitations, or I think I do. :-)
We really, really like specifying all our business objects in XSD and generating them. It simplifies so many things and is an excellent approach from a conceptual point of view at least. Simple example: we suddenly find we need to expose an object graph as part of a web service, how much coding? Almost none. But it does insist on delivering all collections as ArrayList. It seems a minor change to be able to specify an alternate class. I'd be happy to use the same class everywhere, just not ArrayList. ie defining a new one globally would be fine. It's not like we serialise everything back and forth all the time, but regardless of that we still have to use ArrayList. Actually I did make some progress here. I added a plugin on the generator that injects some code around the instantiation of the ArrayList. That handles cases where we don't serialise, but we do tend to use serialised classes interchangeably with nonserialised and that can lead to inconsistencies where the list class is different. Thanks for listening R Wolfgang Laun wrote: > Serializing Java using XML is bound to have limits, even with all the > customizing and plugin features. XML Schema isn't a design tool for Java > classes. Using objects created from the xjc generated classes in an > application where thread safety (or any other facet of dynamic behaviour) > matters obviously raises issues that are not addressed by the JAXB > specification. > > One way to go would be to avoid Java class generation from a schema and to > annotate Java classes with JAXB annotations. This way it would be easy to > deal with synchronisation, or use better strategies for list allocations, > etc. > > If you want to stick with generating classes, you might consider using a > design pattern akin to Decorator or Proxy to deal with synchronisation or > other dynamic behaviour issues. > > And you always have the option of not using some or all of the document > classes in your application's business logic at all. Transforming between > related objects does create an overhead, but it'll also effectively decouple > the XML representation from the business logic. > > .W > > On Fri, Oct 2, 2009 at 2:47 AM, Roger Parkinson <roger@...>wrote: > >> I could use this too. >> I had a recent performance issue with ArrayList, it goes slow as the size >> gets past a certain point. >> Had to change it to a TreeSet (or similar, I forget the details). >> It wasn't anywhere near JAXB so that was easy, but it might have been, in >> which case I would looking for an answer to this question. >> >> Regards >> >> >> rubinod wrote: >> >> Hi, >> >> I need something thread safe so even a Vector or something from >> java.util.concurrent would be more useful. >> >> Thanks >> >> >> Wolfgang Laun-2 wrote: >> >> >> This depends on PlatformType - is it an xs:simpleType? >> >> What would you like to have instead of ArrayList, and why? >> >> -W >> >> >> On Wed, Sep 30, 2009 at 6:28 PM, rubinod <webaccounts@...> <webaccounts@...> wrote: >> >> >> >> Hi, >> >> Say I have the following: >> >> <xs:element name="Platforms"> >> <xs:complexType> >> <xs:sequence> >> <xs:element name="platform" minOccurs="0" >> maxOccurs="unbounded" >> type="c:PlatformType"/> >> </xs:sequence> >> </xs:complexType> >> </xs:element> >> >> when I run the schema through JAXB to generate the class files I get: >> >> @XmlRootElement(name = "Platforms") >> public class Platforms >> implements Serializable >> { >> >> @XmlElement(name = "platform") >> protected List<Platform> platforms; >> >> public List<Platform> getPlatforms() { >> if (platforms == null) { >> platforms = new ArrayList<Platform>(); >> } >> return this.platforms; >> } >> >> } >> >> I would like to be able to override the default List implementation as I >> dont want an ArrayList- is this possible? >> >> Thanks >> >> -- >> View this message in context:http://www.nabble.com/Overiding-default-JAXB-mappings-tp25684570p25684570.html >> Sent from the java.net - jaxb users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... For additional >> commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Overiding default JAXB mappings
by Wolfgang Laun-2
::
Rate this Message:
It seems that simply replacing ArrayList by Vector solves the problem,
since Vector<T> implements List<T>. (It seems that it's even possible to replace List<T> by Vector<T> as well, but that isn't necessary.) Or would wrapping all the ArrayList<T> into Collection.synchronizedList<T> solve your problem? In either case I'd suggest a simple sed or Perl script to post-process the generated files. -W On Sun, Oct 4, 2009 at 11:43 PM, Roger Parkinson <roger@...> wrote: Sure, I understand the limitations, or I think I do. :-) |
| Free embeddable forum powered by Nabble | Forum Help |
