Folks,
I'm going to declare this vote as passed, with the following votes cast:
+1: Sean O'Callaghan, Sergey Beryozkin, David Bosschaert, Marc Schaaf, Jeff
Genender, Dan Kulp, Eoghan Glynn
I've promoted the artifacts to central and copied the distributions to the
cxf/dosgi
Folks,
Now that the release notes are all fixed up, I'm calling a second vote to
release
CXF Distributed OSGi 1.2.
The release notes contain a description of new features and bugs fixed
in this release:
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/releas
Folks,
I'm pulling this release after noticing that the release notes in the
multi-bundle distro weren't updated for 1.2.
I'll cut a take-two and call another vote later on today.
Cheers,
Eoghan
On 20 July 2010 08:42, Eoghan Glynn wrote:
>
> Here's the raw tex
emos and
> > it works fine.
> >
> > Here's my +1
> >
> > David
> >
> > On 20 July 2010 08:42, Eoghan Glynn wrote:
> > > Here's the raw text with the link formatting removed:
> > >
> > >
> > > Folks,
>
Also tags to both 1.1 and 1.2 are in there...
>
> Cheers,
>
> David
>
> On 19 July 2010 23:45, Eoghan Glynn wrote:
> > Folks,
> >
> > I'm calling a vote to release CXF Distributed OSGi 1.2.
> >
> > In addition to providing the Reference Implement
Folks,
I'm calling a vote to release CXF Distributed OSGi 1.2.
In addition to providing the Reference Implementation to the OSGi Remote
Services Specification, the CXF Distributed OSGi 1.2 release now also
provides the Reference Implementation of the OSGi Remote Service Admin
Specification versio
tweaking to run on
> all machines (including yours - if you have any tips I would love to
> hear them :)
>
> Cheers,
>
> David
>
> On 19 July 2010 12:35, Eoghan Glynn wrote:
> >
> > Hi David,
> >
> >> This exception happens when the remot
happy that I'm seeing a
phantom issue here.
Cheers,
Eoghan
On 19 July 2010 10:30, wrote:
> Hi Eoghan,
>
> On 17 July 2010 12:59, Eoghan Glynn wrote:
> >> Eoghan would you have some cycles?
> >
> > Yeah.
>
> Excellent!
>
> > A couple of things
> I think we're ready for a release!
Great!
> Eoghan would you have some cycles?
Yeah.
A couple of things before I go ahead and cut the release:
- can you update the release notes[1] with a summary of what's new in this
release?
- does this TimeoutException[2] in TestExportService.testAccessE
> A more long-term option might to ship an entire distro of karaf with
dOSGi,
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for
ugh most of the
> > > config.properties are probably reusable across diff versions)
> > > DOSGI RI does only ship the fragments of config properties which are
> > built
> > > during the multi-bundle build...
> > >
> > > I'm just curious, why was the
..
>
> I'm just curious, why was the CXF import updated to include 0.0.0 ?
>
> cheers, Sergey
>
>
> On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn wrote:
>
> > Have you tried overriding the org.osgi.framework.system.packages property
> > in
> > fel
Have you tried overriding the org.osgi.framework.system.packages property in
felix/conf/config.properties, with a list of packages specifically excluding
javax.xml.ws.*?
This is the approach taken by SMX to get around these sort of issues. See
for ex:
wget
https://www.apache.org/dist/servicemix/s
> Tasks left would be:
> * When the above is done, cut the actual release candidate(s).
I can help cutting the release when you're ready to go.
Cheers,
Eoghan
On 11 June 2010 16:53, David Bosschaert wrote:
> Great, thanks Marc!
>
> I think we're getting close to something that is releasable.
+1
/Eoghan
On 19 March 2010 01:21, Daniel Kulp wrote:
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.6 release. Over 55 JIRA issues
> are resolved for 2.2.7.
>
> List of issues:
>
> https://issues.apache.org/jira/secure/ReleaseN
for JMX port and also I could connect to the server
> > using JConsole.
> >
> > I will try your route.
> >
> > Regards,
> >
> > Ulhas Bhole
> >
> >
> > On Thu, Mar 18, 2010 at 10:05 PM, Eoghan Glynn
> wrote:
> >
> >> Ulhas,
&
Ulhas,
How are you picking up the config file?
For example, if you're running the server via ant, you'd need to change the
server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml from:
to:
Alternatively, you could change the
$CXF_HOME/sampl
+1
/Eoghan
On 10 March 2010 14:29, Daniel Kulp wrote:
>
> David's been doing a good job lately of answering questions on the
> mailing lists and getting involved there. He's also submitted several
> high
> quality patches for the ws-security and security-policy stuff. The patches
> are all v
+1
Cheers,
Eoghan
On 9 March 2010 16:09, David Bosschaert wrote:
> Hi all,
>
> I would like to propose Marc Schaaf as a committer for CXF. Marc has
> written a tremendous amount of code for CXF-DOSGi (which he provided
> as patches to JIRA), making it compliant with the OSGi 4.2 Remote
> Servic
Have you considered just using the ServiceMix versions of the JSR-311 spec?
Code here:
http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.0/
http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/
Artefacts here:
http://repo2.maven.org/maven2/org/apache/s
cent tiny bundles integration could take care
> of this. Have a look at the bottom example in
> http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles. Do you think
> that will do it?
>
> Cheers,
>
> David
>
> 2010/1/22 Eoghan Glynn :
> >
> > David,
> >
&g
David,
One thing to note about pax-exam is that its doesn't AFAIK have a feature
analogous to the spring-osgi-test support for accessing and adding to the
manifest for the on-the-fly bundle.
Now I don't know whether we could possibly live without this
manifest-mangling as currently done by the dO
+1
Cheers,
Eoghan
2010/1/20 Daniel Kulp
>
> This is a vote to release CXF 2.1.9
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.8 release. Over 43 JIRA issues
> are resolved for 2.1.9
>
> *Note:* as announced earlier this will be
+1
Cheers,
Eoghan
2010/1/20 Freeman Fang
> +1
>
> Freeman
>
> On 2010-1-20, at 上午9:44, Daniel Kulp wrote:
>
>
>> This is a vote to release CXF 2.2.6
>>
>> Once again, there have been a bunch of bug fixes and enhancements that
>> have been done compared to the 2.2.5 release. Over 78 JIRA issue
Hmmm ... smells like a Nexus issue.
If I follow that link, I'm redirected to:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar
with the message:
Item not foun
> Hope everyone is ok with this.
Go for it!
And welcome to the project, Marc.
Cheers,
Eoghan
+1
Cheers,
Eoghan
2009/12/3 Daniel Kulp
>
>
> Cyrille has submitted several patches to various management and logging
> related things for CXF starting way back in February. I think he's up to
> 7
> or 8 submitted patches.He's also been hanging around the user list for
> almost a year ans
Folks,
I'm going to declare this vote as passed, with the following votes cast:
+1 (binding): Sergey Beryozkin, David Bosschaert, Sean O'Callaghan, Ulhas
Bhole, Eoghan Glynn
+1 (non binding): Andres Olarte
I've promoted the artifacts to central and will copy the distributions t
Folks,
I'm calling a vote to release CXF Distributed OSGi 1.1.
The dOSGi subproject of CXF provides the Reference Implementation of the
Remote Services Specification version 1.0, Chapter 13 in the OSGi Compendium
Specification [1].
The release notes contain a description of new features and issu
+1
/Eoghan
2009/11/15 Daniel Kulp
>
> This is a vote to release CXF 2.1.8
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.7 release. Over 25 JIRA issues
> are resolved for 2.1.8
>
>
> List of issues:
>
> https://issues.apache.org
+1
2009/11/15 Daniel Kulp
>
> This is a vote to release CXF 2.2.5
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.4 release. Over 90 JIRA issues
> are resolved for 2.2.5
>
>
> List of issues:
>
> The Maven staging area is at:
> ht
+1
/Eoghan
2009/10/8 Daniel Kulp
>
> 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
+1
/Eoghan
2009/10/8 Daniel Kulp
>
> This is a vote to release CXF 2.2.4
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.3 release. Over 59 JIRA issues
> are resolved for 2.2.4.
>
>
> List of issues:
> https://issues.apache.org/j
Thanks for the patch, Dan. Your efforts are much appreciated.
I've committed the fix just now in r809738.
Cheers,
Eoghan
2009/8/27 Daniel Kulp
>
> Please file a JIRA and submit the changes as a patch. This is excellent!
>
> https://issues.apache.org/jira/browse/CXF
>
>
> Dan
>
> On Thu Augus
+1
/Eoghan
2009/7/29 Daniel Kulp :
>
> his is a vote to release CXF 2.2.3
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.2 release. Over 86 JIRA issues
> are resolved for 2.2.3.
>
>
> List of issues:
> https://issues.apache.org/ji
+1
/Eoghan
2009/7/29 Daniel Kulp :
>
>
> This is a vote to release CXF 2.1.6
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.5 release. Over 74 JIRA issues
> are resolved for 2.1.6
>
>
> List of issues:
>
> The Maven staging area i
+1
/Eoghan
2009/7/29 Daniel Kulp :
>
> This is a vote to release CXF 2.0.12
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.0.11 release. Over 32 JIRA issues
> are resolved for 2.0.12
>
> *Note:* as announced earlier this will be th
Note that in order for any CXF MBean to actually be exposed, you'll
have to enable the IntrumentationManager (which is disabled by
default).
See [1] for details.
Cheers,
Eoghan
[1] http://cwiki.apache.org/CXF20DOC/jmx-management.html
2009/7/21 Rao, Sameer V :
> CXF Asynch processing creates a
S spec", do you mean in
2.3? I haven't heard that JAX-WS 2.2 will address this.
Cheers,
Eoghan
2009/6/18 Richard Opalka
> Hi Eoghan,
>
> see in lined comments below:
>
> Richard
>
> Eoghan Glynn wrote:
>
>> Hi Richard,
>>
>> Apologies for th
Hi Richard,
Apologies for the delay in replying. Please see my comments in-line.
2009/6/15 Richard Opalka :
> what's the current state of CXF WS-RM?
See below.
> I'm asking because we'd like to integrate probably
> WS-RM in our JBossWS CXF integration.
Great that you're thinking of using CXF
One thing I've had at the back of my mind is WS-RM 1.1 support.
Is that something that would be of interest to you?
Cheers,
Eoghan
2009/6/12 Richard Opalka :
> Hi CXF Team,
>
> what's the current CXF roadmap from WS-* point of view?
> What specs are you going to work on next and what is the sch
2009/6/12 David Bosschaert :
>
> 2009/6/11 Sergey Beryozkin :
> ...
>> The only question I have is where this model info should reside, in
>> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
>
> We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents
> files, so maybe somewhere in t
+1
/Eoghan
2009/6/8 Daniel Kulp :
>
> Alessio has been one of the primary driving forces behind getting CXF to be a
> certified JAX-WS provider for JBoss. As part of that work, he has identified
> several bugs/issues in CXF and has provided patches for many of them. He has
> also been helping
+1
/Eoghan
2009/5/22 Daniel Kulp :
>
> This is a vote to release CXF 2.2.2
>
> With only 23 JIRA's resolved for 2.2.2, this doesn't have as many "fixes" as
> many of the previous patch releases. HOWEVER, there is a one major new
> feature: the JAX-RS 1.0 TCK now passes. Thus, it's worth a r
Sorry that should be 7 aye-sayers:
eglynn, davidb, sberyozkin, seanoc, ubhole, dkulp, jgenender
-Original Message-
From: Eoghan Glynn [mailto:eogl...@gmail.com]
Sent: Wed 13/05/2009 17:44
To: dev@cxf.apache.org
Subject: [VOTE][RESULT] Release CXF dOSGi 1.0
Hi Folks,
I'm goi
The Apache CXF dOSGi team is proud to announce the availability of our
first full release, 1.0.
The dOSGi subproject of CXF provides the Reference Implementation of
the Distribution Software (DSW) component of the Distributed OSGi
Specification[1].
Download information may be found here[2]
The b
Hi Folks,
I'm going to call this result as carried with six +1s and no dissenting votes.
For the record, the aye-sayers were:
eglynn, davidb, sberyozkin, ubhole, dkulp, jgenender
Cheers,
Eoghan
2009/5/7 Daniel Kulp :
>
> Eoghan,
>
> Could the version be passed into the xslt via an xslt param? That would
> avoid needing to modify it as part of the builds and such.
>
> Dan
Yeah, sure it could.
The literal version in the xslt was just a quick'n'dirty fix for a
minor issue in the OSGi co
Folks,
I'm calling a second vote to release CXF Distributed OSGi 1.0.
The main differences between this and the first take are:
- addition of a sources distro
- LICENSE file now contains references to licenses for 3rd party dependencies
- removal of extraneous NOTICEs
- addition of top-l
gt;
> Thanks!
> Dan
>
>
> On Wed May 6 2009 9:10:18 am Eoghan Glynn wrote:
>> 2009/5/5 Daniel Kulp :
>> > OK. That kind of make sense (along with what Eoghan said).
>> >
>> > However, I really think there needs to at least be a "README" in the
s to be respun, let's get that cleaned up.
>> >
>> > 3) For the "distribution" builds, the LICENSE file needs to have at least
>> > the pointers to the LICENSES of the bundled deps appended to it. See
>> > the LICENSE in the cxf distributions.
Sent this earlier to dkulp individually, I meant to reply-all.
-- Forwarded message --
From: Eoghan Glynn
Date: 2009/5/5 10:13
Subject: Re: [VOTE] Release CXF dOSGi 1.0
To: Daniel Kulp
2009/5/4 Daniel Kulp :
> On Mon May 4 2009 5:30:49 pm Eoghan Glynn wrote:
>
>>
Folks,
I'm calling a vote to release CXF Distributed OSGi 1.0.
The dOSGi subproject of CXF provides the Reference Implementation of
the Distribution Software (DSW) component of the Distributed OSGi
Specification[1].
The staging area can be found at:
http://people.apache.org/~eglynn/stage_cxf_
What sort of failure are you seeing?
2009/4/29 cybercxf :
>
> I did but I am not sure if I am using right annotations of Restful services.
> Can you verify that for me by taking a look at the code I had attached in
> my first post.
>
> thanks.
/systest/jaxrs/BookStoreJaxrsJaxws.java
2009/4/29 Eoghan Glynn :
> I'd suspect you've a mismatch between the version of
> cxf-rt-frontend-jaxrs and the cxf-api jars.
>
> The former depends on the Message.REQUEST_URI field, which is defined
> in the latter.
>
> This fie
I'd suspect you've a mismatch between the version of
cxf-rt-frontend-jaxrs and the cxf-api jars.
The former depends on the Message.REQUEST_URI field, which is defined
in the latter.
This field was introduced on 2008-10-21, so you'll need a version of
the API jar from after this date (2.0.10/2.1.4
Hi Benson,
Do you mean using an NIO MappedByteBuffer?
That would be an interesting thing to look at doing.
Obviously limiting it to MTOM attachments sortta simplifies things,
but of course there's also the possibility to go the whole hog and
write a full-blown transport based on shared memory. N
+1
/Eoghan
+1
/Eoghan
+1
/Eoghan
Internally in the CXF stack, usually we need to convert the other way
round, i.e. to populate the SAAJ model if its required for example
when a JAX-WS SOAPHandler is installed. This conversion is the
responsibility of the SAAJ{In|Out}Interceptor[1] classes.
However in your case, rather than doing
2009/4/10 Sergey Beryozkin :
> Would it still make sense to keep the Local Discovery service implementation
> ? For ex to test against multiple Discovery instances ?
I think we definitely need to keep the local discovery service intact
in order to support the static remote-services.xml style of
co
Hi David,
This would be a very welcome addition to the distributed OSGi support in CXF!
So please, fire away and commit what you've done so far.
Thanks,
Eoghan
2009/4/10 David Bosschaert :
> Hi all,
>
> Over the past while I have done some experimentation around a possible
> implementation of t
Hi David,
On the general point, I definitely agree that we need to be thinking about a
1.0 release.
On the specifics ...
> * We need to make sure that all the API's we are using are exactly
> correct with the lasted RFC 119 version, e.g. I think we need to add
> something to the ServicePublicati
+1
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Sun 15/03/2009 18:57
To: dev@cxf.apache.org
Subject: [VOTE] Release Apache CXF 2.2
This is a vote to release CXF 2.2
This release is a major step forward for CXF with several new features
including:
* WS-Securit
Hi Folks,
A quick question, has anyone come across a requirement or interest in any sort
of cometd or Bayeux integration in CXF?
Cheers,
Eoghan
Thanks Dan,
I'll disable this for now and move the Jetty thread pool stuff to a separate
test.
/Eoghan
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Thu 26/02/2009 16:04
To: dev@cxf.apache.org
Cc: egl...@apache.org
Subject: Re: svn commit: r748171 - in
/cxf/tr
+1
/Eoghan
+1
+1
+1
/Eoghan
+1
/Eoghan
Folks,
Are commits to trunk still propagated to 2.0.x-fixes, or is it just 2.1.x-fixes
that's actively maintained now?
Cheers,
Eoghan
The id attribute seems to be visible now on
http://cxf.apache.org/schemas/core.xsd
/Eoghan
-Original Message-
From: David Bosschaert [mailto:david.bosscha...@gmail.com]
Sent: Wed 07/01/2009 14:04
To: dev@cxf.apache.org
Subject: Re: http://cxf.apache.org/schemas/core.xsd out of date
Th
think we take the http client timeout(60s) as an example.
Cheers,
Willem
Eoghan Glynn wrote:
>
> Folks,
>
> Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
>
> For even moderately long-lived requests, this seems *way* too tight to me.
>
> A timeo
Folks,
Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
For even moderately long-lived requests, this seems *way* too tight to me.
A timeout in the ballpark of 2s seems more appropriate for localhost demo-type
situation where you want the user to get rapid feedback if
Yep agreed, makes sense to have a separate distributed OSGi category in JIRA.
Cheers,
Eoghan
-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Thu 11/12/2008 11:27
To: dev@cxf.apache.org
Subject: Would it make sense to add a Distributed-OSGi component to C
Yep agreed, makes sense to have a separate distributed OSGi category in JIRA.
Cheers,
Eoghan
-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Thu 11/12/2008 11:27
To: dev@cxf.apache.org
Subject: Would it make sense to add a Distributed-OSGi component to C
Cheers, Sergey
- Original Message -
From: "Eoghan Glynn" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 26, 2008 1:58 PM
Subject: Problem with cxf-bundle-minimal
Folks,
For some reason the minimal bundle lists org.apache.cxf.tools.wsdlto.core in
its Import- & Exp
Folks,
For some reason the minimal bundle lists org.apache.cxf.tools.wsdlto.core in
its Import- & Export-Package manifest headers, even though the
cxf-tools-wsdlto-* modules are excluded from this bundle.
The net result is an unresolved package error when the minimal bundle is
installed.
Any
e you through this.
For the record, +1 votes were received from:
Ajay Paibir, Benson Margulies, Christian Schneider, Dan Kulp, Eoghan Glynn,
Freeman Fang, Glen Mazza, Guillaume Nodet, Jeff Genender, Jim Ma, Richard Hall,
Sergey Beryozkin, Ulhas Bhole, Willem Jiang
Cheers,
Eoghan
-Ori
Does that make sense to you?
Cheers,
Eoghan
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Fri 14/11/2008 15:26
To: dev@cxf.apache.org
Cc: Eoghan Glynn
Subject: Re: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL
phase?
Actually, I remember why I p
Thanks for the quick response Dan, some comments inline ...
> > Is there any reason why the SOAP CheckFaultInterceptor runs in the
> > POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?
>
> Well, the basic reason is that to check for a fault, it needs to look at the
> first element in the body.
Folks,
Is there any reason why the SOAP CheckFaultInterceptor runs in the
POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?
The net result is handleFault() is never called for a client-side JAX-WS
SOAPHandler, as the CheckFaultInterceptor (which is responbile for determining
if a fault is pres
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
Thanks for these David, I'll do the needful ...
/Eoghan
-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 03/11/2008 04:44
To: dev@cxf.apache.org
Subject: Re: [DOSGi] Spring-DM based demo added to CXF-1879
Hi all,
I've also attached some small improvements
Hi David,
It would be great to have RFC 126 support in Felix as well as Equinox, as
obviously this would remove a barrier to wide adoption of dOSGi.
So I agree, it would be a good move to contribute back the ListenerHook support
from the forked version of Felix that we've put in the CXF sando
+1
/Eoghan
-Original Message-
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent: Sat 18/10/2008 11:19
To: dev@cxf.apache.org
Subject: [VOTE] Release Apache CXF 2.1.3 (2nd try)
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1.2 r
Thanks David for this summary!
> There is a lot of work that still needs to be done:
> ...
> - We need better documentation.
On the subject of docco for dOSGi, I wrote up a quick "getting started" guide a
while back. It would need a bit of updating as it dates from before the
donation of the
tests. Would appreciate if they could be applied too.
Cheers,
David
2008/10/16 Eoghan Glynn <[EMAIL PROTECTED]>:
>
> Thanks David, applied.
> Cheers,
> Eoghan
>
> -Original Message-
> From: David Bosschaert [mailto:[EMAIL PROTECTED]
> Sent: Thu 16/10/2008 12:03
Thanks David, applied.
Cheers,
Eoghan
-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Thu 16/10/2008 12:03
To: dev@cxf.apache.org
Subject: [DOSGi] Patch for CXF-1876
Hi all,
I've attached a patch to https://issues.apache.org/jira/browse/CXF-1876
Would greatly
+1
Willem Jiang wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a vote to release CXF 2.0.9
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.0.9 release. Over 37 JIRA issues
are resolved for 2.0.9 which is a large number
Thanks David, patch applied.
David Bosschaert wrote:
Hi all,
I've attached a patch to https://issues.apache.org/jira/browse/CXF-1854
which contains the beginning of a distribution of the DOSGi stuff. The
distribution contains all the required dependencies (OSGi bundles) is
built as part of
this works.
Cheers,
David
Eoghan Glynn wrote:
Did you do the moves as a single step, or more like moving a to c via:
mv a b
mv b c
David Bosschaert wrote:
Yeah, I moved intent-map.xml from META-INF/osgi into a new directory
called OSGI-INF/cxf/intents in a few places. I also mov
/remote-services in a
few places...
FYI I created the patch using Tortoise 1.5.0 on Windows...
Cheers,
David
Eoghan Glynn wrote:
Thanks David,
However svn-apply got a bit confused when I tried to apply the patch.
Did you create some new elements in your working copy and then move
them a
Thanks David,
However svn-apply got a bit confused when I tried to apply the patch.
Did you create some new elements in your working copy and then move them
a different directory?
For example, svn-apply complains that the patch attempts to delete the
non-existent:
dsw/cxf-dsw/src/main/res
Thanks David, patch applied.
/Eoghan
David Bosschaert wrote:
Hi all,
I've attached another patch to
https://issues.apache.org/jira/browse/CXF-1836 that implements the
required Service Properties on the DistributionProvider service. The
patch is called DistributionProvider-properties.patch
Daniel Kulp wrote:
- ensuring the multiplicity of conduit beans configured alongside a
failover selector is consistent with the set of ports defined in the
WSDL, as the CXF static failover strategy is based on burning the
alternate ports into a multi-port service definition in the WSDL.
Well,
Hi Dan,
Dan Diephouse made a similar proposal about 18 months ago, and I was
opposed at the time as it didn't accomodate what was trying to acheive
with ConduitSelectors.
That discussion was also conflated with a bunch of other proposed
changes, but in retrospect I think the bean had the
Thanks for the patch David, now applied.
/Eoghan
David Bosschaert wrote:
Hi all,
I attached a further patch for CXF-1811 to this bug:
https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch
The patch is called 'property_rename2.patch'. A direct link to the
patch:
1 - 100 of 128 matches
Mail list logo
