You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2008/10/03 23:10:55 UTC
What is mergable to 2.1.3 and 2.0.9....
There's a couple commits to trunk that I'd like some verification that
they should go to 2.1.x before I do so.
1)
r699289 | bimargulies
Some preliminary work on attributes
r700981 | bimargulies
Incremental creeping toward attribute support in Javascript. As usual, in
spite of the XmlSchema situation.
This looks like it's just adding support for attributes and thus looks
safe to merge to 2.1. (javascript wasn't on 2.0.x so no need to merge
there) Correct?
2) A BUNCH of commits to the JMS transport - they are all localized to
the JMS transport and don't touch the jms tests in systest. Thus, it
looks like none of the old configuration "broke". However, can
Christian comment on whether he thinks what is there is "safe"
(performance and general compatibility wise) to merge down? I'd really
like to get the Spring based JMS stuff down into the 2.0.x if possible
(to alleviate some of the suckiness of the jms config), but not if it's
going to break everyone.
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: What is mergable to 2.1.3 and 2.0.9....
Posted by Christian Schneider <ch...@die-schneider.net>.
What I have currently done should be fairly compatible. But in details
there could be problems.
I have not yet implemented a new configuration style for spring or wsdl.
The new config is there but not yet attached. This means that currently
the users will not yet
really benefit from the changes.
The performance should be quite good but but I have not done any
performance tests yet. Any good ideas how to test this? The normal test
tools like jmeter or SoapUI do not support
soap/jms as far as I know.
Greetings
Christian
Daniel Kulp schrieb:
> There's a couple commits to trunk that I'd like some verification that
> they should go to 2.1.x before I do so.
>
> 1)
> r699289 | bimargulies
> Some preliminary work on attributes
> r700981 | bimargulies
> Incremental creeping toward attribute support in Javascript. As usual, in
> spite of the XmlSchema situation.
>
> This looks like it's just adding support for attributes and thus looks
> safe to merge to 2.1. (javascript wasn't on 2.0.x so no need to merge
> there) Correct?
>
>
> 2) A BUNCH of commits to the JMS transport - they are all localized to
> the JMS transport and don't touch the jms tests in systest. Thus, it
> looks like none of the old configuration "broke". However, can
> Christian comment on whether he thinks what is there is "safe"
> (performance and general compatibility wise) to merge down? I'd really
> like to get the Spring based JMS stuff down into the 2.0.x if possible
> (to alleviate some of the suckiness of the jms config), but not if it's
> going to break everyone.
>
>
>
--
Christian Schneider
---
http://www.liquid-reality.de
Re: What is mergable to 2.1.3 and 2.0.9....
Posted by Benson Margulies <bi...@gmail.com>.
Correct. Mine are harmless.
On Fri, Oct 3, 2008 at 5:10 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> There's a couple commits to trunk that I'd like some verification that
> they should go to 2.1.x before I do so.
>
> 1)
> r699289 | bimargulies
> Some preliminary work on attributes
> r700981 | bimargulies
> Incremental creeping toward attribute support in Javascript. As usual, in
> spite of the XmlSchema situation.
>
> This looks like it's just adding support for attributes and thus looks
> safe to merge to 2.1. (javascript wasn't on 2.0.x so no need to merge
> there) Correct?
>
>
> 2) A BUNCH of commits to the JMS transport - they are all localized to
> the JMS transport and don't touch the jms tests in systest. Thus, it
> looks like none of the old configuration "broke". However, can
> Christian comment on whether he thinks what is there is "safe"
> (performance and general compatibility wise) to merge down? I'd really
> like to get the Spring based JMS stuff down into the 2.0.x if possible
> (to alleviate some of the suckiness of the jms config), but not if it's
> going to break everyone.
>
>
> --
> J. Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>