from:"Christian Schneider"

2017-11-17 4:40 GMT+01:00 Jeff Genender <jgenen...@apache.org>:

>
>
> > On Nov 16, 2017, at 6:02 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
> >
> > I am not sure sure about the need for Java 9 modules. Currently I see no
> > user requesting this.
>
> We need a user to request it?  Whats wrong with us looking in a crystal
> ball?  Doesn’t one of our own committers count as a user requesting it?
>

Absolutely Sergeys request is surely valid. I just fear the additional
overhead and that a java 9 master might prevent some java 8 developers from
supplying patches as they would be forced to develop on java 9.
So I completely agree that we will have a java 9 master at some point ..
The question is only when. My approach to this is to switch as late as
possible while still allowing us to explore java 9.

>
> > It is also not yet fully clear how these modules
> > behave in OSGi.
>
> They are just jars with manifests, no?  I would believe they would both
> operate based on their own manifest file contents.  Let stay it and find
> out. ;-). No harm no foul.
>

Yes. I completely agree to try this. I would rather experiment with this in
a side branch though. The ideal solution would be a jar that is both a java
9 module and a regular java 8 jar. Not sure if that works though.
If Dans assumption is right that all our deps must be JAva 9 modules before
we switch this will take quite a while anyway. So I think the right time to
switch to add java 9 modules is when all dependencies are modules.
For other java 9 features we might want to provide support earlier though.

>
> >
> > So I think the current situation with a master that works on Java 9 and
> > Java 8 is a pretty good situation that we should keep for as long as
> > possible.
> > I am not sure how attractive the other Java 9 features are. Personally I
> > were really eager to adopt Java 8 because of the closures but I see no
> real
> > need for myself to rush to java 9.
> >
>
> But others do use it.  I'm one of those who did go all in JDK 9… call me a
> cutting edge person. ;-). I have people asking me all the time about this.
> Different strokes for different folks. ;-)
>
> > When I remember how reluctant we were when it came to adopting the
> previous
> > java versions like 7 and 8 as minimal requirement I think it makes sense
> to
> > do this rather slowly.
>
> And what did that reluctancy buy us except people wondering what is taking
> so long.  Why not get ahead of the curve this time instead of being
> dinosaurs and the last ones to the table.
>
> Whats the harm in doing it?  Its just a git repo that has zero impact on
> the Java 8 code base.  Everything will feed it as an upstream code base.
>

The harm is that every change in CXF will be coded and tested on the Java 9
master first then. Additionally it would need to be backported to the older
branches. So we would force all CXF developers to switch to Java 9.
This is the price and it will be especially high while most people are
still on Java 8.

On the other hand the gain is that Java 9 developers can already work with
Java 9 features. At the start this gain is very low. It will grow over time
when people migrate to Java 9.

So the question is simply when there is the right time for this switch.

Christian

-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

Re: New Java 9 master

I mean simple in regard to everyday work on the code. The effort would be
mainly in setting up this build once.

I simply had bad experiences in the past with a master that is never
released for a long time. For example there was a camel 3 master for a long
time and it deteriorated more and more over time as people concentrated on
the code that was going into the releases they use on a daily basis. So no
one really cared about a master that everyone knew is not released anytime
(soon).

Personally I even prefer to simply stay on a java 8+9 master until a big
percentage of people switched to java 9. This will not allow us to use java
9 features until then but honestly I personally have no intention to ever
switch to java 9. I will probably wait if java 10 brings anything
convincing.

Christian

2017-11-16 16:57 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Sorry, looks like a pretty messy and non convincing plan to me.
> Simple for users and us ? Seriously ? This would be Java 9 only branch
> would be released probably once in at least a year time from now.
>
> Cheers, Sergey
>
> On 16/11/17 15:42, Christian Schneider wrote:
>
>> So lets make this a little more concrete. What do we expect that people do
>> in the Java 9 master?
>>
>> Java 9 modules -> As Andriy explained this only works when all our
>> dependencies are Java 9 modules. So this will not be near term.
>> Java 9 reactive streams. Could be interesting but there is already rxjava
>> and project reactor. So people have the reactive capabilities already. So
>> I
>> am not sure how many people are really interested in this. We can do kind
>> of a poll on the user list.
>> I do not think there are any other Java 9 features that are really an
>> incentive for a java 9 only branch.
>>
>> So I think the Java 9 only code could be limited to only a few modules.
>> For
>> example we could have a REST client with java 9 Flow support.
>> So how about having a build that checks if the developer has a jdk8. If
>> yes
>> then we skip the java 9 modules in the build. If the developer has java 9
>> we build all modules. We could then do our release with Java 9 but make
>> sure that most modules can run with java 8 and only the few java 9 modules
>> require java 9. Not sure if that is possible but it would make our and the
>> users life a lot simpler than a pure java 9 master.
>>
>> Christian
>>
>>
>> 2017-11-16 15:02 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:
>>
>> Indeed it will take a long time for a team with the limited resources to
>>> have CXF embracing Java 9. Postponing the start of this long process for
>>> 2
>>> years or so and wait for the users to come in and say, when will CXF will
>>> do what SpringBoot with Java 9 can do, is not strategically right move
>>> IMHO.
>>>
>>> Have the Java 9 branch, let people spend as much time as needed to play
>>> there, keep going with Java 8+9 in 3.2.1. I don't see where the conflict
>>> is.
>>>
>>> Cheers. Sergey
>>>
>>> On 16/11/17 13:53, Andriy Redko wrote:
>>>
>>> Modules are really far away in the future (IMHO). As per my
>>>> understanding, we
>>>> could think about real modules only when all our dependencies are
>>>> modularized,
>>>> which would take quite a lot of time I suppose. The Reactive Streams
>>>> part
>>>> is
>>>> really appealing *BUT* even there we **could** keep the same master for
>>>> 8
>>>> and 9
>>>> (http://openjdk.java.net/jeps/238).
>>>>
>>>> Honestly, I am not 100% sure we have to branch off the new master and
>>>> keep it
>>>> Java 9 only right now. May be the good moment will be when we
>>>> discountinue
>>>> 3.1.x so at least the code will be much easier to cherry-pick?
>>>>
>>>> Best Regards,
>>>>  Andriy Redko
>>>>
>>>> CS> I am not sure sure about the need for Java 9 modules. Currently I
>>>> see
>>>> no
>>>> CS> user requesting this. It is also not yet fully clear how these
>>>> modules
>>>> CS> behave in OSGi. As far as I understood as soon as we start with this
>>>> we
>>>> CS> have code that is not working in Java 8. As we require every change
>>>> to be
>>>> CS> done in master first this means we have a lot of back port work. A
>>>> Java 9
>>>> CS> only master will also make it much harder for Java 8 users t

Re: New Java 9 master

 seen successfull builds from
>>>>> https://builds.apache.org/job/CXF-Master-JDK9) ?
>>>>>
>>>>
>> Best Regards,
>>>>>   Andriy Redko
>>>>>
>>>>
>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>>>>> SB> development.
>>>>>
>>>>
>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>>>>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>>>>> amount
>>>>> SB> of time to materialize.
>>>>>
>>>>
>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>>>>> SB> support. It will have new features that only work with Java 9 and
>>>>> may
>>>>> SB> give new ideas for the contributions.
>>>>>
>>>>
>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>>>>> years
>>>>> SB> at least for it to retire, giving Java 8 support.
>>>>>
>>>>
>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>>>>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
>>>>>
>>>>
>> SB> Sergey
>>>>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>>>>>
>>>>
>> On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>> I dont think we can already predict when users move to Java 9.
>>>>>>>> So creating a Java 9 only branch at this time means we have to
>>>>>>>> maintain two
>>>>>>>> main branches over a long time.
>>>>>>>>
>>>>>>>
>> What is the rationale behind a Java 9 only branch compared to being
>>>>>>>> Java 9
>>>>>>>> and Java 8 compatible on master?
>>>>>>>>
>>>>>>>
>>
>> I also don't see a good reason to do that at the moment. Let's release
>>>>>>> the XJC plugin and users should be able to use CXF with Java 9 or am
>>>>>>> I
>>>>>>> missing something?
>>>>>>>
>>>>>>
>> Cheers
>>>>>>> Dennis
>>>>>>>
>>>>>>
>>
>>
>>
>>
>> CS> --
>>
>>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

Re: New Java 9 master

I am not sure sure about the need for Java 9 modules. Currently I see no
user requesting this. It is also not yet fully clear how these modules
behave in OSGi. As far as I understood as soon as we start with this we
have code that is not working in Java 8. As we require every change to be
done in master first this means we have a lot of back port work. A Java 9
only master will also make it much harder for Java 8 users to supply pull
requests as they have to develop and test on java 9 which is not their
production system.

So I think the current situation with a master that works on Java 9 and
Java 8 is a pretty good situation that we should keep for as long as
possible.
I am not sure how attractive the other Java 9 features are. Personally I
were really eager to adopt Java 8 because of the closures but I see no real
need for myself to rush to java 9.

When I remember how reluctant we were when it came to adopting the previous
java versions like 7 and 8 as minimal requirement I think it makes sense to
do this rather slowly.

Christian

2017-11-16 13:31 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Hi Andriy
>
> I'm only presuming that yes, a Java 9 only master would have to support
> the new Java 9 modules system, so I'd say a lot of exciting work would
> await for the CXF dev community :-)
>
> Cheers, Sergey
>
> On 16/11/17 12:19, Andriy Redko wrote:
>
>> Hey Sergey,
>>
>> Do we have a goal to support Java 9 modules (aka Jigsaw) for
>> the new master branch? Or we just looking to benefit from the
>> latest changes in stardand library (as you mentioned, Flow & Co,
>> collections are also a good example)? Is our current master JDK9
>> compatible actually (haven't seen successfull builds from
>> https://builds.apache.org/job/CXF-Master-JDK9) ?
>>
>> Best Regards,
>>  Andriy Redko
>>
>> SB> It's pretty simple really. It's about having a new impetus for the CXF
>> SB> development.
>>
>> SB> Without a Java 9 only master CXF will be about fixing the bugs only.
>> SB> JAX-WS is done long time ago, next version of JAX-RS will take N
>> amount
>> SB> of time to materialize.
>>
>> SB> Java 9 with its Flow class will let CXF do new work around Reactive
>> SB> support. It will have new features that only work with Java 9 and may
>> SB> give new ideas for the contributions.
>>
>> SB> 3.2.x is at the start of its life-cycle and will have a couple of
>> years
>> SB> at least for it to retire, giving Java 8 support.
>>
>> SB> 3.1.x has probably 6 months or so left in it, and after it's gone we
>> SB> will have 3.2.x and 4.0.x or whatever new version is preferred.
>>
>> SB> Sergey
>> SB> On 16/11/17 08:15, Dennis Kieselhorst wrote:
>>
>>> On 2017-11-16 07:27, Christian Schneider <ch...@die-schneider.net>
>>>> wrote:
>>>>
>>>>> I dont think we can already predict when users move to Java 9.
>>>>> So creating a Java 9 only branch at this time means we have to
>>>>> maintain two
>>>>> main branches over a long time.
>>>>>
>>>>> What is the rationale behind a Java 9 only branch compared to being
>>>>> Java 9
>>>>> and Java 8 compatible on master?
>>>>>
>>>>
>>>> I also don't see a good reason to do that at the moment. Let's release
>>>> the XJC plugin and users should be able to use CXF with Java 9 or am I
>>>> missing something?
>>>>
>>>> Cheers
>>>> Dennis
>>>>
>>>>
>>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

Re: New Java 9 master

2017-11-15 Thread Christian Schneider

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?

Christian

2017-11-15 12:47 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Hi
>
> Should we open a new Java 9 only master soon enough ?
>
> Thanks, Sergey
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

[RESULT][VOTE] - Release Apache CXF DOSGi 2.3.0 .. take 2

2017-10-03 Thread Christian Schneider

With 5 +1 this vote passes.

Christian

2017-09-25 16:25 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:

> +1 (minor quibble : There are ^M characters in the license + notice in the
> distribution).
>
> Colm.
>
> On Mon, Sep 25, 2017 at 1:41 AM, Freeman Fang <freeman.f...@gmail.com>
> wrote:
>
> > +1
> > －
> > Freeman(Yue) Fang
> >
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> >
> >
> >
> > > On Sep 23, 2017, at 6:46 PM, Christian Schneider <
> > ch...@die-schneider.net> wrote:
> > >
> > > This is a vote to release Apache CXF-DOSGi 2.3.0.
> > >
> > > I cut a second release as the first one missed the LICENSE and NOTICE
> > files
> > > in the correct position. As another small improvement I upgraded to
> jline
> > > 3.5.1 which has better colors on windows.
> > >
> > > Highlights:
> > >
> > > * The multi bundle distro is now built using bnd-export-plugin and a
> > bndrun
> > > file instead of by exporting karaf features. The new approach makes
> sure
> > > the bundles form a consistent and minimal deployment. In fact the
> distro
> > in
> > > now only 15MB instead of 22 MB.
> > >
> > > * The multi bundle distro now includes apache felix and can be directly
> > > started
> > >
> > > * We do not list the bundles in the config anymore. Felix simply starts
> > all
> > > bundles in the directory bundle. There are also no more start level
> > tweaks.
> > >
> > > * The distro now uses the felix http service instead of pax web. This
> > saves
> > > us a lot of bundles
> > >
> > > I found one issue which I can not fix before the release as requires a
> > CXF
> > > release:
> > > https://issues.apache.org/jira/browse/DOSGI-276
> > > Another issue is an exception thrown by gogo jline when starting the
> > > distro. I will try to get that fixed too for 2.4.0.
> > >
> > >
> > > Release Notes - CXF Distributed OSGi - Version 2.3.0
> > >
> > > ** Bug
> > >* [DOSGI-254] - ServiceInvocationHandler does not handle checked
> > > super-interface exceptions correctly
> > >* [DOSGI-267] - ContainerRequestFilter intents do not get registered
> > as
> > > providers
> > >* [DOSGI-275] - Include felix and samples in multibundle distro
> > >
> > > ** Improvement
> > >* [DOSGI-273] - Use bnd resolver to create multibundle distro
> > >* [DOSGI-274] - Upgrade to CXF 3.2.0
> > >
> > >
> > > Tag:
> > > https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=
> > tag;h=refs/tags/cxf-dosgi-2.3.0
> > >
> > > Maven Artifacts:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1106
> > >
> > >
> > > +1 from me.
> > >
> > >
> > >
> > > Christian
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> 2bd062c5a7e
> > 46=http%3a%2f%2fwww.liquid-reality.de>
> > >
> > > Open Source Architect
> > > http://www.talend.com
> > > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> 2bd062c5a7e
> > 46=http%3a%2f%2fwww.talend.com>
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com

[VOTE] - Release Apache CXF DOSGi 2.3.0 .. take 2

2017-09-23 Thread Christian Schneider

This is a vote to release Apache CXF-DOSGi 2.3.0.

I cut a second release as the first one missed the LICENSE and NOTICE files
in the correct position. As another small improvement I upgraded to jline
3.5.1 which has better colors on windows.

Highlights:

* The multi bundle distro is now built using bnd-export-plugin and a bndrun
file instead of by exporting karaf features. The new approach makes sure
the bundles form a consistent and minimal deployment. In fact the distro in
now only 15MB instead of 22 MB.

* The multi bundle distro now includes apache felix and can be directly
started

* We do not list the bundles in the config anymore. Felix simply starts all
bundles in the directory bundle. There are also no more start level tweaks.

* The distro now uses the felix http service instead of pax web. This saves
us a lot of bundles

I found one issue which I can not fix before the release as requires a CXF
release:
https://issues.apache.org/jira/browse/DOSGI-276
Another issue is an exception thrown by gogo jline when starting the
distro. I will try to get that fixed too for 2.4.0.

Release Notes - CXF Distributed OSGi - Version 2.3.0

** Bug
* [DOSGI-254] - ServiceInvocationHandler does not handle checked
super-interface exceptions correctly
* [DOSGI-267] - ContainerRequestFilter intents do not get registered as
providers
* [DOSGI-275] - Include felix and samples in multibundle distro

** Improvement
* [DOSGI-273] - Use bnd resolver to create multibundle distro
* [DOSGI-274] - Upgrade to CXF 3.2.0

Tag:
https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.3.0

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1106

+1 from me.

Christian

--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0

2017-09-22 Thread Christian Schneider

I agree ..better be safe than sorry in legal issues.

I will cut a new release but it will take some time as I already cleaned my
work notebook to return it.
I hope I can prepare my home windows system for a release.

Christian

2017-09-22 14:15 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:

> From: http://www.apache.org/dev/licensing-howto.html
>
> "LICENSE and NOTICE belong at the top level of the source tree
> <http://www.apache.org/legal/src-headers.html#notice>.". I'm not sure if
> this is a hard requirement, but I would say it's probably better to fix it
> for this release.
>
> Colm.
>
> On Fri, Sep 22, 2017 at 12:54 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
> > No .. I forgot to place them in the top level dir.
> > I will fix this. Do you think it is ok to fix this for the next release?
> >
> > Christian
> >
> > 2017-09-22 13:08 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:
> >
> > > Thanks. In the distribution, is there a reason the LICENSE + NOTICE
> file
> > > are hidden away in "target/maven-shared-archive-resources/META-INF"
> > > instead
> > > of the root directory of the distribution?
> > >
> > > Colm.
> > >
> > > On Fri, Sep 22, 2017 at 11:53 AM, Christian Schneider <
> > > ch...@die-schneider.net> wrote:
> > >
> > > > Hmm .. somehow I posted the wrong repo url. The correct one is:
> > > > https://repository.apache.org/content/repositories/orgapachecxf-1104
> > > >
> > > > Best
> > > > Christian
> > > >
> > > > 2017-09-22 12:36 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org
> >:
> > > >
> > > >> I'm getting a 404 for the maven repo:
> > > >>
> > > >> https://repository.apache.org/content/repositories/
> orgapachecxf-1094/
> > > >>
> > > >> Perhaps it's temporarily down?
> > > >>
> > > >> Colm.
> > > >>
> > > >> On Thu, Sep 21, 2017 at 5:23 PM, Daniel Kulp <dk...@apache.org>
> > wrote:
> > > >>
> > > >> >
> > > >> > +1
> > > >> >
> > > >> > Dan
> > > >> >
> > > >> >
> > > >> >
> > > >> > > On Sep 21, 2017, at 8:43 AM, Christian Schneider <
> > > >> > ch...@die-schneider.net> wrote:
> > > >> > >
> > > >> > > This is a vote to release Apache CXF-DOSGi 2.3.0.
> > > >> > >
> > > >> > > Highlights:
> > > >> > >
> > > >> > > * The multi bundle distro is now built using bnd-export-plugin
> > and a
> > > >> > bndrun file instead of by exporting karaf features. The new
> approach
> > > >> makes
> > > >> > sure the bundles form a consistent and minimal deployment. In fact
> > the
> > > >> > distro in now only 15MB instead of 22 MB.
> > > >> > >
> > > >> > > * The multi bundle distro now includes apache felix and can be
> > > >> directly
> > > >> > started
> > > >> > >
> > > >> > > * We do not list the bundles in the config anymore. Felix simply
> > > >> starts
> > > >> > all bundles in the directory bundle. There are also no more start
> > > level
> > > >> > tweaks.
> > > >> > >
> > > >> > > * The distro now uses the felix http service instead of pax web.
> > > This
> > > >> > saves us a lot of bundles
> > > >> > >
> > > >> > > I found one issue which I can not fix before the release as
> > > requires a
> > > >> > CXF release:
> > > >> > > https://issues.apache.org/jira/browse/DOSGI-276
> > > >> > >
> > > >> > >
> > > >> > > Release Notes - CXF Distributed OSGi - Version 2.3.0
> > > >> > >
> > > >> > > ** Bug
> > > >> > >* [DOSGI-254] - ServiceInvocationHandler does not handle
> > checked
> > > >> > super-interface exceptions correctly
> > > >> > >* [DOSGI-267] - ContainerRequestFilter intents do not get
> > > >> registered
> > > >> > as providers
> > > >>

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0

2017-09-22 Thread Christian Schneider

No .. I forgot to place them in the top level dir.
I will fix this. Do you think it is ok to fix this for the next release?

Christian

2017-09-22 13:08 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:

> Thanks. In the distribution, is there a reason the LICENSE + NOTICE file
> are hidden away in "target/maven-shared-archive-resources/META-INF"
> instead
> of the root directory of the distribution?
>
> Colm.
>
> On Fri, Sep 22, 2017 at 11:53 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
> > Hmm .. somehow I posted the wrong repo url. The correct one is:
> > https://repository.apache.org/content/repositories/orgapachecxf-1104
> >
> > Best
> > Christian
> >
> > 2017-09-22 12:36 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:
> >
> >> I'm getting a 404 for the maven repo:
> >>
> >> https://repository.apache.org/content/repositories/orgapachecxf-1094/
> >>
> >> Perhaps it's temporarily down?
> >>
> >> Colm.
> >>
> >> On Thu, Sep 21, 2017 at 5:23 PM, Daniel Kulp <dk...@apache.org> wrote:
> >>
> >> >
> >> > +1
> >> >
> >> > Dan
> >> >
> >> >
> >> >
> >> > > On Sep 21, 2017, at 8:43 AM, Christian Schneider <
> >> > ch...@die-schneider.net> wrote:
> >> > >
> >> > > This is a vote to release Apache CXF-DOSGi 2.3.0.
> >> > >
> >> > > Highlights:
> >> > >
> >> > > * The multi bundle distro is now built using bnd-export-plugin and a
> >> > bndrun file instead of by exporting karaf features. The new approach
> >> makes
> >> > sure the bundles form a consistent and minimal deployment. In fact the
> >> > distro in now only 15MB instead of 22 MB.
> >> > >
> >> > > * The multi bundle distro now includes apache felix and can be
> >> directly
> >> > started
> >> > >
> >> > > * We do not list the bundles in the config anymore. Felix simply
> >> starts
> >> > all bundles in the directory bundle. There are also no more start
> level
> >> > tweaks.
> >> > >
> >> > > * The distro now uses the felix http service instead of pax web.
> This
> >> > saves us a lot of bundles
> >> > >
> >> > > I found one issue which I can not fix before the release as
> requires a
> >> > CXF release:
> >> > > https://issues.apache.org/jira/browse/DOSGI-276
> >> > >
> >> > >
> >> > > Release Notes - CXF Distributed OSGi - Version 2.3.0
> >> > >
> >> > > ** Bug
> >> > >* [DOSGI-254] - ServiceInvocationHandler does not handle checked
> >> > super-interface exceptions correctly
> >> > >* [DOSGI-267] - ContainerRequestFilter intents do not get
> >> registered
> >> > as providers
> >> > >* [DOSGI-275] - Include felix and samples in multibundle distro
> >> > >
> >> > > ** Improvement
> >> > >* [DOSGI-273] - Use bnd resolver to create multibundle distro
> >> > >* [DOSGI-274] - Upgrade to CXF 3.2.0
> >> > >
> >> > >
> >> > > Tag:
> >> > > https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=
> >> > tag;h=refs/tags/cxf-dosgi-2.3.0
> >> > >
> >> > > Maven Artifacts:
> >> > > https://repository.apache.org/content/repositories/
> orgapachecxf-1094/
> >> > >
> >> > >
> >> > > +1 from me.
> >> > >
> >> > > Christian
> >> > >
> >> > > --
> >> > > Christian Schneider
> >> > > http://www.liquid-reality.de
> >> > >
> >> > > Open Source Architect
> >> > > http://www.talend.com
> >> > >
> >> >
> >> > --
> >> > Daniel Kulp
> >> > dk...@apache.org - http://dankulp.com/blog
> >> > Talend Community Coder - http://coders.talend.com
> >> >
> >> >
> >>
> >>
> >> --
> >> Colm O hEigeartaigh
> >>
> >> Talend Community Coder
> >> http://coders.talend.com
> >>
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46=http%3a%2f%2fwww.liquid-reality.de>
> >
> > Open Source Architect
> > http://www.talend.com
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
> 46=http%3a%2f%2fwww.talend.com>
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: [VOTE] - Release Apache CXF DOSGi 2.3.0

2017-09-22 Thread Christian Schneider

Hmm .. somehow I posted the wrong repo url. The correct one is:
https://repository.apache.org/content/repositories/orgapachecxf-1104

Best
Christian

2017-09-22 12:36 GMT+02:00 Colm O hEigeartaigh <cohei...@apache.org>:

> I'm getting a 404 for the maven repo:
>
> https://repository.apache.org/content/repositories/orgapachecxf-1094/
>
> Perhaps it's temporarily down?
>
> Colm.
>
> On Thu, Sep 21, 2017 at 5:23 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > +1
> >
> > Dan
> >
> >
> >
> > > On Sep 21, 2017, at 8:43 AM, Christian Schneider <
> > ch...@die-schneider.net> wrote:
> > >
> > > This is a vote to release Apache CXF-DOSGi 2.3.0.
> > >
> > > Highlights:
> > >
> > > * The multi bundle distro is now built using bnd-export-plugin and a
> > bndrun file instead of by exporting karaf features. The new approach
> makes
> > sure the bundles form a consistent and minimal deployment. In fact the
> > distro in now only 15MB instead of 22 MB.
> > >
> > > * The multi bundle distro now includes apache felix and can be directly
> > started
> > >
> > > * We do not list the bundles in the config anymore. Felix simply starts
> > all bundles in the directory bundle. There are also no more start level
> > tweaks.
> > >
> > > * The distro now uses the felix http service instead of pax web. This
> > saves us a lot of bundles
> > >
> > > I found one issue which I can not fix before the release as requires a
> > CXF release:
> > > https://issues.apache.org/jira/browse/DOSGI-276
> > >
> > >
> > > Release Notes - CXF Distributed OSGi - Version 2.3.0
> > >
> > > ** Bug
> > >* [DOSGI-254] - ServiceInvocationHandler does not handle checked
> > super-interface exceptions correctly
> > >* [DOSGI-267] - ContainerRequestFilter intents do not get registered
> > as providers
> > >* [DOSGI-275] - Include felix and samples in multibundle distro
> > >
> > > ** Improvement
> > >* [DOSGI-273] - Use bnd resolver to create multibundle distro
> > >* [DOSGI-274] - Upgrade to CXF 3.2.0
> > >
> > >
> > > Tag:
> > > https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=
> > tag;h=refs/tags/cxf-dosgi-2.3.0
> > >
> > > Maven Artifacts:
> > > https://repository.apache.org/content/repositories/orgapachecxf-1094/
> > >
> > >
> > > +1 from me.
> > >
> > > Christian
> > >
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Open Source Architect
> > > http://www.talend.com
> > >
> >
> > --
> > Daniel Kulp
> > dk...@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

[VOTE] - Release Apache CXF DOSGi 2.3.0

2017-09-21 Thread Christian Schneider


This is a vote to release Apache CXF-DOSGi 2.3.0.

Highlights:

* The multi bundle distro is now built using bnd-export-plugin and a 
bndrun file instead of by exporting karaf features. The new approach 
makes sure the bundles form a consistent and minimal deployment. In fact 
the distro in now only 15MB instead of 22 MB.


* The multi bundle distro now includes apache felix and can be directly 
started


* We do not list the bundles in the config anymore. Felix simply starts 
all bundles in the directory bundle. There are also no more start level 
tweaks.


* The distro now uses the felix http service instead of pax web. This 
saves us a lot of bundles


I found one issue which I can not fix before the release as requires a 
CXF release:

https://issues.apache.org/jira/browse/DOSGI-276


Release Notes - CXF Distributed OSGi - Version 2.3.0

** Bug
* [DOSGI-254] - ServiceInvocationHandler does not handle checked 
super-interface exceptions correctly
* [DOSGI-267] - ContainerRequestFilter intents do not get 
registered as providers

* [DOSGI-275] - Include felix and samples in multibundle distro

** Improvement
* [DOSGI-273] - Use bnd resolver to create multibundle distro
* [DOSGI-274] - Upgrade to CXF 3.2.0


Tag:
https://gitbox.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.3.0

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1094/


+1 from me.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Release CXF-DOSGi 2.3.0 during the next days

2017-09-18 Thread Christian Schneider

Thanks for spotting this. There is an up to date release notes file in
the top of the cxf-dosgi source which I could use.
I would even prefer though to not have release notes in the source code
like you proposed.

So question to the PMC members: Are we required to have a release notes
file in the source/distro?

Christian

On 18.09.2017 16:21, Dennis Kieselhorst wrote:

Hi Christian,

sounds good. Just one short remark: The release_notes.txt file is
outdated (1.6.0 is the latest version), I think a link to the JIRA
releases page would be also ok.

I noticed an exception on startup but it doesn't seem to block anything.

Regards
Dennis

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.inspect(CommandSessionImpl.java:445)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.format(CommandSessionImpl.java:422)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.format(CommandSessionImpl.java:482)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:427)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1241)
at java.net.URLConnection.getContent(URLConnection.java:740)
at java.net.URL.getContent(URL.java:1059)
... 14 more

Am 18.09.2017 um 13:21 schrieb Christian Schneider:

I did some interesting changes to CXF-DOSGi that I think should go
into a new release soon.

- Update to CF 3.2.0. So DOSGi is now again at the forefront of CXF

- Build multi bundle distro using bnd-export-plugin. This makes the
distro a lot smaller and also easier to recreate for users to
customize it for their own distros. This way the distro is now only 15
MB instead of 22MB before.

- Make it easier to try the multi bundle distro. The distro is now
directly start-able like the new felix distros. It also includes the
examples. The distro also uses gogo jline which has shell features
similar to karaf (history, completion, coloring).

This is the full set of issues. There are 3 open issues which I intend
to move if no one steps in to work on them:

https://issues.apache.org/jira/projects/DOSGI/versions/12341079

I encourage everyone to give the current snapshot a try:

https://repository.apache.org/content/repositories/snapshots/org/apache/cxf/dosgi/cxf-dosgi-multibundle-distribution/2.3.0-SNAPSHOT/cxf-dosgi-multibundle-distribution-2.3.0-20170918.111439-13-dir.tar.gz

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.2.0

I just checked with Guillaume to get some other opinion. He also
approves going ahead with the release.

So I am back to +1 again but we should not wait too long with a 3.2.1.

Christian

On 11.09.2017 12:57, Sergey Beryozkin wrote:
3.2.0 has been open for 2 years so I doubt major OSGI integrators will
start using it immediately, will try it, not all of them necessarily
use karaf-maven-plugin. 3.2.1 will follow in a few weeks...

By the way, I see

[INFO] Verification of feature cxf-jaxrs-cdi/3.2.1.SNAPSHOT succeeded
(and it was fine with 3.2.0-SNAPSHOT)

from the Karaf Maven plugin:verify

Cheers, Sergey
On 11/09/17 11:38, Christian Schneider wrote:

Updating cxf-dosgi would of course not be a blocker.
The problem is that I think this might also block people from
building custom distros that include cxf 3.2.0.

Christian

On 11.09.2017 12:33, Sergey Beryozkin wrote:

Christian

Looks like it is only happening with the DOSGI, if you try to update
it to 3.2.0 - but does the issue you see with updating DOSGi to
3.2.0 warrants -1 ?

Can't you just wait till 3.2.1 ?

Cheers, Sergey
On 11/09/17 11:30, Christian Schneider wrote:
Reverting my vote to -1 until we have a decision about the issues I
found below.

I just tried to update cxf-dosgi to cxf 3.2.0. I get an error when
building the multi bundle distro.

[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.1.2:features-export-meta-data
(features-add-to-repository) on project
cxf-dosgi-multibundle-distribution: Error populating repository:
Can't resolve artifact
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2):
Failure to find
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2) in
https://repo.maven.apache.org/maven2 was cached in the local
repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced

So it seems like the karaf-maven-plugin does not work with a
version range in the feature file. I think this is a bug and will
report and fix it in karaf.
Even if this might be a problem in karaf I wonder if using a range
in the CXF feature is a good idea at this time. It will probably
affect all karaf users that build a custom distro.

I also tried to install the cxf-jaxrs-cdi feature from cxf 3.2.0 in
karaf. The installation works but uses the 1.0.0-SNAPSHOT of the
pax-cdi feature which is probably not what users expect.

Christian

On 06.09.2017 20:14, Daniel Kulp wrote:
It’s been 2 years since the last major CXF release.We have
well over 100 JIRA’s of new features and enhancements that are
only targeted toward 3.2. Let’s get it out!

Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48

Here is my +1

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.2.0

Updating cxf-dosgi would of course not be a blocker.
The problem is that I think this might also block people from building
custom distros that include cxf 3.2.0.

Christian

On 11.09.2017 12:33, Sergey Beryozkin wrote:

Christian

Looks like it is only happening with the DOSGI, if you try to update
it to 3.2.0 - but does the issue you see with updating DOSGi to 3.2.0
warrants -1 ?

Can't you just wait till 3.2.1 ?

Cheers, Sergey
On 11/09/17 11:30, Christian Schneider wrote:
Reverting my vote to -1 until we have a decision about the issues I
found below.

I just tried to update cxf-dosgi to cxf 3.2.0. I get an error when
building the multi bundle distro.

So it seems like the karaf-maven-plugin does not work with a version
range in the feature file. I think this is a bug and will report and
fix it in karaf.
Even if this might be a problem in karaf I wonder if using a range in
the CXF feature is a good idea at this time. It will probably affect
all karaf users that build a custom distro.

I also tried to install the cxf-jaxrs-cdi feature from cxf 3.2.0 in
karaf. The installation works but uses the 1.0.0-SNAPSHOT of the
pax-cdi feature which is probably not what users expect.

Christian

On 06.09.2017 20:14, Daniel Kulp wrote:
It’s been 2 years since the last major CXF release.We have well
over 100 JIRA’s of new features and enhancements that are only
targeted toward 3.2. Let’s get it out!

Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48

Here is my +1

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.2.0

Reverting my vote to -1 until we have a decision about the issues I
found below.

I just tried to update cxf-dosgi to cxf 3.2.0. I get an error when
building the multi bundle distro.

[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.1.2:features-export-meta-data
(features-add-to-repository) on project
cxf-dosgi-multibundle-distribution: Error populating repository: Can't
resolve artifact
org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2): Failure
to find org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2) in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central
has elapsed or updates are forced

So it seems like the karaf-maven-plugin does not work with a version
range in the feature file. I think this is a bug and will report and fix
it in karaf.
Even if this might be a problem in karaf I wonder if using a range in
the CXF feature is a good idea at this time. It will probably affect all
karaf users that build a custom distro.

I also tried to install the cxf-jaxrs-cdi feature from cxf 3.2.0 in
karaf. The installation works but uses the 1.0.0-SNAPSHOT of the pax-cdi
feature which is probably not what users expect.

Christian

On 06.09.2017 20:14, Daniel Kulp wrote:

It’s been 2 years since the last major CXF release.We have well over 100
JIRA’s of new features and enhancements that are only targeted toward 3.2.
Let’s get it out!

Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48

Here is my +1

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.2.0


+1

Christian

On 06.09.2017 20:14, Daniel Kulp wrote:

It’s been 2 years since the last major CXF release.We have well over 100 
JIRA’s of new features and enhancements that are only targeted toward 3.2.   
Let’s get it out!


Staging repo:
https://repository.apache.org/content/repositories/orgapachecxf-1102/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=79c1486ed9cf34d90a04d943ed72475500f83c48

Here is my +1




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.0.15 and 3.1.13 patch releases...


+1

Christian


On 06.09.2017 20:12, Daniel Kulp wrote:

It’s been over 2 months since the last release. We’ve fixed over 35 JIRA’s for 
3.1.13.  Thus, let’s get them out.

Staging repos:
3.0.15:
https://repository.apache.org/content/repositories/orgapachecxf-1100/
3.1.13:
https://repository.apache.org/content/repositories/orgapachecxf-1101/

Tags:
3.0.15:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=2e4c59bdfb3e503621904e91e6be7042c787bfff
3.1.13:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=4870bfd0ff967819df4cce794c8ebd61efdf92ca


Here is my +1.   Vote will be open for at least 72h.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: All CXF repos moved to gitbox....


I also just did the migration to gitbox. Some remarks:

After activating the 2FA it takes a while until the asf bot adds you to 
the team. You will get a mail once that is completed.


The link to the cxf committers team only works once you are added to the 
team. So it is normal to get a 404 until then.


Christian

On 09.09.2017 08:40, Dennis Kieselhorst wrote:

FYI, all our repos have now been moved over to gitbox.  In order to commit to 
the repos, you will need to do the gitbox setup to associate your Apache ID 
with your GitHub account.   Follow the steps at:

https://gitbox.apache.org/setup/

There are a bunch of steps starting from enabling the 2FA on GitHub, getting 
yourself added to the Apache organization, etc…


Once that is all done, you SHOULD be able to push directly to the GitHub repo 
and manage pull requests and such there.



Great, I've just changed the Jenkins Jobs to use gitbox.apache.org
instead of git-wip-us.apache.org.

Link to the Github team:
https://github.com/orgs/apache/teams/cxf-committers/members

All missing team members will automatically added by asfgit after they
have completed the Gitbox setup steps.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[RESULT] [VOTE] - Release Apache CXF DOSGi 2.2.0

2017-07-14 Thread Christian Schneider


This vote passes with 6 +1 and no other votes.

I will publish the artifacts.

Christian

On 10.07.2017 15:56, Christian Schneider wrote:

This is a vote to release Apache CXF DOSGi 2.2.0.

Highlights are swagger support, ContextProvider support and it is 
simpler to add features to a DOSGi endpoint by using @Features or the 
new IntentsProvider interface.


Most can be seen in the jax-rs sample 
https://github.com/apache/cxf-dosgi/tree/master/samples/rest



Release Notes - CXF Distributed OSGi - Version 2.2.0

** Bug
* [DOSGI-253] - CXF DOSGI JAX-RS incompatible with Camel features
* [DOSGI-262] - Configure intent objects from service object 
(IntentsProvider, @Features)
* [DOSGI-264] - Add features to OSGi service using @Features 
annotation


** Improvement
* [DOSGI-268] - Update CXF to 3.1.12
* [DOSGI-269] - Update Aries RSA to 1.11.0

** New Feature
* [DOSGI-261] - Sample for rest with jackson provider
* [DOSGI-266] - Support for org.apache.cxf.jaxrs.ext.ContextProvider
* [DOSGI-270] - Create sample for swagger documentation


Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.2.0 



Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1094/

Repo mirror:
https://github.com/apache/cxf-dosgi

+1 from me.

Christian



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[VOTE] - Release Apache CXF DOSGi 2.2.0

2017-07-10 Thread Christian Schneider


This is a vote to release Apache CXF DOSGi 2.2.0.

Highlights are swagger support, ContextProvider support and it is 
simpler to add features to a DOSGi endpoint by using @Features or the 
new IntentsProvider interface.


Most can be seen in the jax-rs sample 
https://github.com/apache/cxf-dosgi/tree/master/samples/rest



Release Notes - CXF Distributed OSGi - Version 2.2.0

** Bug
* [DOSGI-253] - CXF DOSGI JAX-RS incompatible with Camel features
* [DOSGI-262] - Configure intent objects from service object 
(IntentsProvider, @Features)

* [DOSGI-264] - Add features to OSGi service using @Features annotation

** Improvement
* [DOSGI-268] - Update CXF to 3.1.12
* [DOSGI-269] - Update Aries RSA to 1.11.0

** New Feature
* [DOSGI-261] - Sample for rest with jackson provider
* [DOSGI-266] - Support for org.apache.cxf.jaxrs.ext.ContextProvider
* [DOSGI-270] - Create sample for swagger documentation


Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.2.0

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1094/

Repo mirror:
https://github.com/apache/cxf-dosgi

+1 from me.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.1.12 and 3.0.14

2017-06-26 Thread Christian Schneider

+1

Christian

2017-06-27 0:23 GMT+02:00 Daniel Kulp <dk...@apache.org>:

> It’s been over 2 months since the last release. We’ve fixed over 50 JIRA’s
> for 3.1.12.  Thus, let’s get it out.
>
> Staging repos:
> 3.0.14:
> https://repository.apache.org/content/repositories/orgapachecxf-1093/
> 3.1.12:
> https://repository.apache.org/content/repositories/orgapachecxf-1092/
>
> Tags:
> 3.0.14:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=
> a74c456018afc62d273cb8cb0a459fec5b12d265
> 3.1.12:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=
> 6b41994254531a6ea6b2451277063c71ecfac320
>
> Here is my +1.   Vote will be open for at least 72h.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: Configurable logging categeory for payload logging

2017-04-24 Thread Christian Schneider

How about we add the type "rs" or "ws" as category before the packagename?

Christian

2017-04-24 12:28 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Hi David
>
> I can add that option back, can you try something else in meantime,
> a default JAXRS service QName is "{packagename}ClassName".
> I wonder if you set a category to this value, would it help ?
>
> Sergey
>
> On 24/04/17 09:56, David Karlsen wrote:
>
>> See change in:
>> https://issues.apache.org/jira/browse/CXF-7254
>> vs
>> https://issues.apache.org/jira/browse/CXF-6936
>>
>> our usecase:
>> we have "dualstack" jax-ws / jax-rs servers (which are also clients
>> towards
>> other systems, mainly as jax-ws clients) - and want to cleanly separate:
>> inbound jax-ws
>> inbound jax-rs
>> outbound jax-ws
>> outbound jax-rs
>>
>> traffic into distinct logs.
>> This is most easily done as a single line logger configuration in logback
>> onto distinct appenders, and thus logfiles.
>>
>> It might seem we lost this possibility with CXF-7254 ?
>>
>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: [VOTE] - Release Apache CXF Fediz 1.3.2 and 1.2.4

2017-04-24 Thread Christian Schneider

+1

Christian

2017-04-24 11:53 GMT+02:00 Jan Bernhardt <jbernha...@talend.com>:

> +1 from me.
>
>
> Jan
>
> 
> Von: Colm O hEigeartaigh <cohei...@apache.org>
> Gesendet: Freitag, 21. April 2017 14:06:55
> An: dev@cxf.apache.org
> Betreff: [VOTE] - Release Apache CXF Fediz 1.3.2 and 1.2.4
>
> This is a vote to release Apache CXF Fediz 1.3.2 and 1.2.4. The vote for
> 1.4.0 will follow next week.
>
> *1.3.2*
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1089/
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=commit;h=
> 7aff8635b4078fe952c63306e4ebb4ace25302df
>
> Issues fixed:
> https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12338091
>
> *1.2.4*
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1090/
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf-fediz.git;a=tag;h=
> 2fcb252a6931eccedac668f22f895e6a106f7f27
>
> Issues fixed:
> https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12338219/
>
> +1 from me.
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: Fred : which branch to work on?

2017-04-11 Thread Christian Schneider

Whenever possible we try to fix issues on master first and then backport to
the individual branches.

You should first clone the cxf git repo on github, then create a branch
named like the issue id. You can then work on the branch and do your
commits. The commits should have the format "[issue-id] description". When
finished you create a pull request. If the commits are named like this the
PR should automatically appear in the respective issue in jira.

Christian

2017-04-12 5:28 GMT+02:00 Fred Assi <java2010...@gmail.com>:

> Hi guys,
>
> I would like to start work on some bugs , Im not sure about your
> procedures, can you advise please?
> which branch should I pull to work on?
>
> Regards,
>
> Fred Assi
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: [VOTE] Apache CXF 3.1.11 and 3.0.13

2017-04-06 Thread Christian Schneider


+1

Christian

On 06.04.2017 01:43, Daniel Kulp wrote:

It’s been about 2 months since the last release.  However, we’ve fixed over 100 
JIRA’s for 3.1.11 which is a large number of fixes.  Thus, let’s get it out.

Staging repos:
3.0.13:
https://repository.apache.org/content/repositories/orgapachecxf-1087/
3.1.11:
https://repository.apache.org/content/repositories/orgapachecxf-1088/

Tags:
3.0.13:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=444c58f6d36243e1a73efe3f0e748091cfbd499b
3.1.11:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=2ae6483276825a93e7ebe40fbcfc11866d364530

Here is my +1.   Vote will be open for at least 72h.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: cxf git commit: [CXF-7281] Create new Logging annotation that allows to configure all settings

2017-03-13 Thread Christian Schneider

Oops :-) It is also not ignored by default.

Christian

2017-03-13 18:37 GMT+01:00 Daniel Kulp <dk...@apache.org>:

>
> > On Mar 13, 2017, at 12:50 PM, cschnei...@apache.org wrote:
> >
> > +/**
> > + * Ignore binary payloads by default
> > + */
> > +boolean logMultiplart() default true;
> > +}
>
>
> Multiplart?  :)
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

[Discuss] How do we remove the old logging

2017-03-13 Thread Christian Schneider

For some time now we have the new logging system (located in 
rt/features/logging). I would like to discuss how we transition to the 
new system.


I propose the following:

We deprecate all parts of the old logging system and define a CXF 
version when it will be removed.

The new logging should completely life in the features/logging module.

I propose we remove the old logging either in CXF 3.3 or in CXF 4 
depending if we plan to do a new major version in mid term (~ a year).


As soon as we decided which version to remove the logging in we should 
document the planned removal in the javadoc of the entry points of 
logging and on the website. So people will have an early warning.


Some implications when switching to the new system:

- When using the class switch to this class: 
org.apache.cxf.ext.logging.LoggingFeature

- When using the annotation: Switch to org.apache.cxf.ext.logging.Logging
- The xml namespace will not exist in the new system. Use either the 
class or the annotation
- Some configs of the old system will not exist in the new one. In 
general it the new system should be more flexible though


Dan is following a slightly different style by for example reusing the 
old @Logging annotation and not deprecating it. I personally would like 
to avoid that to have a clean cut.


What do you think?

Christian


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] - Release Apache CXF DOSGi 2.1.0

2017-02-15 Thread Christian Schneider


This vote passes with 5 +1 and no other votes. I will deploy the artifacts.

Christian

On 11.02.2017 19:53, Christian Schneider wrote:

This is a vote to release Apache CXF DOSGi 2.1.0.

I just found the documentation does not yet reflect the new features. 
I will fix that asap on master.
This is not ideal but I guess most people use the docs from master 
anyway.


Release Notes - CXF Distributed OSGi - Version 2.1.0

** Bug
* [DOSGI-258] - itests fail when port 8080 is in use

** Improvement
* [DOSGI-251] - Allow to export services with less service properties
* [DOSGI-256] - ContextResolver intents should be registered as 
providers

* [DOSGI-257] - Allow to set bus properties

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.1.0 



Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1086

Repo mirror:
https://github.com/apache/cxf-dosgi

+1 from me.

Christian




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[VOTE] - Release Apache CXF DOSGi 2.1.0

2017-02-11 Thread Christian Schneider


This is a vote to release Apache CXF DOSGi 2.1.0.

I just found the documentation does not yet reflect the new features. I 
will fix that asap on master.

This is not ideal but I guess most people use the docs from master anyway.

Release Notes - CXF Distributed OSGi - Version 2.1.0

** Bug
* [DOSGI-258] - itests fail when port 8080 is in use

** Improvement
* [DOSGI-251] - Allow to export services with less service properties
* [DOSGI-256] - ContextResolver intents should be registered as 
providers

* [DOSGI-257] - Allow to set bus properties

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=refs/tags/cxf-dosgi-2.1.0

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecxf-1086

Repo mirror:
https://github.com/apache/cxf-dosgi

+1 from me.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Heads up] CXF-DOSGi release this weekend

2017-02-10 Thread Christian Schneider

I would like to do another CXF-DOSGi release this weekend. It is now 
more than 3 months since the last release and we fixed some issues:


See https://issues.apache.org/jira/browse/DOSGI/fixforversion/12338258

So if anyone wants to get something into the release now would be a good 
time.


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache CXF 3.1.10

2017-01-27 Thread Christian Schneider


+1

Christian

On 27.01.2017 20:28, Daniel Kulp wrote:

This is a vote for Apache CXF 3.1.10.   We’ve fixed a bunch of issues and I’d 
like to get it out so we can start trying to concentrate on getting 3.2 out.

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1085/

Tag:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=59f79f3cfca1beb6e8f3a3a3f60f7d1d62eb8422

Vote will be open for 72h.

Here is my +1.





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[DISCUSS] Add promotion for Apache events on website

2017-01-26 Thread Christian Schneider

On the apache member list there is the request to help promoting the 
next Apachecon.


The proposal is to add the snippet below our web site. This allows the 
foundation to promote the current event.

I would like to help with this effort. Any opinions?

Christian

---

http://www.apache.org/events/current-event.html;>
http://www.apache.org/events/current-event-{size}.png"/>


where {size} = 125x125 or 234x60

Maintenance of current-event* files:
- update text in content/events/current-event.mdtext
- replace content/events/current-event-*.png files with the new versions from 
content/ads/ApacheCon

See also content/ads/README.txt


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] - Release Apache CXF XJC Utils 3.1.0

2016-12-15 Thread Christian Schneider


+1

Christian

On 15.12.2016 17:32, Colm O hEigeartaigh wrote:

This is a vote to release Apache CXF XJC Utils 3.1.0.

Artifacts:

https://repository.apache.org/content/repositories/orgapachecxf-1084/

Git tag:

https://git-wip-us.apache.org/repos/asf?p=cxf-xjc-utils.git;a=commit;h=729224ef42279fff2c7faeb0d2e7c7a4152799ad

Issues fixed:

https://issues.apache.org/jira/browse/CXFXJC/fixforversion/12338810

+1 from me.

Colm.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] CXF 3.1.9 and 3.0.12

2016-12-12 Thread Christian Schneider

Would it be ok to tackle this in the next bugfix release and maybe get
it out a little quicker? (Like 2-3 weeks instead of the usual 4 weeks)

Christian

On 11.12.2016 17:27, John D. Ament wrote:

No, I -0'd a release because something's busted. I raised the PR to fix
that busted thing.

John

On Sun, Dec 11, 2016 at 11:03 AM Jeff Genender <jgenen...@apache.org> wrote:

You -0’d a release because the pull request that you submitted at 12/11/16
15:30 GMT didn’t make it into a release whose vote was kicked off nearly 42
hours before at 12/9/16 21:47 GMT?

Seriously?

Jeff

On Dec 11, 2016, at 7:16 AM, John D. Ament <johndam...@apache.org>

wrote:

I did find one issue. Its not a new issue, but the CDI integration

changes

made the problem more profound when using CXF + Weld in an Arquillian

test.

https://issues.apache.org/jira/browse/CXF-7175

So -0 since I won't be able to upgrade yet.

On Fri, Dec 9, 2016 at 3:47 PM Daniel Kulp <dk...@apache.org> wrote:

Since there are several folks waiting for this release and it would be
good to get it out before the holidays, I’d like to call a vote for CXF
3.1.9 and 3.0.12.

Staging areas:
3.1.9:
https://repository.apache.org/content/repositories/orgapachecxf-1083/
3.0.12:
https://repository.apache.org/content/repositories/orgapachecxf-1082/

Tags:
3.0.12:

https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=c98cb3181ae1153c37240a851aefe8e4f3a40ae9

3.1.9:

https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=7cd4d49a7fe7d24a715192112a2170bdd708e6c7

Vote will be open for 72h.

Here is my +1.

--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] CXF 3.1.9 and 3.0.12

2016-12-10 Thread Christian Schneider

+1

Christian

2016-12-10 19:51 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org>:

> On 9 Dec 2016 21:47:05 CET, Daniel Kulp <dk...@apache.org> wrote:
> >Since there are several folks waiting for this release and it would be
> >good to get it out before the holidays, I’d like to call a vote for CXF
> >3.1.9 and 3.0.12.
> >
> >Staging areas:
> >3.1.9:
> >https://repository.apache.org/content/repositories/orgapachecxf-1083/
> >3.0.12:
> >https://repository.apache.org/content/repositories/orgapachecxf-1082/
> >
> >Tags:
> >3.0.12:
> >https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=
> c98cb3181ae1153c37240a851aefe8e4f3a40ae9
> >3.1.9:
> >https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=
> 7cd4d49a7fe7d24a715192112a2170bdd708e6c7
> >
> >
> >Vote will be open for 72h.
>
> +1
> Regards
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF,
> OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave

2016-12-08 Thread Christian Schneider

The new logging support in rt/features/logging already creates exchange 
id and message id. It also allows to send the message id over the wire.
I have already fed the data into elastic search. There I was able to 
correlate request to reply and request sent out from the client to 
request received on the server.


Would that already work?

See http://cxf.apache.org/docs/message-logging.html

Christian

On 08.12.2016 08:58, Romain Manni-Bucau wrote:

Hello guys,

would it make sense to have a lighter tracker in cxf? idea is just to have
a header accumulator but not all the data zipkin requires. I often saw it
used in companies to track the data path but often it is self contained and
only contains the host list. In term of delivery it would be a jaxrs
client/server provider (or interceptor) to handle the header and soap
equivalent probably. Wdyt?

(to make it clear client1 would send Cxf-Tracking: host1, if received on
host2 the program does another request it will send Cxf-Tracking:
host1,host2 etc...)





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave

2016-12-07 Thread Christian Schneider

Would be great if we could work together on this. I saw that you were part
of the brave-cxf development.
Maybe you could start with the actual tracing in cxf.
For me another important part is the brave OSGi integration and CXF-DOSGi
integration. So I could start with that.

I am not sure where to put the brave OSGi part as it is not really related
to CXF but an important prerequisite to get it working in OSGi.
Maybe this can go to brave itself. I am thinking about a config driven
Brave OSGi service. So you simply need to create a config and get a working
service. The CXF tracing could then simply inject the Brave service instead
of taking care of the Brave setup directly.

Christian


2016-12-07 15:50 GMT+01:00 Andrey Redko <drr...@gmail.com>:

> I think it is very good idea to integrate brave-cxf into CXF. Christian, do
> you have enough time to work on that? I think I could help you out with
> that, I have reviewed brave-cxf PRs awhile back. Thanks.
>
> On Wed, Dec 7, 2016 at 5:00 AM, Christian Schneider <
> ch...@die-schneider.net
> > wrote:
>
> > I just talked to Adrian Cole. He prefers to have the brave cxf
> integration
> > in cxf instead of brave. So we can go ahead and improve the module in cxf
> > and he will deprecate the
> > brave-cxf module in brave once ours is good enough to cover all cases.
> >
> > Christian
> >
> > On 07.12.2016 11:46, Sergey Beryozkin wrote:
> >
> >> Hi Christian
> >>
> >> May be you can contribute your CXF Brave Feature code to the Brave CXF 3
> >> module (the docs show the interceptors are registered directly) ?
> Otherwise
> >> Brave and CXF own Brave interceptors will start competing for who has
> the
> >> latest code :-)
> >>
> >> CXF HTrace is quite advanced thanks to the work Andriy did. But I
> believe
> >> your reservation about it was that HTrace was not working well in OSGI.
> >>
> >> But if CXF RS/WS services are running in Spring Boot or other non-OSGI
> >> containers then what we have with HTrace is good. We'd like to consider
> >> enhancing it a bit:
> >>
> >> https://issues.apache.org/jira/browse/CXF-7129
> >>
> >> so that the hTrac-ing can be optionally implicit.
> >>
> >> Cheers, Sergey
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave

2016-12-07 Thread Christian Schneider

I just talked to Adrian Cole. He prefers to have the brave cxf 
integration in cxf instead of brave. So we can go ahead and improve the 
module in cxf and he will deprecate the

brave-cxf module in brave once ours is good enough to cover all cases.

Christian

On 07.12.2016 11:46, Sergey Beryozkin wrote:

Hi Christian

May be you can contribute your CXF Brave Feature code to the Brave CXF 
3 module (the docs show the interceptors are registered directly) ? 
Otherwise Brave and CXF own Brave interceptors will start competing 
for who has the latest code :-)


CXF HTrace is quite advanced thanks to the work Andriy did. But I 
believe your reservation about it was that HTrace was not working well 
in OSGI.


But if CXF RS/WS services are running in Spring Boot or other non-OSGI 
containers then what we have with HTrace is good. We'd like to 
consider enhancing it a bit:


https://issues.apache.org/jira/browse/CXF-7129

so that the hTrac-ing can be optionally implicit.

Cheers, Sergey 


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave

2016-12-06 Thread Christian Schneider

Damn ... I just found there is also general CXF support for brave at
https://github.com/openzipkin/brave/tree/master/brave-cxf3 . So maybe this
already solved the problem before.
We should decide how to proceed.

I think one approach is to help at brave-cxf3 to make it as good as
possible and revert the cxf module I created.
The other is to focus on the cxf trace zipkin module .. Actually I am not
sure what is the better option.

Any opinions?

Christian

2016-12-06 20:49 GMT+01:00 Andrey Redko <drr...@gmail.com>:

> That's right, the JAX-RS part should be supported by Brave already thanks
> to dedicated CXF integration (I was involved in late-stage discussions for
> the PR in question but not in the implementation).
>
> Best Regards,
> Andriy Redko
>
> On Tue, Dec 6, 2016 at 12:09 PM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
> > My orignal plan was to just support SOAP as REST is well supported by
> brave
> > rest support already.
> > In the end my code was able to support both REST and SOAP without much
> > overhead so I removed the soap package again.
> >
> > Christian
> >
> > 2016-12-06 14:41 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:
> >
> > > Christian, what is SOAP specific in this code ?
> > > Looks like that can work with JAX-RS too ?
> > >
> > > Usually we try to accommodate both frontends, example, Andriy Redko
> made
> > > sure HTrace interceptors work for JAXWS, similarly for Bean validation
> > >
> > > Sergey
> > >
> > >
> > >
> > > On 06/12/16 13:36, cschnei...@apache.org wrote:
> > >
> > >> Repository: cxf
> > >> Updated Branches:
> > >>   refs/heads/master 892a4ca84 -> fd77d3f33
> > >>
> > >>
> > >> [CXF-7164] Support tracing using Zipkin Brave
> > >>
> > >>
> > >> Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
> > >> Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/fd77d3f3
> > >> Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/fd77d3f3
> > >> Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/fd77d3f3
> > >>
> > >> Branch: refs/heads/master
> > >> Commit: fd77d3f3380f805db3547d37cbb2ff72bd033ad0
> > >> Parents: 892a4ca
> > >> Author: Christian Schneider <ch...@die-schneider.net>
> > >> Authored: Tue Dec 6 14:35:35 2016 +0100
> > >> Committer: Christian Schneider <ch...@die-schneider.net>
> > >> Committed: Tue Dec 6 14:36:01 2016 +0100
> > >>
> > >> 
> --
> > >>  rt/features/pom.xml |   1 +
> > >>  rt/features/tracing-brave/pom.xml   |  87 +
> > >>  .../brave/soap/CxfHttpClientRequest.java|  49 
> > >>  .../tracing/brave/soap/CxfServerRequest.java|  48 
> > >>  .../cxf/tracing/brave/soap/HttpResponse200.java |  28 +
> > >>  .../cxf/tracing/brave/soap/ParsedMessage.java   | 121
> > >> +++
> > >>  .../cxf/tracing/brave/soap/TraceFeature.java|  50 
> > >>  .../tracing/brave/soap/TraceInInterceptor.java  |  58 +
> > >>  .../tracing/brave/soap/TraceOutInterceptor.java |  57 +
> > >>  .../cxf/tracing/brave/soap/BraveTraceTest.java  |  99
> +++
> > >>  .../brave/soap/LoggingSpanNameProvider.java |  31 +
> > >>  .../cxf/tracing/brave/soap/MyService.java   |  26 
> > >>  .../cxf/tracing/brave/soap/MyServiceImpl.java   |  28 +
> > >>  13 files changed, 683 insertions(+)
> > >> 
> --
> > >>
> > >>
> > >> http://git-wip-us.apache.org/repos/asf/cxf/blob/fd77d3f3/rt/
> > >> features/pom.xml
> > >> 
> --
> > >> diff --git a/rt/features/pom.xml b/rt/features/pom.xml
> > >> index 0365bf6..a4cfdff 100644
> > >> --- a/rt/features/pom.xml
> > >> +++ b/rt/features/pom.xml
> > >> @@ -34,5 +34,6 @@
> > >>  logging
> > >>  metrics
> > >>  throttling
> > >> +tracing-brave
> > >>  
> > >>  
> > >>
> > >> http://git-wip-us.apache.org/repos/asf/cxf/blo

Re: cxf git commit: [CXF-7164] Support tracing using Zipkin Brave

2016-12-06 Thread Christian Schneider

My orignal plan was to just support SOAP as REST is well supported by brave
rest support already.
In the end my code was able to support both REST and SOAP without much
overhead so I removed the soap package again.

Christian

2016-12-06 14:41 GMT+01:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Christian, what is SOAP specific in this code ?
> Looks like that can work with JAX-RS too ?
>
> Usually we try to accommodate both frontends, example, Andriy Redko made
> sure HTrace interceptors work for JAXWS, similarly for Bean validation
>
> Sergey
>
>
>
> On 06/12/16 13:36, cschnei...@apache.org wrote:
>
>> Repository: cxf
>> Updated Branches:
>>   refs/heads/master 892a4ca84 -> fd77d3f33
>>
>>
>> [CXF-7164] Support tracing using Zipkin Brave
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/cxf/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/cxf/commit/fd77d3f3
>> Tree: http://git-wip-us.apache.org/repos/asf/cxf/tree/fd77d3f3
>> Diff: http://git-wip-us.apache.org/repos/asf/cxf/diff/fd77d3f3
>>
>> Branch: refs/heads/master
>> Commit: fd77d3f3380f805db3547d37cbb2ff72bd033ad0
>> Parents: 892a4ca
>> Author: Christian Schneider <ch...@die-schneider.net>
>> Authored: Tue Dec 6 14:35:35 2016 +0100
>> Committer: Christian Schneider <ch...@die-schneider.net>
>> Committed: Tue Dec 6 14:36:01 2016 +0100
>>
>> --
>>  rt/features/pom.xml |   1 +
>>  rt/features/tracing-brave/pom.xml   |  87 +
>>  .../brave/soap/CxfHttpClientRequest.java|  49 
>>  .../tracing/brave/soap/CxfServerRequest.java|  48 
>>  .../cxf/tracing/brave/soap/HttpResponse200.java |  28 +
>>  .../cxf/tracing/brave/soap/ParsedMessage.java   | 121
>> +++
>>  .../cxf/tracing/brave/soap/TraceFeature.java|  50 
>>  .../tracing/brave/soap/TraceInInterceptor.java  |  58 +
>>  .../tracing/brave/soap/TraceOutInterceptor.java |  57 +
>>  .../cxf/tracing/brave/soap/BraveTraceTest.java  |  99 +++
>>  .../brave/soap/LoggingSpanNameProvider.java |  31 +
>>  .../cxf/tracing/brave/soap/MyService.java   |  26 
>>  .../cxf/tracing/brave/soap/MyServiceImpl.java   |  28 +
>>  13 files changed, 683 insertions(+)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/cxf/blob/fd77d3f3/rt/
>> features/pom.xml
>> --
>> diff --git a/rt/features/pom.xml b/rt/features/pom.xml
>> index 0365bf6..a4cfdff 100644
>> --- a/rt/features/pom.xml
>> +++ b/rt/features/pom.xml
>> @@ -34,5 +34,6 @@
>>  logging
>>  metrics
>>  throttling
>> +tracing-brave
>>  
>>  
>>
>> http://git-wip-us.apache.org/repos/asf/cxf/blob/fd77d3f3/rt/
>> features/tracing-brave/pom.xml
>> --
>> diff --git a/rt/features/tracing-brave/pom.xml
>> b/rt/features/tracing-brave/pom.xml
>> new file mode 100644
>> index 000..9af22e4
>> --- /dev/null
>> +++ b/rt/features/tracing-brave/pom.xml
>> @@ -0,0 +1,87 @@
>> +
>> +
>> +http://maven.apache.org/POM/4.0.0; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://mav
>> en.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;>
>> +4.0.0
>> +cxf-rt-features-tracing-brave
>> +jar
>> +Apache CXF Tracing using Zipkin Brave
>> +http://cxf.apache.org
>> +
>> +org.apache.cxf
>> +cxf-parent
>> +3.2.0-SNAPSHOT
>> +../../../parent/pom.xml
>> +
>> +
>> +
>> +
>> +org.apache.cxf.tracing.brave.soap
>> +
>> +3.15.1
>> +
>> +
>> +
>> +
>> +junit
>> +junit
>> +test
>> +
>> +
>> +org.apache.cxf
>> +cxf-core
>> +${project.version}
>> +
>> +
>> +
>> +org.apache.cxf
>> +cxf-rt-features-logging
>> +${project.version}
>> +
>> +
>> +   io.zipkin.brave
>> +   brave-core
>>

Re: [ANNOUNCE] Introducing Microbule...

2016-11-23 Thread Christian Schneider


One thing about the implementation.
I noticed that microbule is using blueprint for its own setup.
I would switch this rather to DS as it has a smaller footprint.

If someone is using microbule with DS then the blueprint overhead is 
substantial.
If someone would use a DS based microbule with blueprint then the DS 
overhead would be a lot smaller.


Christian

On 21.11.2016 19:03, James Carman wrote:

We've been working on a Microservices framework called "Microbule" which
leverages CXF and Karaf (hence the cross-post):

https://github.com/jwcarman/microbule

The idea is to make writing Microservices easy and fun, by providing many
of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
transformation, validation, etc.).  There's a README page that explains how
to install/run Microbule in Karaf and how to write your own services.  If
you're interested, take it for a spin and let us know what you think.

Thanks,

James




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [ANNOUNCE] Introducing Microbule...

2016-11-23 Thread Christian Schneider

I really like the microbule project scope. We really need a project that 
can bring mircoservice development on CXF and OSGi to the same level as 
spring boot.
I am only concerned that many different projects seem to cover parts of 
this at the moment. So if we are not careful we again will have too many 
separate efforts inside the already small OSGi space.


Some things you might want to look into:

In the CXF-DOSGi samples I have bndrun that shows how to package cxf and 
the felix http service.

https://github.com/apache/cxf-dosgi/blob/master/samples/soap/soap.bndrun
I used the /myservice addresses and it works quite well. Felix http 
service is a a lot simpler to deploy than pax web. As CXF-DOSGi just 
uses the HttpService it is easy to use pax-web when deployed in karaf 
and felix http service for microservice like deployments.


Another project to look into is the Aries JAX-RS-whiteboard. It is 
implementing the JAX-RS Whiteboard OSGi spec in Aries. Your project 
should have a big overlap with CXF-DOSGi and JAX-RS-whiteboard. I wonder 
if we could combine these efforts. One possible solution would be to 
concentrate the efforts of exporting REST services in JAX-RS whiteboard. 
Then your framework could concentrate on the remaining aspects of 
microservices like circuit breaker, discovery and packaging. The Aries 
JAX-RS whiteboard project is currently in a very early stage. So I think 
this should provide a great opportunity to get your ideas into the project.


Another interesting part of JAX-RS whiteboard is that it can provide 
OSGi enabled JAX-RS ClientBuilder instances. So that could be used to 
create clients without depending on CXF in the user code.


CXF-DOSGi on the other hand can provide fully transparent type safe 
clients as OSGi services which could also provide some value.


I am also working on getting zipkin and brave tracing working inside 
OSGi. See https://github.com/cschneider/brave-osgi-example
Brave already offers JAX-RS interceptors for logging and I added a PR to 
offer a jax-rs Feature. That will make it really easy to add tracing to 
CXF and any other JAX-RS 2 impl.


Before that I was not aware that JAX-RS has such a nice portable Feature 
interface. So I think a lot of the microservice features like circuit 
breaker could be created in a portable way. This would give the user the 
free choice of the JAX-RS impl.


I also had pretty good experiences using bndtools to create the 
packaging into a runnable jar. The result is a lot smaller than karaf 
(~9mb for a full REST example) and matches the docker concepts better.


Sorry for this highly uncohesive list but I just wanted to give you some 
ideas to pursue :-)


Christian



On 22.11.2016 21:55, Benson Margulies wrote:

A small update with some irony here.

At the job I just finished today, we reached the conclusion that we
weren't getting much value out of Karaf and pax-web; no criticism
intended, we just don't dynamically provision, and we don't need any
HTTP except for CXF services. So, over the last few weeks, we
refactored the thing to use cxf-rt-transport-http-jetty in the Felix
container, with our own rather tiny class responsible for launching.
We lost a bit of flexibility in that we can't create an endpoint
'inside' of the namespace of another endpoint, but otherwise it works
just fine. The code that that I showed James is hardly changed at all.
The endpoint addresses now look like
"http://0.0.0.0:n/base/whatever; instead "/whatever".  Maybe some
day there will be an ultramicrobule that anticipates this mode of
operation.





On Mon, Nov 21, 2016 at 7:13 PM, James Carman
<ja...@carmanconsulting.com> wrote:

Small update.  Microbule 0.1.0 release has been cut and will soon be
available in Maven Central (awaiting sync from Nexus OSS).  Enjoy, folks!

On Mon, Nov 21, 2016 at 1:03 PM James Carman <ja...@carmanconsulting.com>
wrote:


We've been working on a Microservices framework called "Microbule" which
leverages CXF and Karaf (hence the cross-post):

https://github.com/jwcarman/microbule

The idea is to make writing Microservices easy and fun, by providing many
of the oft-requested features for you out-of-the-box (CORS, Caching, JSON
transformation, validation, etc.).  There's a README page that explains how
to install/run Microbule in Karaf and how to write your own services.  If
you're interested, take it for a spin and let us know what you think.

Thanks,

James




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] CXF 3.0.11/3.1.8

2016-10-17 Thread Christian Schneider


+1

Christian

On 14.10.2016 20:59, Daniel Kulp wrote:

This is a vote to release 3.0.11/3.1.8.   We’ve resolved over 55 issues for 
3.1.8.

Staging areas:
3.1.8:
https://repository.apache.org/content/repositories/orgapachecxf-1081/
3.0.11:
https://repository.apache.org/content/repositories/orgapachecxf-1080/


Tags:
3.1.8:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=80473c6a929cd797d5b0b0134f31818a716011e8
3.0.11:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=209f5f9d04b2b49e05c4894034a719eea40bd0e4

Here is my +1





--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Move spring and blueprint support out of cxf-core


On 30.09.2016 17:56, Guillaume Nodet wrote:

2016-09-30 16:28 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:


I hope we can get DOSGi on the same level as CXF + blueprint. Basically we
just need to make sure we provide a programmatic way to configure all
aspects of CXF (e.g. using Features). The big advantage is that this will
bring first class CXF support to all other platforms too.

So my first goal is to get the most important CXF features configureable. I
think with CXF DOSGi 2 we should already cover the need of most users.
Maybe not yet as convenient as possible but at least possible.


Having a programmatic way to configure CXF is not really specific to DOSGi,
is it ?
Exactly. This is why I want to make sure we support it. It will help 
other platforms too

and also help people who want to provide specific tooling for a platform.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Move spring and blueprint support out of cxf-core

I hope we can get DOSGi on the same level as CXF + blueprint. Basically we
just need to make sure we provide a programmatic way to configure all
aspects of CXF (e.g. using Features). The big advantage is that this will
bring first class CXF support to all other platforms too.

So my first goal is to get the most important CXF features configureable. I
think with CXF DOSGi 2 we should already cover the need of most users.
Maybe not yet as convenient as possible but at least possible.

Christian


2016-09-30 14:51 GMT+02:00 Sergey Beryozkin <sberyoz...@gmail.com>:

> Christian, I'll be happy to see DOSGI getting more attention but this
> 'simply use DOSGI' will simply not work - the flexibility of Blueprint (and
> Spring in or outside of OSGI) is rated highly by the CXF users.
> DOSGI has its niche but it has its limitations too.
>
> Cheers, Sergey
>
>
>
>
> On 30/09/16 12:59, Christian Schneider wrote:
>
>> Hi Benson,
>>
>> DS and CXF already work quite well. Simply use CXF-DOSGi to expose and use
>> services.
>> The new samples in version 2.0 all use DS.
>>
>> https://github.com/apache/cxf-dosgi/tree/master/samples
>>
>> Honestly I think the blueprint / spring namespaces never were such a good
>> idea. They are much too intrusive.
>> I plan to point people to using DOSGi as the default way of using CXF in
>> OSGi.
>>
>> Christian
>>
>>
>>
>> 2016-09-29 17:07 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:
>>
>> There's more to OSGi than Blueprint. I'd be very happy to use CXF with
>>> DS and no blueprint.
>>>
>>> On Thu, Sep 29, 2016 at 8:13 AM, Andrei Shakirin <ashaki...@talend.com>
>>> wrote:
>>>
>>>> Just more detail description:
>>>>
>>>> After removing the optional spring imports packages from CXF jars
>>>>
>>> Manifests, the users still can use CXF with Spring in Web, JEE and
>>> standalone deployments, but not in OSGi with SpringDM.
>>>
>>>>
>>>> Removing can be done for example with maven bundle plugin instruction:
>>>> 
>>>>   org.apache.felix
>>>>   maven-bundle-plugin
>>>>   true
>>>>   
>>>>
>>>>
>>>> !org.springframework*,
>>>>  *
>>>> 
>>>> 
>>>>   
>>>> 
>>>>
>>>> CXF reloading issue should be fixed with that.
>>>>
>>>> However the OSGi users using CXF in OSGi with SpringDM wouldn't be
>>>>
>>> supported anymore.
>>>
>>>>
>>>> WDYT?
>>>>
>>>> Regards,
>>>> Andrei.
>>>>
>>>> -Original Message-
>>>>> From: Andrei Shakirin [mailto:ashaki...@talend.com]
>>>>> Sent: Freitag, 23. September 2016 18:09
>>>>> To: dev@cxf.apache.org
>>>>> Subject: RE: [Discuss] Move spring and blueprint support out of
>>>>> cxf-core
>>>>>
>>>>> Hi Christian,
>>>>>
>>>>> Regarding Karaf4 and OSGi: as Guillaume says the Spring DM isn't
>>>>>
>>>> supported
>>>
>>>> anymore.
>>>>> I am not sure how many users still use CXF + Spring in OSGi.
>>>>> Do you think it will be an option just to remove optional spring
>>>>>
>>>> imports from
>>>
>>>> the Manifest (for example using maven bundle plugin)?
>>>>>
>>>>> Regards,
>>>>> Andrei.
>>>>>
>>>>> -Original Message-
>>>>>> From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf
>>>>>> Of Christian Schneider
>>>>>> Sent: Freitag, 23. September 2016 17:29
>>>>>> To: dev@cxf.apache.org
>>>>>> Subject: Re: [Discuss] Move spring and blueprint support out of
>>>>>> cxf-core
>>>>>>
>>>>>> Hmm .. the dynamic imports would be worth a try. The namespaces might
>>>>>> work this way.
>>>>>> The focus is indeed mainly on spring though as blueprint is pre
>>>>>> installed most times and is only present in one version.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 23.09.2016 16:38, Guillaume Nodet wrote:
>>>>>>
>>>>>>> I think w

Re: [Discuss] Move spring and blueprint support out of cxf-core

I am still hoping for better CDI support in OSGi. So that would be really
cool.

On the other hand I think DS can do the job in most cases. With CXF-DOSGi
for services and JPATemplate or tx-control for db access DS is already
quite usable in the enterprise space.

I just did an OSGi training at a customer. We chose blueprint with the
blueprint-maven-plugin as the customer already knows it but all the code we
did would have worked with DS too.

Christian

2016-09-29 17:10 GMT+02:00 Guillaume Nodet <gno...@apache.org>:

> But DS provides no extension point and can't really be used to do pure
> dependency injection.
> I'd think CDI might be a better goal if we want to support a new framework.
>
> Guillaume
>
> 2016-09-29 17:07 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:
>
> > There's more to OSGi than Blueprint. I'd be very happy to use CXF with
> > DS and no blueprint.
> >
> > On Thu, Sep 29, 2016 at 8:13 AM, Andrei Shakirin <ashaki...@talend.com>
> > wrote:
> > > Just more detail description:
> > >
> > > After removing the optional spring imports packages from CXF jars
> > Manifests, the users still can use CXF with Spring in Web, JEE and
> > standalone deployments, but not in OSGi with SpringDM.
> > >
> > > Removing can be done for example with maven bundle plugin instruction:
> > > 
> > >   org.apache.felix
> > >   maven-bundle-plugin
> > >   true
> > >   
> > >
> > >
> > > !org.springframework*,
> > >  *
> > > 
> > > 
> > >   
> > > 
> > >
> > > CXF reloading issue should be fixed with that.
> > >
> > > However the OSGi users using CXF in OSGi with SpringDM wouldn't be
> > supported anymore.
> > >
> > > WDYT?
> > >
> > > Regards,
> > > Andrei.
> > >
> > >> -Original Message-
> > >> From: Andrei Shakirin [mailto:ashaki...@talend.com]
> > >> Sent: Freitag, 23. September 2016 18:09
> > >> To: dev@cxf.apache.org
> > >> Subject: RE: [Discuss] Move spring and blueprint support out of
> cxf-core
> > >>
> > >> Hi Christian,
> > >>
> > >> Regarding Karaf4 and OSGi: as Guillaume says the Spring DM isn't
> > supported
> > >> anymore.
> > >> I am not sure how many users still use CXF + Spring in OSGi.
> > >> Do you think it will be an option just to remove optional spring
> > imports from
> > >> the Manifest (for example using maven bundle plugin)?
> > >>
> > >> Regards,
> > >> Andrei.
> > >>
> > >> > -Original Message-
> > >> > From: Christian Schneider [mailto:cschneider...@gmail.com] On
> Behalf
> > >> > Of Christian Schneider
> > >> > Sent: Freitag, 23. September 2016 17:29
> > >> > To: dev@cxf.apache.org
> > >> > Subject: Re: [Discuss] Move spring and blueprint support out of
> > >> > cxf-core
> > >> >
> > >> > Hmm .. the dynamic imports would be worth a try. The namespaces
> might
> > >> > work this way.
> > >> > The focus is indeed mainly on spring though as blueprint is pre
> > >> > installed most times and is only present in one version.
> > >> >
> > >> > Christian
> > >> >
> > >> > On 23.09.2016 16:38, Guillaume Nodet wrote:
> > >> > > I think we can solve the refresh problem from blueprint :
> > >> > >* remove the bundle activators that registers the blueprint
> > handlers
> > >> > >* create an extender which will scan for the blueprint.handlers
> > >> > > files in bundles and register the namespaces
> > >> > >* replace the cxf bundles Import-Package
> > >> > > org.apache.aries.blueprint.* and
> > >> > > org.osgi.service.blueprint.* packages with
> DynamicImport-Package(s)
> > >> > > I think this way, we should be able to deploy cxf-jaxws, then
> deploy
> > >> > > blueprint, and have blueprint namespaces available without having
> > >> > > any cxf bundle refreshed.
> > >> > >
> > >> > > For spring, I'm not sure we can do the same.  Though spring-dm is
> > >> > > not supported anymore, so I think at some point, we can safely not
> > >> > > support it

Re: [Discuss] Move spring and blueprint support out of cxf-core

Hi Benson,

DS and CXF already work quite well. Simply use CXF-DOSGi to expose and use
services.
The new samples in version 2.0 all use DS.

https://github.com/apache/cxf-dosgi/tree/master/samples

Honestly I think the blueprint / spring namespaces never were such a good
idea. They are much too intrusive.
I plan to point people to using DOSGi as the default way of using CXF in
OSGi.

Christian



2016-09-29 17:07 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:

> There's more to OSGi than Blueprint. I'd be very happy to use CXF with
> DS and no blueprint.
>
> On Thu, Sep 29, 2016 at 8:13 AM, Andrei Shakirin <ashaki...@talend.com>
> wrote:
> > Just more detail description:
> >
> > After removing the optional spring imports packages from CXF jars
> Manifests, the users still can use CXF with Spring in Web, JEE and
> standalone deployments, but not in OSGi with SpringDM.
> >
> > Removing can be done for example with maven bundle plugin instruction:
> > 
> >   org.apache.felix
> >   maven-bundle-plugin
> >   true
> >   
> >
> >
> > !org.springframework*,
> >  *
> > 
> > 
> >   
> > 
> >
> > CXF reloading issue should be fixed with that.
> >
> > However the OSGi users using CXF in OSGi with SpringDM wouldn't be
> supported anymore.
> >
> > WDYT?
> >
> > Regards,
> > Andrei.
> >
> >> -Original Message-
> >> From: Andrei Shakirin [mailto:ashaki...@talend.com]
> >> Sent: Freitag, 23. September 2016 18:09
> >> To: dev@cxf.apache.org
> >> Subject: RE: [Discuss] Move spring and blueprint support out of cxf-core
> >>
> >> Hi Christian,
> >>
> >> Regarding Karaf4 and OSGi: as Guillaume says the Spring DM isn't
> supported
> >> anymore.
> >> I am not sure how many users still use CXF + Spring in OSGi.
> >> Do you think it will be an option just to remove optional spring
> imports from
> >> the Manifest (for example using maven bundle plugin)?
> >>
> >> Regards,
> >> Andrei.
> >>
> >> > -Original Message-
> >> > From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf
> >> > Of Christian Schneider
> >> > Sent: Freitag, 23. September 2016 17:29
> >> > To: dev@cxf.apache.org
> >> > Subject: Re: [Discuss] Move spring and blueprint support out of
> >> > cxf-core
> >> >
> >> > Hmm .. the dynamic imports would be worth a try. The namespaces might
> >> > work this way.
> >> > The focus is indeed mainly on spring though as blueprint is pre
> >> > installed most times and is only present in one version.
> >> >
> >> > Christian
> >> >
> >> > On 23.09.2016 16:38, Guillaume Nodet wrote:
> >> > > I think we can solve the refresh problem from blueprint :
> >> > >* remove the bundle activators that registers the blueprint
> handlers
> >> > >* create an extender which will scan for the blueprint.handlers
> >> > > files in bundles and register the namespaces
> >> > >* replace the cxf bundles Import-Package
> >> > > org.apache.aries.blueprint.* and
> >> > > org.osgi.service.blueprint.* packages with DynamicImport-Package(s)
> >> > > I think this way, we should be able to deploy cxf-jaxws, then deploy
> >> > > blueprint, and have blueprint namespaces available without having
> >> > > any cxf bundle refreshed.
> >> > >
> >> > > For spring, I'm not sure we can do the same.  Though spring-dm is
> >> > > not supported anymore, so I think at some point, we can safely not
> >> > > support it anymore.  It could be replaced by the spring-dm
> >> > > compatible support from aries blueprint, in which case, we have a
> bit more
> >> room to hack there.
> >> > > But even with plain spring-dm, the same idea as above should work,
> >> > > as both spring-dm and the spring support in aries-blueprint do use
> >> > > an extender and scan for META-INF/spring.handlers.
> >> > >
> >> > >
> >> > >
> >> > > 2016-09-23 16:11 GMT+02:00 Christian Schneider <chris@die-
> >> schneider.net>:
> >> > >
> >> > >> I agree. I would not make sense to have that many additional jars.
> >> > >> On the other hand we cou

Re: [Discuss] Move spring and blueprint support out of cxf-core

Hmm .. the dynamic imports would be worth a try. The namespaces might 
work this way.
The focus is indeed mainly on spring though as blueprint is pre 
installed most times and is only present in one version.


Christian

On 23.09.2016 16:38, Guillaume Nodet wrote:

I think we can solve the refresh problem from blueprint :
   * remove the bundle activators that registers the blueprint handlers
   * create an extender which will scan for the blueprint.handlers files in
bundles and register the namespaces
   * replace the cxf bundles Import-Package org.apache.aries.blueprint.* and
org.osgi.service.blueprint.* packages with DynamicImport-Package(s)
I think this way, we should be able to deploy cxf-jaxws, then deploy
blueprint, and have blueprint namespaces available without having any cxf
bundle refreshed.

For spring, I'm not sure we can do the same.  Though spring-dm is not
supported anymore, so I think at some point, we can safely not support it
anymore.  It could be replaced by the spring-dm compatible support from
aries blueprint, in which case, we have a bit more room to hack there.
But even with plain spring-dm, the same idea as above should work, as both
spring-dm and the spring support in aries-blueprint do use an extender and
scan for META-INF/spring.handlers.



2016-09-23 16:11 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:


I agree. I would not make sense to have that many additional jars.  On the
other hand we could only create the extra modules for the most important
bundles like jaxrs, jaxws, http and http jetty. These are the ones that
people use a lot and that would cause most of the refreshs.

Honestly I think we have too many special namespaces anyway.  So at the
start I would concentrate on the pain points above.

Another approach might be to have some generic support for namespaces.
After all the namespaces represent configuration. We could define the
configuration in a neutral form (like pojos) and create the xsds as well as
the spring or blueprint namespace handler registration centrally. Then
there could be one module that collects and registers the spring namespaces
and another for the blueprint ones. These modules would then also parse the
user xml and return the common pojos. The approach might be a bit difficult
to code but would save a lot of code in the individual modules. So this is
not something I would start with but it could be a mid term goal.

Christian


On 23.09.2016 15:38, Daniel Kulp wrote:


My biggest concern would be the “jar explosion” that would occur if you
add a -blueprint and -spring jar for each of the jars that contains those.
  We already have a ton of jars, not sure adding another 30-40 is the best
idea.

Several years ago, I also started experimenting a bit:
https://github.com/apache/cxf/tree/split-spring <
https://github.com/apache/cxf/tree/split-spring>

But didn’t really pursue it much further.




On Sep 23, 2016, at 8:31 AM, Christian Schneider <ch...@die-schneider.net>

wrote:

On 23.09.2016 14:03, Sergey Beryozkin wrote:


IMHO the most important thing is to preserve the CXF stability.

FYI, CommomUtil helpers which can use Spring are heavily used - some of
them in JAX-WS and a lot in JAX-RS.

For example, JAX-RS SpringBoot starter does depend a lot on the
ClassScanner Spring, and JAX-RS runtime depends in various places on
ClassHelper to help with dealing with Spring proxified beans. The code
which refers to these helpers can not afford to start referring to Spring
variants because of course not all CXF users are Spring users.

One needs to be aware that Spring (and now SpringBoot) is very much a
major platform for many CXF users.


We should definitely keep the good support for spring that we currently
have. What I am not sure of is if we still need the pretty extensive xml
namespaces in the future. The modern spring platform is now almost
completely annotation based. So I can imagine that cxf 4 might drop xml
namespaces in favor of comprehensive annotation based spring support.


Personally I'd like see a very clear and concrete plan first:
- How to preserve the runtime code portability which depends on
CommonUtil helpers such that it works as before in/out of Spring


I am not yet at the stage where I have a concrete plan. My first attempt
was just to find out how deeply spring is wired into CXF. As it seems the
unwrapping of proxies seems to be the most problematic part. So one first
task is to find a good way to make this still work while having a separate
module for the spring support.


- How to keep CXF Spring user code which depends on Spring Namespace
support (starting from cxf:bus and then for all other modules) operating.


As a first step I would simply add the new cxf-core-spring jar to all
modules that define namespaces. That might then not provide the full
advantage of the separation but it should guarantee that all modules work
as before. This change should make sure that refreshs only happen to
mo

Re: [Discuss] Move spring and blueprint support out of cxf-core

I agree. I would not make sense to have that many additional jars.  On 
the other hand we could only create the extra modules for the most 
important bundles like jaxrs, jaxws, http and http jetty. These are the 
ones that people use a lot and that would cause most of the refreshs.


Honestly I think we have too many special namespaces anyway.  So at the 
start I would concentrate on the pain points above.


Another approach might be to have some generic support for namespaces. 
After all the namespaces represent configuration. We could define the 
configuration in a neutral form (like pojos) and create the xsds as well 
as the spring or blueprint namespace handler registration centrally. 
Then there could be one module that collects and registers the spring 
namespaces and another for the blueprint ones. These modules would then 
also parse the user xml and return the common pojos. The approach might 
be a bit difficult to code but would save a lot of code in the 
individual modules. So this is not something I would start with but it 
could be a mid term goal.


Christian

On 23.09.2016 15:38, Daniel Kulp wrote:

My biggest concern would be the “jar explosion” that would occur if you add a 
-blueprint and -spring jar for each of the jars that contains those.   We 
already have a ton of jars, not sure adding another 30-40 is the best idea.

Several years ago, I also started experimenting a bit:
https://github.com/apache/cxf/tree/split-spring 
<https://github.com/apache/cxf/tree/split-spring>

But didn’t really pursue it much further.





On Sep 23, 2016, at 8:31 AM, Christian Schneider <ch...@die-schneider.net> 
wrote:

On 23.09.2016 14:03, Sergey Beryozkin wrote:

IMHO the most important thing is to preserve the CXF stability.

FYI, CommomUtil helpers which can use Spring are heavily used - some of them in 
JAX-WS and a lot in JAX-RS.

For example, JAX-RS SpringBoot starter does depend a lot on the ClassScanner 
Spring, and JAX-RS runtime depends in various places on ClassHelper to help 
with dealing with Spring proxified beans. The code which refers to these 
helpers can not afford to start referring to Spring variants because of course 
not all CXF users are Spring users.

One needs to be aware that Spring (and now SpringBoot) is very much a major 
platform for many CXF users.

We should definitely keep the good support for spring that we currently have. 
What I am not sure of is if we still need the pretty extensive xml namespaces 
in the future. The modern spring platform is now almost completely annotation 
based. So I can imagine that cxf 4 might drop xml namespaces in favor of 
comprehensive annotation based spring support.

Personally I'd like see a very clear and concrete plan first:
- How to preserve the runtime code portability which depends on CommonUtil 
helpers such that it works as before in/out of Spring

I am not yet at the stage where I have a concrete plan. My first attempt was 
just to find out how deeply spring is wired into CXF. As it seems the 
unwrapping of proxies seems to be the most problematic part. So one first task 
is to find a good way to make this still work while having a separate module 
for the spring support.

- How to keep CXF Spring user code which depends on Spring Namespace support 
(starting from cxf:bus and then for all other modules) operating.

As a first step I would simply add the new cxf-core-spring jar to all modules 
that define namespaces. That might then not provide the full advantage of the 
separation but it should guarantee that all modules work as before. This change 
should make sure that refreshs only happen to modules that provide namespaces.
As a second step we should then check if we can improve on that. This all of 
course depends if we find a feasible solution and if the changes have the 
desired effect.
In any case I will make sure that we keep all problematic changes in a branch 
so we can decide about them before they reach the master.

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: TomEE CDI and CXF CDI

I also think is would be great to have the CDI support directly in cxf 
as a portable extension. It could then also be reused in pax-cdi for 
OSGi and also for standalone CDI cases.


Christian

On 23.09.2016 15:33, Sergey Beryozkin wrote:

Hi Romain

What do you think of trying to utilize CXF CDI code for the purpose of 
supporting CXF CDI services in TomEE ?


You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI 
code 'missed out' :-). We have some CDI experts here on the list so 
may be it can make sense...


Thanks, Sergey



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [Discuss] Move spring and blueprint support out of cxf-core


On 23.09.2016 14:03, Sergey Beryozkin wrote:

IMHO the most important thing is to preserve the CXF stability.

FYI, CommomUtil helpers which can use Spring are heavily used - some 
of them in JAX-WS and a lot in JAX-RS.


For example, JAX-RS SpringBoot starter does depend a lot on the 
ClassScanner Spring, and JAX-RS runtime depends in various places on 
ClassHelper to help with dealing with Spring proxified beans. The code 
which refers to these helpers can not afford to start referring to 
Spring variants because of course not all CXF users are Spring users.


One needs to be aware that Spring (and now SpringBoot) is very much a 
major platform for many CXF users.
We should definitely keep the good support for spring that we currently 
have. What I am not sure of is if we still need the pretty extensive xml 
namespaces in the future. The modern spring platform is now almost 
completely annotation based. So I can imagine that cxf 4 might drop xml 
namespaces in favor of comprehensive annotation based spring support.


Personally I'd like see a very clear and concrete plan first:
- How to preserve the runtime code portability which depends on 
CommonUtil helpers such that it works as before in/out of Spring
I am not yet at the stage where I have a concrete plan. My first attempt 
was just to find out how deeply spring is wired into CXF. As it seems 
the unwrapping of proxies seems to be the most problematic part. So one 
first task is to find a good way to make this still work while having a 
separate module for the spring support.
- How to keep CXF Spring user code which depends on Spring Namespace 
support (starting from cxf:bus and then for all other modules) operating.
As a first step I would simply add the new cxf-core-spring jar to all 
modules that define namespaces. That might then not provide the full 
advantage of the separation but it should guarantee that all modules 
work as before. This change should make sure that refreshs only happen 
to modules that provide namespaces.
As a second step we should then check if we can improve on that. This 
all of course depends if we find a feasible solution and if the changes 
have the desired effect.
In any case I will make sure that we keep all problematic changes in a 
branch so we can decide about them before they reach the master.


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[Discuss] Move spring and blueprint support out of cxf-core