Yes we had to setup spring pooling of the marshaller/unmarshaller for anything
to work under load. They (or maybe just one of the two.. I forget) are not
threadsafe.. and the create() operation can be expensive. We can't even use
validation due to a bug with xerces choking on one of the schemas we are
importing =)
I would just checkout the stripes trunk and browse around, find the object
factory and trace it up. It's not very complicated
Re subclassing, I think you might be able to extend the property binder &
population strategy. But last I looked, the property binder didn't have a
clean hook for instantiation so you may have to duplicate a lot of code in a
large method in your subclass.. =(
>>"also changes parameters names to plural for arrays and such"
That's nice. All of our collections are singular names which frequently
confuses me ... there is a jaxb plugin for adding the S, but it doesn't exactly
work right List<Plan> currentPlans ends up being List<Plan> currentPlen .. etc,
it is 'too smart'.
JAXB itself isn't that bad. In fact I could see myself using it again for
something else in the future. For xml<->java it works well and is quite fast
enough.
But using xjc has been, well, a bit of a burden. When we first started it was
a big win, just grab the xsd and run instead of crafting and updating the .java
files. But like I said there's no Sets, and getBoolean (which I've worked
around) are the main two problems. Oh and no Map support last I tried. I
know there are a few other nagging things with xjc I can't recall now. But
really having generated entities that you can't add calculations / validation
into can be a bit crippling sometimes. It's nice in the spirit of MDA but in
practice that didn't really work out 100% for us. Plugging correct equals &
hashcode methods into a superclass is tricky and required a plugin. That then
breaks MDA since I have some abstract getXXX() methods in a super type above
the generated one and just have to hope that the generated one still correctly
overrides that =)
From: Brown, Alex [mailto:[email protected]]
Sent: Wednesday, October 28, 2009 12:34 PM
To: Stripes Users List
Cc: Stone, Timothy; Smith, Ken
Subject: Re: [Stripes-users] Bean Population with XMLBeans and Stripes?
Hey John,
So Stripes 1.6 will have the ability to use factories with the population
strategy? Is this documented anywhere as far as how it works or should I just
peruse the code?
Not sure what you mean about subclassing, subclassing the population strategy?
Why do you like or not like jaxb? XMLBeans not only uses "is" instead of
"get", but it also changes parameters names to plural for arrays and such. It
is also not Java 5 code and uses a goofy enumeration strategy etc. It also
uses arrays instead of Lists or Sets, sort of.... You use the factory to add
the elements and build the object from each parent for the most part.
Main issue with JAXB at this point for me is that validation is goofy and you
need to cache the marshler or it is crazy slow.
I did a speed analysis and they are extremely close speedwise if you cache the
marshler with JAXB.
Thanks
________________________________
From: Newman, John W [mailto:[email protected]]
Sent: Wednesday, October 28, 2009 10:35 AM
To: Stripes Users List
Subject: Re: [Stripes-users] Bean Population with XMLBeans and Stripes?
Stripes 1.6 will have the object factory - anywhere newInstance() was used is
replaced with yourObjectFactory.newInstance(); .. this was stable in the trunk
when I last tried it out, about 2 months ago. The @Before method probably
wont work too well for very long. You could subclass
We are currently using jaxb. It is definitely working fine for us, but I've
been lightly looking into a switch to xml beans. If you can use that, I would
try to stick with it. We had to hack our way through a few custom plugins and
xjc changes to get jaxb to behave correctly for us. The biggest problem is
they botched the boolean is/get convention
http://www.mojavelinux.com/blog/archives/2006/09/the_great_jaxb_api_blunder/
.. among other things .. the other big one is they only use List<> for
collections, no Sets .. and absolutely forget about maps (which are often so
useful).
From: Brown, Alex [mailto:[email protected]]
Sent: Tuesday, October 27, 2009 3:04 PM
To: [email protected]
Subject: [Stripes-users] Bean Population with XMLBeans and Stripes?
Hello all,
I am working with XMLBean objects, Spring webservices and of course Stripes.
XMLBeans utilize factories to create new object instances for an object graph
like this:
obj = Object.Factory.newInstance();
newObj = obj.addNewObject();
The issue I have is that a given form may have information to build an unknown
set of objects on an object graph. We need to maintain this flexibility as the
pages are dynamic.
We want to use the XMLBean object as the form object on the action bean.
We could pre-instantiate the objects in a @Before method but this can be messy
and might leave us with object leafs that were not part of the submission.
I have a few options as I see it:
* Convert everything to JAXB
* Figure out a bean population strategy hack that uses reflection to
automatically build objects based on the XMLBean convention.
Has anyone heard of any solutions for this issue? It looks like the Stripes
rolled BeanUtils does not support factories.
Thanks!
Alex
_______________________________________________________
Barclays
www.barclaycardus.com
_______________________________________________________
This e-mail and any files transmitted with it may contain confidential and/or
proprietary information. It is intended solely for the use of the individual or
entity who is the intended recipient. Unauthorized use of this information is
prohibited. If you have received this in error, please contact the sender by
replying to this message and delete this material from any system it may be on.
_______________________________________________________
Barclays
www.barclaycardus.com
_______________________________________________________
This e-mail and any files transmitted with it may contain confidential and/or
proprietary information. It is intended solely for the use of the individual or
entity who is the intended recipient. Unauthorized use of this information is
prohibited. If you have received this in error, please contact the sender by
replying to this message and delete this material from any system it may be on.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
