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

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). 

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.

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

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). 

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.

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 =) 

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

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). 

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.