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 2012/06/01 17:10:26 UTC
[DISCUSS] Branch for 2.6.x, trunk thoughts...
With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here
is a list of some things I'd like to start thinking about for 2.7:
1) Drop support for Java 5 - this may be a bit contentious. :-) It would
simplify the poms a little bit, allow use of @Override, remove some jars
from the lib dir, etc... The bigger issue is that several of the things we
test with and depend on are now Java 6+ such as ActiveMQ and gwt and such so
we've been stuck on older versions.
2) Async http client - this is been on my "maybe next version of CXF" for
quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-)
Would definitely help with some of the Camel integration scenarios.
3) WS-Discovery - really two parts to this. Runtime support to broadcast
availability and discover endpoints is the first part. Second part MAY be
a simple WS-Discovery proxy service for /services.
4) SOAP/UDP - Required for #3.
5) Possible re-write of the http-jetty transport to base it off the Servlet
transport or similar so it can take more advantage of things like the
services list, etc... Additionally, that may make it easier to create an
http-tomcat transport (which people DID ask about at CamelOne BTW).
Those are the things *I've* been thinking on and off about. Obviously the
other folks around here may have additional things. I'm sure Colm has
some security things, Sergey has some REST things, etc.... :-)
So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes
branch now?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Posted by "Ulhas Bhole (OS)" <ap...@gmail.com>.
+1 for both branching out and dropping Java 5 Support.
Regards,
Ulhas Bhole
On 5 Jun 2012, at 10:11, Colm O hEigeartaigh wrote:
> +1.
>
> I intend on introducing streaming WS-Security support in 2.7, which will
> depend on Santuario 2.0 and WSS4J 2.0, both of which are slated to require
> JDK 1.6.
>
> Colm.
>
> On Fri, Jun 1, 2012 at 4:10 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
>> about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here
>> is a list of some things I'd like to start thinking about for 2.7:
>>
>> 1) Drop support for Java 5 - this may be a bit contentious. :-) It would
>> simplify the poms a little bit, allow use of @Override, remove some jars
>> from the lib dir, etc... The bigger issue is that several of the things we
>> test with and depend on are now Java 6+ such as ActiveMQ and gwt and such
>> so
>> we've been stuck on older versions.
>>
>> 2) Async http client - this is been on my "maybe next version of CXF" for
>> quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-)
>> Would definitely help with some of the Camel integration scenarios.
>>
>> 3) WS-Discovery - really two parts to this. Runtime support to broadcast
>> availability and discover endpoints is the first part. Second part MAY be
>> a simple WS-Discovery proxy service for /services.
>>
>> 4) SOAP/UDP - Required for #3.
>>
>> 5) Possible re-write of the http-jetty transport to base it off the Servlet
>> transport or similar so it can take more advantage of things like the
>> services list, etc... Additionally, that may make it easier to create an
>> http-tomcat transport (which people DID ask about at CamelOne BTW).
>>
>> Those are the things *I've* been thinking on and off about. Obviously the
>> other folks around here may have additional things. I'm sure Colm has
>> some security things, Sergey has some REST things, etc.... :-)
>>
>> So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes
>> branch now?
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Posted by Colm O hEigeartaigh <co...@apache.org>.
+1.
I intend on introducing streaming WS-Security support in 2.7, which will
depend on Santuario 2.0 and WSS4J 2.0, both of which are slated to require
JDK 1.6.
Colm.
On Fri, Jun 1, 2012 at 4:10 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
> about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here
> is a list of some things I'd like to start thinking about for 2.7:
>
> 1) Drop support for Java 5 - this may be a bit contentious. :-) It would
> simplify the poms a little bit, allow use of @Override, remove some jars
> from the lib dir, etc... The bigger issue is that several of the things we
> test with and depend on are now Java 6+ such as ActiveMQ and gwt and such
> so
> we've been stuck on older versions.
>
> 2) Async http client - this is been on my "maybe next version of CXF" for
> quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-)
> Would definitely help with some of the Camel integration scenarios.
>
> 3) WS-Discovery - really two parts to this. Runtime support to broadcast
> availability and discover endpoints is the first part. Second part MAY be
> a simple WS-Discovery proxy service for /services.
>
> 4) SOAP/UDP - Required for #3.
>
> 5) Possible re-write of the http-jetty transport to base it off the Servlet
> transport or similar so it can take more advantage of things like the
> services list, etc... Additionally, that may make it easier to create an
> http-tomcat transport (which people DID ask about at CamelOne BTW).
>
> Those are the things *I've* been thinking on and off about. Obviously the
> other folks around here may have additional things. I'm sure Colm has
> some security things, Sergey has some REST things, etc.... :-)
>
> So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes
> branch now?
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 11/06/12 14:35, Sergey Beryozkin wrote:
> Hi Dan, All,
>
> sorry for a delay
>
> On 08/06/12 20:55, Daniel Kulp wrote:
>>
>> Not really much of a discussion, but no objections either. Thus, I'll go
>> ahead and create the branch. :-)
>>
>> Dan
>>
>>
>> On Friday, June 01, 2012 11:10:26 AM Daniel Kulp wrote:
>>> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
>>> about creating a 2.6.x-fixes branch and changing trunk to target 2.7.
>>> Here is a list of some things I'd like to start thinking about for 2.7:
>>>
>>> 1) Drop support for Java 5 - this may be a bit contentious. :-) It
>>> would simplify the poms a little bit, allow use of @Override, remove
>>> some
>>> jars from the lib dir, etc... The bigger issue is that several of the
>>> things we test with and depend on are now Java 6+ such as ActiveMQ and
>>> gwt and such so we've been stuck on older versions.
>>>
> +1
>
>>> 2) Async http client - this is been on my "maybe next version of CXF"
>>> for
>>> quite a while. Since 2.3.x I think. Maybe I'll actually get to it.
>>> :-) Would definitely help with some of the Camel integration scenarios.
>>>
>>> 3) WS-Discovery - really two parts to this. Runtime support to broadcast
>>> availability and discover endpoints is the first part. Second part MAY
>>> be a simple WS-Discovery proxy service for /services.
>>>
>>> 4) SOAP/UDP - Required for #3.
>>>
>>> 5) Possible re-write of the http-jetty transport to base it off the
>>> Servlet transport or similar so it can take more advantage of things
>>> like
>>> the services list, etc... Additionally, that may make it easier to
>>> create an http-tomcat transport (which people DID ask about at CamelOne
>>> BTW).
>
> Hope the JAX-RS frontend will benefit from 2) :-)
>
>>>
>>> Those are the things *I've* been thinking on and off about. Obviously
>>> the
>>> other folks around here may have additional things. I'm sure Colm has
>>> some security things, Sergey has some REST things, etc.... :-)
>>>
> There are few new features/improvements I'd like to focus upon in the
> next 6-12 months, apart from starting to work on implementing JAX-RS 2.0:
> 1. Security related enhancements
> - Continue working with Colm and Oli on SAML-based SSO (CXF, Fediz),
> though I did not work with Fediz yet
> - OAuth 2.0 and OpendId Connect - at the very least CXF
> AuthorizationService should be able to work with OpenId Connect
> endpoints provided by the third party - this part should be fairly easy
> to implement but there's a lot of new material there so it will take a
> bit of time to test/implement
> - OAuth 2.0, Fediz and SAML - we may want to provide an option for Fediz
> to produce SAML pr even JWT assertions as recommended by the relevant
> OAuth profiles
>
> 2. 'Connecting' FIQL queries with JPA as proposed by Jeff Wang - I think
> it needs to be prioritized; possible support for the alternative OData
> language
> 3. Light weight HTTP RM support - Aki and myself talked briefly about it
> with, I'll post an update shortly - not sure it's for 2.7 though
> 4. Looks like Web Sockets can become one of the main tools for building
> Web UI. People say they are not RESTful, but users will inevitably
> expect some support for it soon enough. So perhaps we can consider
> introducing an api similar to the Continuations one CXF already has that
> will be usable with Tomcat/Jetty, or at least introduce a Jetty centric
> module - again not sure it's for 2.7 but more investigation is needed
>
>
>>> So I guess the big question is: anyone OBJECT to creating the
>>> 2.6.x-fixes
>>> branch now?
>
> The only concern I had about it (it came to me when I was on holidays
> :-)) was where we'd have JAX-RS 2.0 implemented. Postponing it till 2.8
> may not be ideal as introducing 2.8 say early in 2013 will give us 5
> branches (including the trunk) and starting implementing it later in
> 2013 will be a bit late.
>
> I think the right thing to do would be to state upfront that CXF 2.7
> will have at least the basic JAX-RS 2.0 support, for example, CXF 2.7.0
> will have the dependencies changed only with the base JAX-RS Response,
> UriBuilder, etc updated. CXF 2.7.1/etc will start introducing more
> support. That should work, we don't have to get all JAX-RS 2.0
> implemented in one go
I've started the upgrade process on the trunk only, I think we will have
a fairly basic server-side JAX-RS 2.0 support in CXF 2.7.0, but the
process has started :-).
Cheers, Sergey
>
> Does it sound reasonable ?
>
> Cheers, Sergey
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan, All,
sorry for a delay
On 08/06/12 20:55, Daniel Kulp wrote:
>
> Not really much of a discussion, but no objections either. Thus, I'll go
> ahead and create the branch. :-)
>
> Dan
>
>
> On Friday, June 01, 2012 11:10:26 AM Daniel Kulp wrote:
>> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
>> about creating a 2.6.x-fixes branch and changing trunk to target 2.7.
>> Here is a list of some things I'd like to start thinking about for 2.7:
>>
>> 1) Drop support for Java 5 - this may be a bit contentious. :-) It
>> would simplify the poms a little bit, allow use of @Override, remove some
>> jars from the lib dir, etc... The bigger issue is that several of the
>> things we test with and depend on are now Java 6+ such as ActiveMQ and
>> gwt and such so we've been stuck on older versions.
>>
+1
>> 2) Async http client - this is been on my "maybe next version of CXF" for
>> quite a while. Since 2.3.x I think. Maybe I'll actually get to it.
>> :-) Would definitely help with some of the Camel integration scenarios.
>>
>> 3) WS-Discovery - really two parts to this. Runtime support to broadcast
>> availability and discover endpoints is the first part. Second part MAY
>> be a simple WS-Discovery proxy service for /services.
>>
>> 4) SOAP/UDP - Required for #3.
>>
>> 5) Possible re-write of the http-jetty transport to base it off the
>> Servlet transport or similar so it can take more advantage of things like
>> the services list, etc... Additionally, that may make it easier to
>> create an http-tomcat transport (which people DID ask about at CamelOne
>> BTW).
Hope the JAX-RS frontend will benefit from 2) :-)
>>
>> Those are the things *I've* been thinking on and off about. Obviously the
>> other folks around here may have additional things. I'm sure Colm has
>> some security things, Sergey has some REST things, etc.... :-)
>>
There are few new features/improvements I'd like to focus upon in the
next 6-12 months, apart from starting to work on implementing JAX-RS 2.0:
1. Security related enhancements
- Continue working with Colm and Oli on SAML-based SSO (CXF, Fediz),
though I did not work with Fediz yet
- OAuth 2.0 and OpendId Connect - at the very least CXF
AuthorizationService should be able to work with OpenId Connect
endpoints provided by the third party - this part should be fairly easy
to implement but there's a lot of new material there so it will take a
bit of time to test/implement
- OAuth 2.0, Fediz and SAML - we may want to provide an option for Fediz
to produce SAML pr even JWT assertions as recommended by the relevant
OAuth profiles
2. 'Connecting' FIQL queries with JPA as proposed by Jeff Wang - I think
it needs to be prioritized; possible support for the alternative OData
language
3. Light weight HTTP RM support - Aki and myself talked briefly about it
with, I'll post an update shortly - not sure it's for 2.7 though
4. Looks like Web Sockets can become one of the main tools for building
Web UI. People say they are not RESTful, but users will inevitably
expect some support for it soon enough. So perhaps we can consider
introducing an api similar to the Continuations one CXF already has that
will be usable with Tomcat/Jetty, or at least introduce a Jetty centric
module - again not sure it's for 2.7 but more investigation is needed
>> So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes
>> branch now?
The only concern I had about it (it came to me when I was on holidays
:-)) was where we'd have JAX-RS 2.0 implemented. Postponing it till 2.8
may not be ideal as introducing 2.8 say early in 2013 will give us 5
branches (including the trunk) and starting implementing it later in
2013 will be a bit late.
I think the right thing to do would be to state upfront that CXF 2.7
will have at least the basic JAX-RS 2.0 support, for example, CXF 2.7.0
will have the dependencies changed only with the base JAX-RS Response,
UriBuilder, etc updated. CXF 2.7.1/etc will start introducing more
support. That should work, we don't have to get all JAX-RS 2.0
implemented in one go
Does it sound reasonable ?
Cheers, Sergey
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Posted by Daniel Kulp <dk...@apache.org>.
Not really much of a discussion, but no objections either. Thus, I'll go
ahead and create the branch. :-)
Dan
On Friday, June 01, 2012 11:10:26 AM Daniel Kulp wrote:
> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts
> about creating a 2.6.x-fixes branch and changing trunk to target 2.7.
> Here is a list of some things I'd like to start thinking about for 2.7:
>
> 1) Drop support for Java 5 - this may be a bit contentious. :-) It
> would simplify the poms a little bit, allow use of @Override, remove some
> jars from the lib dir, etc... The bigger issue is that several of the
> things we test with and depend on are now Java 6+ such as ActiveMQ and
> gwt and such so we've been stuck on older versions.
>
> 2) Async http client - this is been on my "maybe next version of CXF" for
> quite a while. Since 2.3.x I think. Maybe I'll actually get to it.
> :-) Would definitely help with some of the Camel integration scenarios.
>
> 3) WS-Discovery - really two parts to this. Runtime support to broadcast
> availability and discover endpoints is the first part. Second part MAY
> be a simple WS-Discovery proxy service for /services.
>
> 4) SOAP/UDP - Required for #3.
>
> 5) Possible re-write of the http-jetty transport to base it off the
> Servlet transport or similar so it can take more advantage of things like
> the services list, etc... Additionally, that may make it easier to
> create an http-tomcat transport (which people DID ask about at CamelOne
> BTW).
>
> Those are the things *I've* been thinking on and off about. Obviously the
> other folks around here may have additional things. I'm sure Colm has
> some security things, Sergey has some REST things, etc.... :-)
>
> So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes
> branch now?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com