Re: [VOTE] CXF 3.3.1
+1 Le jeu. 28 févr. 2019 à 19:56, Daniel Kulp a écrit : > This is vote to release 3.3.1. This doesn’t fix a ton of issues (only > 12), but it does fix two relatively important regressions. > > Staging area: > https://repository.apache.org/content/repositories/orgapachecxf-1136/ < > https://repository.apache.org/content/repositories/orgapachecxf-1136/> > > Tag: > > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=028131b027b3cfc56a18725bf6cd1f27e824a7e9 > < > https://gitbox.apache.org/repos/asf?p=cxf.git;a=tag;h=028131b027b3cfc56a18725bf6cd1f27e824a7e9 > > > > Here is my +1 > > > -- > Daniel Kulp > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog < > http://dankulp.com/blog> > Talend Community Coder - http://talend.com <http://coders.talend.com/> > -- Guillaume Nodet
Re: CXF 3.2 support jetty9 only (drop jetty8 support)
Btw, what's the ETA for CXF 3.2 ? 2016-12-22 14:30 GMT+01:00 Daniel Kulp <dk...@apache.org>: > > I’d be fine with that. Everyone has pretty much moved on from the Karaf > 2.x versions that only have Jetty8. As long as we can support the Jetty > version in Karaf 4.0.x, I’m fine. > > Dan > > > > On Dec 21, 2016, at 10:45 PM, Freeman Fang <freeman.f...@gmail.com> > wrote: > > > > Hi Team, > > > > We have several issues(like CXF-7160 and CXF-7179) recently which is > caused by Jetty9 & Jetty8 API imcompatible, though we should be able to > handle this by reflection on CXF 3.1.x, for the coming CXF 3.2 how about > we support Jetty9(drop Jetty8 support) only? This can relieve some burden > supporting both Jetty8 & Jetty9 in CXF http-jetty transport. > > > > A couple of more reasons CXF 3.2 should support Jetty 9 only > > 1. Jetty8 was EOL at end of 2014 and no further work on jetty 8 > > 2. benchmark showed Jetty9 is 30% faster than Jetty8 on server side due > to the big changes in IO layers > > 3. Jetty community strongly suggest to use Jetty9 > > 4. pax-web support Jetty9 for a long time, so align the jetty version > seems more reasonable. > > > > Any thoughts? > > > > Thanks! > > － > > Freeman(Yue) Fang > > > > Red Hat, Inc. > > FuseSource is now part of Red Hat > > > > > > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [Discuss] Move spring and blueprint support out of cxf-core
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 ? > > 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: Fre
Re: [Discuss] Move spring and blueprint support out of cxf-core
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 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 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 tha
Re: [Discuss] Move spring and blueprint support out of cxf-core
; 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 > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: Karaf 3?
It looks like nobody objects, so I'll go ahead and drop Karaf 3 support. 2016-09-20 22:48 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > Sounds good to me. > It would be obviously easier to maintain. > > 2016-09-20 15:06 GMT+02:00 Daniel Kulp <dk...@apache.org>: > >> Looking at Guillaume’s changes for CXF-7060, I have to wonder one thing: >> >> For 3.2, do we still need support for Karaf 3?Karaf 4 has been out >> for a while and I believe most folks have migrated. If we don’t need >> support for Karaf 3.x the changes Guillaume is doing can be simplified >> greatly and we can avoid all the duplication between the two features.xml >> files and such. >> >> >> Thoughts? >> >> -- >> Daniel Kulp >> dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog < >> http://dankulp.com/blog> >> Talend Community Coder - http://coders.talend.com < >> http://coders.talend.com/> >> > > > > -- > > Guillaume Nodet > ---- > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: Karaf 3?
Sounds good to me. It would be obviously easier to maintain. 2016-09-20 15:06 GMT+02:00 Daniel Kulp <dk...@apache.org>: > Looking at Guillaume’s changes for CXF-7060, I have to wonder one thing: > > For 3.2, do we still need support for Karaf 3?Karaf 4 has been out for > a while and I believe most folks have migrated. If we don’t need support > for Karaf 3.x the changes Guillaume is doing can be simplified greatly and > we can avoid all the duplication between the two features.xml files and > such. > > > Thoughts? > > -- > Daniel Kulp > dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog < > http://dankulp.com/blog> > Talend Community Coder - http://coders.talend.com < > http://coders.talend.com/> > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [1/2] cxf git commit: [CXF-7060] Provide a cxf-http-provider feature to be used when in need of a provider-agnostic http transport
Good catch, I pick the wrong one.
I think I need to move that capability to the web socket server transport
instead which actually provides a HttpDestinationFactory.
2016-09-20 15:25 GMT+02:00 Daniel Kulp <dk...@apache.org>:
>
> On Sep 20, 2016, at 9:07 AM, gno...@apache.org wrote:
>
>
> cxf-http
> @@ -166,6 +181,9 @@
> mvn:org.apache.httpcomponents/
> httpclient-osgi/${cxf.httpcomponents.client.version}
> mvn:org.apache.httpcomponents/
> httpasyncclient-osgi/${cxf.httpcomponents.asyncclient.version}
> mvn:org.apache.cxf/cxf-rt-transports-
> http-hc/${project.version}
> +
> +cxf.http.provider;name=async
> +
>
>
>
>
> The async is a client side only thing, not server side. The others seem
> to be selecting the server side. Is this setting needed here?
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [VOTE] CXF 3.1.1
I think we should do differently ;-) But this is not a blocking issue, so I'll try to propose something for 3.1.2. Ideally, I'd like to have a complete and verified feature descriptor for karaf 4.0.0 (the karaf maven plugin can now do an OSGi resolution to ensure the feature is complete). CXF also has some libraries requirements which should be expressed correctly in the feature file. I'm planning to add a goal to the karaf plugin to translate the new feature syntax into a feature descriptor supported by karaf 2 and 3. Anyway, here's my +1 2015-06-09 1:17 GMT+02:00 Andriy Redko drr...@gmail.com: Hi Aki, Thanks a lot for trying out cxf-jaxrs-cdi. It is true, it needs CDI dependency to be present in the OSGi container. There are few reasons behind that: - cxf-jaxrs-cdi does not manage version of CDI (1.0 / 1.1 / 1.2 / ...) - cxf-jaxrs-cdi does not manage CDI provider (Weld / OpenWebBeans / ...) - we totally rely on the CDI capabilities of the OSGi container The typical prerequisites for cxf-jaxrs-cdi are pax-cdi-1.2-web-weld or pax-cdi-1.1-web-weld, depending on the applications demands. Please let me know if it makes sense or we should do something differently. Thank you! Best Regards, Andriy Redko AY +1 AY but I noticed two minor issues that need to be fixed in the next 3.1.x version. AY Feature cxf-transports-websocket-server can't get installed out of the AY box because it was my fault in not noticing earlier that atmosphere AY 2.3.0 was requiring javax.enterprise.context. (CXF-3.1.0 was using AY atmosphere-2.2.6). I'll see if we can make atmosphere to have this AY dependency optional. As a temporary workaround, one has to install AY geronimo's cdi bundle. Alternatively, do not use this feature but AY install atmosphere-2.2.7 because CXF 3.1.1 itself works with AY atmosphere 2.2.x or 2.3.x. In any case, AY As another workaround, I thought one could just install feature cxf-jaxrs-cdi. AY But this feature seems to be missing the dependency to the required AY cdi bundle. So it doesn't get installed out of the box. But this AY seemed to be the case with CXF 3.1.0 as well. AY aki AY 2015-06-05 22:49 GMT+02:00 Daniel Kulp dk...@apache.org: 3.1.1 fixes a bunch of issues in 3.1.0 that would prevent it from working properly in several normal use cases, particularly in OSGi. Staging area: https://repository.apache.org/content/repositories/orgapachecxf-1044/ Tag: https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=f0d82d6f37105d1e2c97a459fb7fe41d98e1e401 Here is my +1. Vote will be open for 72 hours -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
CXF tools jars aren't OSGi bundles anymore in 3.x
In 2.x, cxf tooling jars were packaged as valid OSGi bundles. In 3.x, the maven packaging has been changed from jar to bundle for most of the bundles, but the tool ones remained jars. Unfortunately, the OSGi manifest is not generated anymore. I'm raising this issue because the feature definitions comes with a cxf-tools feature which can't be used anymore in 3.x. Given I'm verifying those features, which way should I go ? Remove this feature or change the maven packaging to bundle ? Cheers, Guillaume Nodet
Re: Does Durable subscription or message persistence work for WS-Notification?
Currenly that's not really supported. The main problem is that we'd need to persist the WS-Notification subscriptions in addition to creating durable jms subcribers and that's not yet supported. It's on my todo list but not sure when I'll have enough time to start working on that. On Tue, Mar 27, 2012 at 19:13, YUL yulin...@dell.com wrote: Hi All, I'm a newbie to WS-Notification of CXF. If I understand correctly, WS-Notification is built on top of activeMQ. As a JMS provider, activeMQ supports Durable subscription/message persistence. This means when the client is offline, the messages will be persisted so that when the client is up later, the message can still be pushed to the client. I was just wondering if this is also supported by CXF WS-Notification? When the client is temporarily down or the server is crashed, after the client is up or the server is up again, would the message published earlier still be delivered to the client? Thanks very much, YuLing -- View this message in context: http://cxf.547215.n5.nabble.com/Does-Durable-subscription-or-message-persistence-work-for-WS-Notification-tp5598400p5598400.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Fwd: Accepting proposals regarding early git adoption
FYI -- Forwarded message -- From: Joe Schaefer joe_schae...@yahoo.com Date: Mon, Nov 28, 2011 at 14:28 Subject: Accepting proposals regarding early git adoption To: Apache Infrastructure infrastruct...@apache.org While many of you are aware of the ongoing experiment/alpha test with git hosting for CouchDB, you may not be aware of the recent members@ discussion about git @ Apache, the result of which is to solicit proposals here for projects interested in adopting git now, rather than after the testing phase is over. Any such projects you participate in should write a brief and civil proposal as to why we should select you for further git testing. Proposals should include statements of interest in assisting with the git hosting codebase and associated jira issues from named individuals on the project. We'll allow the remainder of the week to collect proposals before deciding on who gets to go next. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r1182065 - in /cxf/trunk: osgi/karaf/features/src/main/resources/features.xml services/wsn/wsn-osgi/pom.xml
I tried to minimize the number of dependencies installed by not installing
the whole activemq and cxf features.
You just bumped the amount of bundles installed from 6 to a few dozens.
Btw, on which version of karaf did you deploy this feature ? It doen't work
on karaf 2.2.x afaik.
On Tue, Oct 11, 2011 at 22:19, dk...@apache.org wrote:
Author: dkulp
Date: Tue Oct 11 20:19:25 2011
New Revision: 1182065
URL: http://svn.apache.org/viewvc?rev=1182065view=rev
Log:
Fix groupid for bundle, possibly use version of activemq already installed
Modified:
cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
cxf/trunk/services/wsn/wsn-osgi/pom.xml
Modified: cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/osgi/karaf/features/src/main/resources/features.xml?rev=1182065r1=1182064r2=1182065view=diff
==
--- cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
(original)
+++ cxf/trunk/osgi/karaf/features/src/main/resources/features.xml Tue Oct
11 20:19:25 2011
@@ -17,6 +17,8 @@
limitations under the License.
--
features xmlns=http://karaf.apache.org/xmlns/features/v1.0.0;
name=cxf-${project.version}
+
repositorymvn:org.apache.activemq/activemq-karaf/${cxf.activemq.version}/xml/features/repository
+
feature name=cxf-specs version=${project.version}
resolver='(obr)'
bundle
start-level='10'mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/${cxf.servicemix.specs.version}/bundle
bundle
start-level='10'mvn:org.apache.geronimo.specs/geronimo-annotation_1.0_spec/${cxf.geronimo.annotation.version}/bundle
@@ -122,14 +124,9 @@
cxf.wsn.port = 8182
/config
+feature version=[5.4,6)activemq/feature
feature version=${project.version}cxf/feature
-bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/${cxf.geronimo.transaction.version}/bundle
-bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/${cxf.geronimo.jms.version}/bundle
-bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-j2ee-management_1.1_spec/${cxf.geronimo.j2ee.management.version}/bundle
-bundle
dependency=truemvn:org.apache.activemq/kahadb/${cxf.activemq.version}/bundle
-bundle
dependency=truemvn:org.apache.activemq/activemq-core/${cxf.activemq.version}/bundle
-
bundlemvn:org.apache.cxf.services.wsn/cxf-services-wsn-osgi/${project.version}/bundle
/feature
/features
Modified: cxf/trunk/services/wsn/wsn-osgi/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/services/wsn/wsn-osgi/pom.xml?rev=1182065r1=1182064r2=1182065view=diff
==
--- cxf/trunk/services/wsn/wsn-osgi/pom.xml (original)
+++ cxf/trunk/services/wsn/wsn-osgi/pom.xml Tue Oct 11 20:19:25 2011
@@ -34,7 +34,7 @@
dependencies
dependency
-groupIdorg.apache.cxf/groupId
+groupIdorg.apache.cxf.services.wsn/groupId
artifactIdcxf-services-wsn-core/artifactId
version${project.version}/version
/dependency
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: svn commit: r1182065 - in /cxf/trunk: osgi/karaf/features/src/main/resources/features.xml services/wsn/wsn-osgi/pom.xml
On Tue, Oct 11, 2011 at 22:34, Daniel Kulp dk...@apache.org wrote:
On Tuesday, October 11, 2011 10:28:11 PM Guillaume Nodet wrote:
I tried to minimize the number of dependencies installed by not
installing
the whole activemq and cxf features.
Well, it NEEDS the CXF feature for the logging and utility stuff (until we
split cxf-common-utilities into it's own bundle or something). And I
don't
want multiple versions of ActiveMQ installed. I think for the version
range
to work, it had to be a feature, not on a specific bundle. I'd love
to
see the activemq features.xml file setup to allow a minimal or invm or
similar smaller feature that could be relied on instead, but that's not
available right now.
If it's really about a few classes, I'd much rather embed them in a private
package than requiring a ton of bundles.
For activemq, if you install the obr feature before installing the wsn, and
if you already have an activemq bundle installed, it won't install the
specified version. That's what the resolver=(obr) and dependency=true
are used for in the descriptor.
You just bumped the amount of bundles installed from 6 to a few dozens.
Btw, on which version of karaf did you deploy this feature ? It doen't
work
on karaf 2.2.x afaik.
2.2.4-SNAPSHOT (will try with the release in a bit).
Dan
On Tue, Oct 11, 2011 at 22:19, dk...@apache.org wrote:
Author: dkulp
Date: Tue Oct 11 20:19:25 2011
New Revision: 1182065
URL: http://svn.apache.org/viewvc?rev=1182065view=rev
Log:
Fix groupid for bundle, possibly use version of activemq already
installed
Modified:
cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
cxf/trunk/services/wsn/wsn-osgi/pom.xml
Modified: cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/osgi/karaf/features/src/main/reso
urces/features.xml?rev=1182065r1=1182064r2=1182065view=diff
== ---
cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
(original)
+++ cxf/trunk/osgi/karaf/features/src/main/resources/features.xml Tue
Oct
11 20:19:25 2011
@@ -17,6 +17,8 @@
limitations under the License.
--
features xmlns=http://karaf.apache.org/xmlns/features/v1.0.0;
name=cxf-${project.version}
+
repositorymvn:org.apache.activemq/activemq-karaf/${cxf.activemq.vers
ion}/xml/features/repository
+
feature name=cxf-specs version=${project.version}
resolver='(obr)'
bundle
start-level='10'mvn:org.apache.servicemix.specs/org.apache.servicemix.s
pecs.activation-api-1.1/${cxf.servicemix.specs.version}/bundle
bundle
start-level='10'mvn:org.apache.geronimo.specs/geronimo-annotation_1.0_s
pec/${cxf.geronimo.annotation.version}/bundle @@ -122,14 +124,9 @@
cxf.wsn.port = 8182
/config
+feature version=[5.4,6)activemq/feature
feature version=${project.version}cxf/feature
-bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/${
cxf.geronimo.transaction.version}/bundle -bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/${
cxf.geronimo.jms.version}/bundle -bundle
dependency=truemvn:org.apache.geronimo.specs/geronimo-j2ee-management
_1.1_spec/${cxf.geronimo.j2ee.management.version}/bundle -
bundle
dependency=truemvn:org.apache.activemq/kahadb/${cxf.activemq.version}
/bundle -bundle
dependency=truemvn:org.apache.activemq/activemq-core/${cxf.activemq.v
ersion}/bundle -
bundlemvn:org.apache.cxf.services.wsn/cxf-services-wsn-osgi/${project.
version}/bundle
/feature
/features
Modified: cxf/trunk/services/wsn/wsn-osgi/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/services/wsn/wsn-osgi/pom.xml?rev
=1182065r1=1182064r2=1182065view=diff
== --- cxf/trunk/services/wsn/wsn-osgi/pom.xml (original)
+++ cxf/trunk/services/wsn/wsn-osgi/pom.xml Tue Oct 11 20:19:25 2011
@@ -34,7 +34,7 @@
dependencies
dependency
-groupIdorg.apache.cxf/groupId
+groupIdorg.apache.cxf.services.wsn/groupId
artifactIdcxf-services-wsn-core/artifactId
version${project.version}/version
/dependency
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: svn commit: r1182085 - in /cxf/trunk: osgi/karaf/features/src/main/resources/features.xml parent/pom.xml
If CXF is supposed to run on JDK 5, we should keep using Activemq 5.4 as 5.5
can't be used on JDK 5 afaik.
On Tue, Oct 11, 2011 at 23:02, dk...@apache.org wrote:
Author: dkulp
Date: Tue Oct 11 21:02:14 2011
New Revision: 1182085
URL: http://svn.apache.org/viewvc?rev=1182085view=rev
Log:
Use a working activemq feature
Modified:
cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
cxf/trunk/parent/pom.xml
Modified: cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/osgi/karaf/features/src/main/resources/features.xml?rev=1182085r1=1182084r2=1182085view=diff
==
--- cxf/trunk/osgi/karaf/features/src/main/resources/features.xml
(original)
+++ cxf/trunk/osgi/karaf/features/src/main/resources/features.xml Tue Oct
11 21:02:14 2011
@@ -17,7 +17,7 @@
limitations under the License.
--
features xmlns=http://karaf.apache.org/xmlns/features/v1.0.0;
name=cxf-${project.version}
-
repositorymvn:org.apache.activemq/activemq-karaf/${cxf.activemq.version}/xml/features/repository
+
repositorymvn:org.apache.activemq/activemq-karaf/${cxf.osgi.activemq.version}/xml/features/repository
feature name=cxf-specs version=${project.version}
resolver='(obr)'
bundle
start-level='10'mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.activation-api-1.1/${cxf.servicemix.specs.version}/bundle
Modified: cxf/trunk/parent/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/trunk/parent/pom.xml?rev=1182085r1=1182084r2=1182085view=diff
==
--- cxf/trunk/parent/pom.xml (original)
+++ cxf/trunk/parent/pom.xml Tue Oct 11 21:02:14 2011
@@ -56,7 +56,10 @@
!-- please maintain alphabetical order here --
cxf.abdera.version1.1.2/cxf.abdera.version
+!-- Due to AMQ-3276, we need to keep the system tests at 5.4.2,
but we
+ need the 5.5.0 features.xml. :-( --
cxf.activemq.version5.4.2/cxf.activemq.version
+cxf.osgi.activemq.version5.5.0/cxf.osgi.activemq.version
cxf.derby.version10.2.2.0/cxf.derby.version
cxf.jaxb21.version2.1/cxf.jaxb21.version
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: [DiSCUSS] WS-Notification
I've started to re-architect the WS-Notification implementation to get rid of JBI and be pure JAX-WS based. The results are available at https://github.com/gnodet/wsn . I think there was a consensus to move the code base to CXF, but I just want to make sure everyone agree. Also, I'd like to keep the implementation lightweight and keep it pure JAXWS based if possible. On Fri, Jul 8, 2011 at 10:20, Guillaume Nodet gno...@gmail.com wrote: Just want to start a discussion on WS-Notification because I've had a chat last week with a ServiceMix user about that. That component is not heavily used, but we always have a few users reporting bugs and such. This component is really the only one which is no replacement in Camel. Given WS-Notification is really just an implementation of a WSDL, I wonder if it would be easier to simply port it to a pure CXF web service so that it would not be tied to JBI anymore, and would also solve a bunch of problems related to the behavior of WS-Addressing inside the JBI bus (which is not really what users expect when using WS-Notification). So I'd like to gauge the interest in re-architecting this component to make it more easily consumable without JBI / NMR, just as a JAX-WS web service (if possible even with no ties to CXF).We could then maybe plan a few enhancements such as the use of non simple topics definitions and such. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DiSCUSS] WS-Notification
On Wed, Oct 5, 2011 at 18:01, Daniel Kulp dk...@apache.org wrote: On Wednesday, October 05, 2011 5:22:01 PM Guillaume Nodet wrote: I've started to re-architect the WS-Notification implementation to get rid of JBI and be pure JAX-WS based. The results are available at https://github.com/gnodet/wsn . I think there was a consensus to move the code base to CXF, but I just want to make sure everyone agree. I definitely agree. :-) Very excited about that prospect. :-) How close to ready is it? Is it something that we can get into CXF shortly for inclusion with CXF 2.5? The code is really the same than in ServiceMix, only the JBI bits have been replaced by JAX-WS. A few tests would definitely help, but the code base itself is mostly done. I recall some users would have been interested in having more features like complex topics or such, but not having those features does not mean the base service is not usable. Also, I'd like to keep the implementation lightweight and keep it pure JAXWS based if possible. I'm quite a bit less excited about this. I would say pure jaxws + cxf- common-utilities is fine as it should likely use the CXF logging stuff, CXF XML utilities (DOMUtils, etc...), etc... duplicating stuff from common to just avoid a dep is silly to me. Yeah, I meant I'd like to be independent of the jaxws provider. The code is currently using slf4j for logging though. Dan On Fri, Jul 8, 2011 at 10:20, Guillaume Nodet gno...@gmail.com wrote: Just want to start a discussion on WS-Notification because I've had a chat last week with a ServiceMix user about that. That component is not heavily used, but we always have a few users reporting bugs and such. This component is really the only one which is no replacement in Camel. Given WS-Notification is really just an implementation of a WSDL, I wonder if it would be easier to simply port it to a pure CXF web service so that it would not be tied to JBI anymore, and would also solve a bunch of problems related to the behavior of WS-Addressing inside the JBI bus (which is not really what users expect when using WS-Notification). So I'd like to gauge the interest in re-architecting this component to make it more easily consumable without JBI / NMR, just as a JAX-WS web service (if possible even with no ties to CXF).We could then maybe plan a few enhancements such as the use of non simple topics definitions and such. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DiSCUSS] WS-Notification
On Wed, Oct 5, 2011 at 19:45, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Dan (and Guillaume), I think it makes more sense to include WS-N in CXF. As the current implementation is tied to ActiveMQ, I think it would required some enhancement to: - use a pure JMS implementation, allowing us to use ActiveMQ and any other JMS broker (WebSphere MQ Series for instance) Yes, we discussed that, but a few features that are not provided by a pure JMS layer are needed (mostly the ability to know when consumers on a give topic subscribe / unsubscribe, and also composite destinations). I think it's a definitely a nice to have to be able to work with another JMS broker in a degraded mode or something like that, but from a pure WS-Notification pov, it's really an implementation detail. - use a fully OSGi compliant implementation You mean be able to deploy it as a bundle, or something more than that ? I guess the main services could be exposed as OSGi services. - be able to describe the WS-N endpoint (poll, etc) in Spring/Blueprint CXF and in Camel I'm not so sure about the real need. That was possible with the servicemix component, but afaik, most users used it in a pure web services standard way. But it should not be so difficult to add it back by leveraging jaxb. I'm ready to help on these topics ;) My 0.02$ Regards JB On 10/05/2011 06:31 PM, Daniel Kulp wrote: Just wanted to mention that Guillaume and I have been chatting a bit about the code on the CXF IRC channel today. He ran into some differences with various JAX-WS implementations: http://irclogs.dankulp.com/**logs/irclogger_log/cxf?date=** 2011-10-05,Wedsel=128#l124http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wedsel=128#l124 that required some less clean code. Nothing major. We also talked about the JMS stuff currently being tied to ActiveMQ and options around that: http://irclogs.dankulp.com/**logs/irclogger_log/cxf?date=** 2011-10-05,Wedsel=194#l190http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wedsel=194#l190 That last stuff is definitely not critical (tied to ActiveMQ is perfectly fine for now as long as we mention that). Dan On Wednesday, October 05, 2011 6:13:15 PM Guillaume Nodet wrote: On Wed, Oct 5, 2011 at 18:01, Daniel Kulpdk...@apache.org wrote: On Wednesday, October 05, 2011 5:22:01 PM Guillaume Nodet wrote: I've started to re-architect the WS-Notification implementation to get rid of JBI and be pure JAX-WS based. The results are available at https://github.com/gnodet/wsn . I think there was a consensus to move the code base to CXF, but I just want to make sure everyone agree. I definitely agree. :-) Very excited about that prospect. :-) How close to ready is it? Is it something that we can get into CXF shortly for inclusion with CXF 2.5? The code is really the same than in ServiceMix, only the JBI bits have been replaced by JAX-WS. A few tests would definitely help, but the code base itself is mostly done. I recall some users would have been interested in having more features like complex topics or such, but not having those features does not mean the base service is not usable. Also, I'd like to keep the implementation lightweight and keep it pure JAXWS based if possible. I'm quite a bit less excited about this. I would say pure jaxws + cxf- common-utilities is fine as it should likely use the CXF logging stuff, CXF XML utilities (DOMUtils, etc...), etc... duplicating stuff from common to just avoid a dep is silly to me. Yeah, I meant I'd like to be independent of the jaxws provider. The code is currently using slf4j for logging though. Dan On Fri, Jul 8, 2011 at 10:20, Guillaume Nodetgno...@gmail.com wrote: Just want to start a discussion on WS-Notification because I've had a chat last week with a ServiceMix user about that. That component is not heavily used, but we always have a few users reporting bugs and such. This component is really the only one which is no replacement in Camel. Given WS-Notification is really just an implementation of a WSDL, I wonder if it would be easier to simply port it to a pure CXF web service so that it would not be tied to JBI anymore, and would also solve a bunch of problems related to the behavior of WS-Addressing inside the JBI bus (which is not really what users expect when using WS-Notification). So I'd like to gauge the interest in re-architecting this component to make it more easily consumable without JBI / NMR, just as a JAX-WS web service (if possible even with no ties to CXF).We could then maybe plan a few enhancements such as the use of non simple topics definitions and such. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Daniel Kulp dk...@apache.org
Re: [DISCUSSION] Support WS-Notification in CXF
I think the main reason is that WS-Notification is part of the WS-* area. It's just that CXF may be a more intuitive place for such a codebase. The current implementation rely on JBI, so ServiceMix was definitely a good place. If we get rid of the JBI dependency to move to a pure JAX-WS service, it may be better to move it to CXF. It's really just a matter of where people would search for such a component first. Note that we haven't voted on anything yet in ServiceMix, and there's no need to vote if CXF does not want the codebase anyway. So we're just really starting the discussion. On Fri, Jul 8, 2011 at 12:25, Dennis Sosnoski d...@sosnoski.com wrote: Hi Freeman, It seems like WS-Notification really is just a web service application that can run on CXF. Do you see a reason for it to be integrated into the CXF codebase? - Dennis On 07/08/2011 09:36 PM, Freeman Fang wrote: Hi Team, Recently we're discussing on Servicemix Dev mailling list about redesign ws-notification component, previously it was designed as JBI ServiceEngine and need work together with BindingComponet(like servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to make it working without any JBI stuff and we believe this is more natural as ws-notification[2] actually is wsdl based and we think move the ws-notification into CXF is more reasonable. Though no concrete idea now, my gut feeling is that we can leverage our jms transport to do this. How about we support WS-Notification in CXF? Any feedback is appreciated. [1]http://servicemix.396122.**n5.nabble.com/DiSCUSS-WS-** Notification-td4563871.htmlhttp://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html [2]http://www.oasis-open.org/**committees/tc_home.php?wg_**abbrev=wsnhttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn Best Regards Freeman --**--- Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.**com http://freemanfang.blogspot.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
We're not talking about implementing something new here. We have an existing code base in ServiceMix that we may work on to remove the ties onto JBI. We were just wondering if CXF would be a better place for it. I have really no problems with keeping it in ServiceMix fwiw. Now if someone wants to start implementing a new WS-Eventing service, that's completely unrelated to this issue. Also, we don't actually use it internally in ServiceMix, so ServiceMix has no requirements, but our we have some users that do use it, that's all. On Fri, Jul 8, 2011 at 14:40, Alessio Soldano asold...@redhat.com wrote: Hi, I'm not sure of the exact requirements in ServiceMix, in any case I suggest evaluating the WS-Eventing spec from WS-ResourceAccess http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being finalized *really* soon. Cheers Alessio On 07/08/2011 11:36 AM, Freeman Fang wrote: Hi Team, Recently we're discussing on Servicemix Dev mailling list about redesign ws-notification component, previously it was designed as JBI ServiceEngine and need work together with BindingComponet(like servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to make it working without any JBI stuff and we believe this is more natural as ws-notification[2] actually is wsdl based and we think move the ws-notification into CXF is more reasonable. Though no concrete idea now, my gut feeling is that we can leverage our jms transport to do this. How about we support WS-Notification in CXF? Any feedback is appreciated. [1] http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn Best Regards Freeman - Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com -- Alessio Soldano Web Service Lead, JBoss -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
That's a bit harsh. It is functional and implements all the required bits afaik. There are some missing stuff such as complex topics expressions though. Most of the problem come from WS-Addressing: it is heavily used in WS-Notification, but given the component was designed to work inside the JBI bus, the behavior is not the one you would necessarily expect when using pure web services and where ws-addressing would target http services, not services in the JBI bus. Also, I agree the component has been disfunctional in ServiceMix 4, but mostly due to the fact that the underllying ws-addressing related JBI piece of code had a behavior change between 3.x and 4.x. And fwiw, the ws-notification component completely rely on JMS for the implementation. Do you have more detailed problems / missing features ? On Fri, Jul 8, 2011 at 16:07, Jeff Genender jgenen...@apache.org wrote: On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote: We're not talking about implementing something new here. We have an existing code base in ServiceMix that we may work on to remove the ties onto JBI. We were just wondering if CXF would be a better place for it. I have really no problems with keeping it in ServiceMix fwiw. Well... lets be honest... the SMX version is pretty much non-functional and it only implements a subset of WSN. I think it probably should be re-written from scratch. Jeff Now if someone wants to start implementing a new WS-Eventing service, that's completely unrelated to this issue. Also, we don't actually use it internally in ServiceMix, so ServiceMix has no requirements, but our we have some users that do use it, that's all. On Fri, Jul 8, 2011 at 14:40, Alessio Soldano asold...@redhat.com wrote: Hi, I'm not sure of the exact requirements in ServiceMix, in any case I suggest evaluating the WS-Eventing spec from WS-ResourceAccess http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being finalized *really* soon. Cheers Alessio On 07/08/2011 11:36 AM, Freeman Fang wrote: Hi Team, Recently we're discussing on Servicemix Dev mailling list about redesign ws-notification component, previously it was designed as JBI ServiceEngine and need work together with BindingComponet(like servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to make it working without any JBI stuff and we believe this is more natural as ws-notification[2] actually is wsdl based and we think move the ws-notification into CXF is more reasonable. Though no concrete idea now, my gut feeling is that we can leverage our jms transport to do this. How about we support WS-Notification in CXF? Any feedback is appreciated. [1] http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn Best Regards Freeman - Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com -- Alessio Soldano Web Service Lead, JBoss -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Then I think we are in agreement. All the code related to ws-addressing support in WS-Notification would have to be rewritten when getting rid of JBI.However, if you were talking about CXF interceptors, I'm not sure that's the right way to go, as implementing a web service purely using interceptors might be a bit more complicated than just using wsdl - java and filling the gaps. That does not prevent the introduction of pluggability in any way though. On Fri, Jul 8, 2011 at 18:24, Jeff Genender jgenen...@apache.org wrote: Oh its not meant to be harsh... please don't take it personally... ;-) I am well aware of its implementation since we dissected the heck out of it ;-) You also seem to be aware of its issues too from your response below ;-) We tried to leverage it on a project that needed to make extensive use of pub/sub along with pull points and it was extremely lacking in its delivery. Hence we more or less rolled our own. Yes you are spot on with the WS-Addressing... that was a *big* area of trouble we had and an area we also had to skirt to some degree. I really think the WS-Notification needs a much more pluggable approach to the entire model (which is what we ended up writing to a degree). Its somewhat hard to genericize the pub/sub implementation, especially when the pull point is somewhat open season on what you can place in its return. I think the interceptor pattern works real well and hence becomes a perfect complement to the CXF architecture. Areas for interception are synchronous vs asynchronous (i.e. pull point immediate return value vs. pub/sub), etc. Just my 3.14159 cents ;-) Jeff On Jul 8, 2011, at 10:00 AM, Guillaume Nodet wrote: That's a bit harsh. It is functional and implements all the required bits afaik. There are some missing stuff such as complex topics expressions though. Most of the problem come from WS-Addressing: it is heavily used in WS-Notification, but given the component was designed to work inside the JBI bus, the behavior is not the one you would necessarily expect when using pure web services and where ws-addressing would target http services, not services in the JBI bus. Also, I agree the component has been disfunctional in ServiceMix 4, but mostly due to the fact that the underllying ws-addressing related JBI piece of code had a behavior change between 3.x and 4.x. And fwiw, the ws-notification component completely rely on JMS for the implementation. Do you have more detailed problems / missing features ? On Fri, Jul 8, 2011 at 16:07, Jeff Genender jgenen...@apache.org wrote: On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote: We're not talking about implementing something new here. We have an existing code base in ServiceMix that we may work on to remove the ties onto JBI. We were just wondering if CXF would be a better place for it. I have really no problems with keeping it in ServiceMix fwiw. Well... lets be honest... the SMX version is pretty much non-functional and it only implements a subset of WSN. I think it probably should be re-written from scratch. Jeff Now if someone wants to start implementing a new WS-Eventing service, that's completely unrelated to this issue. Also, we don't actually use it internally in ServiceMix, so ServiceMix has no requirements, but our we have some users that do use it, that's all. On Fri, Jul 8, 2011 at 14:40, Alessio Soldano asold...@redhat.com wrote: Hi, I'm not sure of the exact requirements in ServiceMix, in any case I suggest evaluating the WS-Eventing spec from WS-ResourceAccess http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being finalized *really* soon. Cheers Alessio On 07/08/2011 11:36 AM, Freeman Fang wrote: Hi Team, Recently we're discussing on Servicemix Dev mailling list about redesign ws-notification component, previously it was designed as JBI ServiceEngine and need work together with BindingComponet(like servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to make it working without any JBI stuff and we believe this is more natural as ws-notification[2] actually is wsdl based and we think move the ws-notification into CXF is more reasonable. Though no concrete idea now, my gut feeling is that we can leverage our jms transport to do this. How about we support WS-Notification in CXF? Any feedback is appreciated. [1] http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn Best Regards Freeman - Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com -- Alessio Soldano Web Service Lead, JBoss
Re: Startup speed, XML, etc.....
31/sec Invoke: 48871 30/sec Setup config: 49255 30/sec -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Use confluence wiki for ... wiki
I would suggest the use of confluence as a real wiki. Keep our web site the way it is, but the page Zoe is currently working on imho could clearly fit in a real wiki, as it's not project documentation ... Thoughts ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Apache CXF 2.3.2
+1 On Tue, Jan 18, 2011 at 05:26, Daniel Kulp dk...@apache.org wrote: We've had a busy 8 weeks or so despite the holidays. We've managed to fix over 75 JIRA issues since 2.3.1 which is quite remarkable . This also fixes a bunch of OSGi related issues that are needed for Camel and ServiceMix. Note: this vote also includes a release of the cxf-xjc-utils to fix a bunch of issues that were resolved there. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315921styleName=TextprojectId=12310511Create=Create The Maven staging areas are at: https://repository.apache.org/content/repositories/orgapachecxf-041/ https://repository.apache.org/content/repositories/orgapachecxf-042/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-042/org/apache/cxf/apache-cxf/2.3.2/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2 http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/ The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release CXF 2.1.7
+1 On Thu, Oct 8, 2009 at 17:22, Daniel Kulp dk...@apache.org wrote: This is a vote to release CXF 2.1.7 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.6 release. Over 25 JIRA issues are resolved for 2.1.7 List of issues: The Maven staging area is at: https://repository.apache.org/content/repositories/cxf-staging-006/ The distributions are in: https://repository.apache.org/content/repositories/cxf-staging-006/org/apache/cxf/apache-cxf/2.1.7/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.7 Here is my +1. The vote will be open here for at least 72 hours. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Jetty Continuations in CXF
see it it so shoot :-) Comments are welcome Sergey -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Jetty Continuations in CXF
Agreed. Especially if continuations can be supported somehow on the JMS transport, ServiceMix should not depend on the jetty internal continuations. On Wed, Nov 12, 2008 at 1:08 PM, Freeman Fang [EMAIL PROTECTED] wrote: Sergey Beryozkin wrote: So before a suspended runtime exception reaches the nearest catch block in the CXF code where we can get a chance to do something to preserve the state of the given invocation, resume() might've alreadty occurred. That's why you need some synchronization blocks to ensure resume can not be called before suspend has been handled somehow. I would suggest wrapping the jetty continuation into something more CXF specific which could be used for other transports too. Yes, I think we're on the same page here. Case 2 is exactly about the user code interacting with the (jetty - when http is involved) continuations indirectly. But I think we agree that if a user code does suspend on an underlying jetty continuation object directly then a race condition leading to a 'loss' of message might occur if resume() is done in parallel, virtually immediately after suspend() was called. Question : how will SMX CXF Binding Component interact with (Jetty) continuations when dealing with CXF-originated invocations ? The Continuation wrappers will be available through an internal CXF input Message and through JAXWS WebServiceContext (or JAXRS one later on) - will CXF BC be able to get hold of such wrappers ? If yes then I guess we have no problems at all ? Yes, I think so, get continuation from cxf message (org.apache.cxf.message.Message) is fine for CxfBcConsumer. Whoever calls the suspend() does not really matter here. The problem is that suspending the continuation will trigger a timer in jetty. When this timer elapse, the request will be replayed with a flag on the continuation saying it has been timed out somehow (we check the cont.isPending() flag in smx). At this point, you need to ensure that the timeout will be handled correctly both on the http response side, and on the cxf message side. I'm feeling silly :-) as I don't get it. Input : 1. What CXF JettyDestination can do if it finds out that a continuation with say 'resumed' status, which is what I see in case1 as I described earlier has no message associated with it ? 2. Why it should care about the suspended/resumed status of the continuation when its *isNew()* call returns *false* ? If it has a message attached to it then what difference would it make for the resumed invocation whether this invocation has been resumed due to that continuation being resumed explicitly or timed out ? I honestly see no difference Output : I don't so anything at all on the Jetty Destination output, as far as continuations are concerned. Some code down the line calls cont.resume() or this continuation expired, in both cases the request is retried by Jetty (that's the inbound path). If the existing message is found on the incoming http request's continuatiuon - we resume a paused invocation otherwise we start a new one. As I said - we might throw an exception at this point if we find that the not-new continuation has no message attached to it - logging a warning for now. Either way, eventually this invocation returns. Why should we do anything about the fact at this stage that this invocation was 'resumed' by the timer expiring ? Am I totally slow ? Cheers, Sergey -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Jetty Continuations in CXF
there, say we'll call PhaseInterceptorPhase.resume(), etc, something along the lines you suggested 3. Basically, to do this right, we'd need to audit pretty much everything to make sure nothing is stored on the stack and is resumable. Once that is done, the rest is relatively easy. Yea - probably can be the quite challenging Thoughts ? Cheers, Sergey [1] http://docs.codehaus.org/display/JETTY/Continuations [2] https://issues.apache.org/jira/browse/CXF-1835 [3] https://issues.apache.org/jira/browse/CXF-1835?focusedCommentId=126 42361 #ac tion_12642361 -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Jetty Continuations in CXF
); // or PhaseInterceptorChain.suspend() } } Most likely, we could add a suspend() method to PhaseInterceptorChain that would do something very similar and throw a SuspendException or something in the same package as PhaseInterceptorChain. When do we trigger this PhaseInterceptorChain.suspend() call though ? That would get propogated back to the JettyDestination that could then call the jetty things. The JMS transport could just catch it and more or less ignore it. We'd then have to add a resume() method to the chain which would call back onto a listener that the transport provides. Jetty would just call the jetty resume stuff. JMS would probably put a runnable on the workqueue to restart the chain. ok Also, suspend() would need to check if there is a listener. If not, it should not throw the exception. Thus, the servlet transport and CORBA stuff that couldn't do this would pretty much just ignore it. ok, not sure I understand about the listener but I think I see what you mean... Basically, this needs to be done in such a way that it CAN work for the non-jetty cases. However, it also needs to be done in a way that doesn't affect existing transports. +1 Cheers, Sergey Dan 2. Now, if the above can be figured out, the next problem arises: when the trigger to wake up the continuation occurs I think we can can do in JettyDestination omething similar to what is done in SMX. When getting a SuspendedFault exception, we can extract from it the original continuation instance or else we can do ContinuationSupport.getContinuation(request) which should return us the instance. At this point we can use it as a ket to store the current exchange plus all the other info we may need. When the user/application code does continuation.resume(), the Jetty thread will come back and we will use the ContinuationSupport.getContinuation(request) to get us the active continuation and use it to extract the suspended exchange and proceed from there, say we'll call PhaseInterceptorPhase.resume(), etc, something along the lines you suggested 3. Basically, to do this right, we'd need to audit pretty much everything to make sure nothing is stored on the stack and is resumable. Once that is done, the rest is relatively easy. Yea - probably can be the quite challenging Thoughts ? Cheers, Sergey [1] http://docs.codehaus.org/display/JETTY/Continuations [2] https://issues.apache.org/jira/browse/CXF-1835 [3] https://issues.apache.org/jira/browse/CXF-1835?focusedCommentId=126 42361 #ac tion_12642361 -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Jetty Continuations in CXF
(), the Jetty thread will come back and we will use the ContinuationSupport.getContinuation(request) to get us the active continuation and use it to extract the suspended exchange and proceed from there, say we'll call PhaseInterceptorPhase.resume(), etc, something along the lines you suggested 3. Basically, to do this right, we'd need to audit pretty much everything to make sure nothing is stored on the stack and is resumable. Once that is done, the rest is relatively easy. Yea - probably can be the quite challenging Thoughts ? Cheers, Sergey [1] http://docs.codehaus.org/display/JETTY/Continuations [2] https://issues.apache.org/jira/browse/CXF-1835 [3] https://issues.apache.org/jira/browse/CXF-1835?focusedCommentId=126 42361 #ac tion_12642361 -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] David Bosschaert for committer
+1 Btw, votes on people are usually held on the private mailing list to avoid potential problems. On Tue, Nov 11, 2008 at 4:57 PM, Eoghan Glynn [EMAIL PROTECTED] wrote: Folks, I'd like to propose David Bosschaert for CXF committership, on the basis of - the many quality patches he's submitted for our CXF-based distributed OSGi reference implementation - his community participation especially in driving the re-integration of the Felix fork in the CXF sandox with the main Felix codebase - his promotion of CXF (by extension via the dOSGi RI) in the wider OSGi community Consider this proposal a +1 from me. The vote will remain open for at least 72 hours. Cheers, Eoghan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Question about JMS Session Pool
Commons-pool is not a JMS connection pool. I was mostly thinking about the ActiveMQ one, but i think each JMS provider should have its own connection pool. In a Java EE environment, the connection pool is done by the server and you don't have to think about it. Anyway, it's part of the ConnectionFactory set up by the user, so the CXF code should not really take care of it. On Wed, Sep 3, 2008 at 7:23 PM, Christian Schneider [EMAIL PROTECTED] wrote: Guillaume Nodet schrieb: The Spring JMS layer contains two parts: the JmsTemplate which can be used to send / consume messages, and the MessageListenerContainers that can be used to consumer messages more efficiently. Caching is configurable on the DefaultMessageListenerContainer, but the JmsTemplate doesn't do caching, mainly because it is meant to work in a Java EE environment, where the client is supposed to create a connection / session / sender every time. Thus, a really good thing is to configure a JMS pooled connection factory underneath (see http://activemq.apache.org/spring-support.html). Hi Guillaume, what connection pooling do you use? I know there is one implementation in http://commons.apache.org/pool/. Spring also contains Pooled Session Factories but there are several... Which would you suggest to use? Best regards Christian -- Christian Schneider --- http://www.liquid-reality.de -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
