Hi
On 27/01/12 15:59, Daniel Kulp wrote:
On Friday, January 27, 2012 1:02:11 PM Sergey Beryozkin wrote:
Hi
It is time to return to this thread with more modules being and about to
be added to the trunk
On 20/09/11 12:07, Sergey Beryozkin wrote:
Hi
What do you think of dropping a couple of modules for 2.5:
- both rt-bindings-local and rt-bindings-object seem to do the same
thing, I recall there were some interesting discussions around these two
modules awhile back :-), but today I guess it's more important which
module we actually encourage users to use. If it is rt-bindings-local
then lets drop rt-bindings-object or the other way around
Can I hack either of those modules on the trunk only, the users
definitely use the collocated support, the question is, do we have an
indication of which module is actually used or both of them can be used ?
If it is the latter, can users migrate to the which will be kept in 2.6
(assuming of course that one module is removed) without any major problems ?
I assume you mean rt-transport-local, not binding-local...
The two of those really have different use cases right now and it would be a
significant amount of work to get the uses cases for one to be met by the
other. I'm OK with doing that, but I'm warning that it will be a lot of
work.
There isn't really a way to get rid of rt-transport-local. It has a
specific use case of allowing FULL CXF feature sets, but without opening ports
or anything. We use it in our tests all over the place. Basically, it
allows things like policy and security and gzip and everything to work exactly
like if it was an HTTP connect, just in-vm. (that said, I think the
performance of local is actually less than http)
The issue is between binding-object and binding-coloc. Most likely,
binding-coloc could be re-written in terms of binding-object or vice versa,
but I've never really dug into them.
Sorry, I meant rt-binding-object & rt-binding-coloc...
I basically looked at the list of modules and I also vaguely remember
that they more or less do the same thing so thought one of the modules
was a 'candidate'...Better keep both of them then for a while just in case
- cxf-rt-bindings-http - dropping it for 2.5 would encourage existing
users to finalize their migration to JAX-RS
I'm poised to remove it on the trunk only, we got one +1 from Eric, any
concerns about deleting it ?
No concerns for 2.6. Go for it.
Sure, will do. My only concern is that this one lets users write the
code that say unwraps in XML into multiple parameters which is not
possible with JAX-RS. But if it will really block some users from
migrating to 2.6 then I'd be ready to consider doing the extension in
the rs frontend. Overall it was a nice effort from Dan D but it's a
simply an unsupported module now with JAX-RS taking the priority
Cheers, Sergey
Dan
Cheers, Sergey
I guess we can continue keeping the above modules, was just thinking if
we could compensate somehow the fact that the new modules are being
added, with more to come...
Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
