[JBossWS] - Re: JbossWS 1.2.1 and .Net 2.0 client
by centecbertl
JBossWS is standard conforming, and per se this is not a JBossWS problem. But it means that updating to new JBossWS versions breaks a lot of client code or requires to put XMLElement on all generated DataStructures for
nillable non-complex Data fields. Thus it is a JBossWS users problem.
Detail:
(i.e. autoboxing Long, Integer, Double types, Date types, BigDecimal,.....
I was lucky, since I generate all these by using androMDA, thus it was easy to add XmlElement to several hundred data structures in the correct places.
It could help other JBossWS users to document the behaviour, and make it configurable (e.g. property nillablesAreRequired).
The situation is even worse on .net side: when a .net client reads a complex data structure it does not set the ...Required fields on its own. Thus something like
| tradeService.updateTradePriceQuote(quotationService.getQuote(isin))
|
with a complex data structure Quote, carrying quotation detail as BigDecimals does not work any longer (what it used to do with JBossWS1.0.x and JSR 181 annotations)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041469#4041469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041469
18 years, 11 months
[JBoss Seam] - Pages Hierarchy
by iradix
First off, Gavin I wanted to say thanks for all the improvements to pages.xml since 1.0. Even though my patch didn't make it in (JBSEAM-397), it's great to see most of the functionality there. I do have a couple of questions about how it's all been implemented though.
In my experience most pages within a specific conversation seem to match a wildcard (say /cart/*) where one of the pages in that group (say /cart/view.jsf) is responsible for starting the conversation. In my head this would translate into:
<page view-id="/cart/*" conversation-required="true" no-conversation-view-id="/cart/view.xhtml"/>
|
| <page view-id="/cart/view.xhtml" conversation-required="false">
| <begin-conversation join="true"/>
| </page>
The way Pages is implemented however, since pages are processed individually starting with the worst match, the conversation-required attribute on the wildcard forces a redirect before the conversation can be begun by the more specific match. When I put my patch together I had laid out pages in a parent child relationship so that single parameters like conversation-required could be overridden by more specific matches and multiple parameters like action could still be processed worst match first. It makes more sense to me that way and I noticed at least one other poster with a similar problem regarding login-required. I'm not saying that my way was better, but could we find a compromise between the two? It seems like the ability to override wildcards would be useful in mutliple circumstances.
I am willing to submit another patch, but I wanted to see what others thought and gauge how well it would be accepted before I do.
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041460#4041460
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041460
18 years, 11 months