DOMWriter given any arbitrary DOM element from the the tree should produce valid XML. i.e. it must include the NS declarations from further up if they are not defined on the element that is beeing written out.
Previous to the change to DOMWriter, the SOAP content element was beeing assigned invalid XML, which had to be corrected before the fragment was passed to JBossXB.
If NS declarations are duplicated on nested elements that would be an error. Correct is, that every XML fragment associated with a SOAPContentElement is valid, which leads to NS declarations on
#1 SOAPBodyElement for doc/lit and
#2 RPC params for rpc/lit
#3 SOAPHeader elements
The DOMWriterTestCase should comperensivly test the correct behaviour of the DOMWriter.
The XML fragment association may go away in future
http://jira.jboss.org/jira/browse/JBWS-1314 when we no longer need to pass XML fragments to JBossXB (i.e can work with DOMSource for example)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979945#3979945
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979945
At some point, we should remove the xml string fragment processing phase. It's not needed in our long term streaming optimization plan, and it adds unneeded performance overhead in the current design.
Instead we could pass the corresponding DOM chunk directly to the marshalling layer. JAXB supports this using InputSource, and it wouldn't be difficult to enhance JBossXB to do the same. This would also be more robust because it would eliminate the xml escape processing that we duplicate from a standard XML parser (see http://jira.jboss.com/jira/browse/JBWS-1240 for an example).
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979932#3979932
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979932
Why did we add the logic to copy root namespaces to a generic DOM output class?
Looking at the other changes in it seems like now other areas of the stack have to do all of this work to remove namespaces.
If the namespace copying is only needed on the top level element that is passed into JBossXB/JAXB, then doesn't this belong in SOAPContentElement?, or some other kind of SOAPContentElement specific class.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979931#3979931
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979931
Thanks thomas.
We are working also on another problem we are experiencing on a jboss cluster with a jbossws eventing deployed on it.
The cluster is viewed (of course) as a single machine by the client, subscribing and getting events to our service. As you can figure out the problem is more than one:
1. The load balancer send subscriptions to only one server, but the subscriptions have to be registered by all servers in the farm (or better in only one place for all cluster's machines IMHO)
2. The notification have to be coordinated.
3. Events like "machine going down" have to be generated according to cluster status, not single machine status.
4. Something else we are thinking about.....:)
We (me ad Alessio alias "palin" on these forums) will have fun coding on these issues, but we need some informations about jbossws' core design:
a. The easiest way to implement this stuffs is to use clustered ejbs as notification proxy, but we think you don't like any solution using ejb. Isn't it?
b. We are thinking to use hajndi to register subsriptions. What do you think about?
c. We think the only part of jbossws needing a cluster solution is ws-eventing because it is the only part in which jbossws acts as client (meaning a source of soap message). Isn't it? Are you thinking about a more general clustering enhacement?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979017#3979017
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979017