Re: [VOTE] Release Apache CXF 2.0.11
+1 -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.0.11 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.10 release. Over 36 JIRA issues are resolved for 2.0.11. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313634&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.11 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.11 Here is my +1. The vote will be open here for at least 72 hours.
Re: [VOTE] Release CXF 2.1.5
+1 -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.1.5 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.4 release. Over 87 JIRA issues are resolved for 2.1.5. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313635&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.5 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.5 Here is my +1. The vote will be open here for at least 72 hours.
Re: [VOTE] Release CXF 2.2.1
+1 -- Ulhas Daniel Kulp wrote: his is a vote to release CXF 2.2.1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.2 release. Over 55 JIRA issues are resolved for 2.2.1. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313720&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.2.1 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.1 Here is my +1. The vote will be open here for at least 72 hours.
Re: Writing my own transport
Hi Bharat,
Looks like you are trying to use client side to act as server so what
you need is creating a Destination (similar to what you have done at
server side for the response)
-- Ulhas
Bharath Gargesh wrote:
Hi Dan,
I wanted to write my own transport, but then I saw your reply to this thread
and found out a way to do this.
But only that I was able to go half way through.
On the Server side I did the following:
1.) Develop a JAX-WS and publish it to a local address.
2.) Got a handle to the LocalConduit through the Default Bus
3.) Registered a Listener to the Conduit.
4.) Prepare a SOAP Message for calling the JAX-WS, publish it
to the Conduit.close() and the reply SOAP Message from the JAX-WS
was got in the Listener.
This is absolutely fine, the only thing that I need to do is, construct a
SOAP Message to invoke the JAX-WS.
But I want to use the JAX-WS Client generated to be able to publish the
message to the Local transport.
How can I force/use the JAX-WS client to put the message into the Local
transport ?
Can you please give me an Idea on how to do this for the JAX-WS client too.
Regards
Bharath
dkulp wrote:
Marcel,
You can actually use the Local transport for this as well. We have
several tests that do this exact thing.
We have a TestUtilities class:
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/test/TestUtilities.java
Look in the "invokeBytes" message which could show you how to invoke a
"local" service using raw data. The invokeBytes takes a string
message in and returns a byte[], but it would be very easy to replace
that with streams or a DOM or something similar.
Dan
On May 26, 2008, at 8:09 AM, Heemskerk, Marcel (M.) wrote:
Hello Dan and CXF,
I've been looking in the documentation and still it's quite fuzy for
me.
What i need is the following:
We work WSDL first, so i have to stick to a certain XML format. From
this i generate an HTTP service implementation. It contains (for
example) the following pojo:
package com.sample;
import javax.jws.WebService;
@WebService(endpointInterface = "com.sample.WSInterface",
targetNamespace = "http://com.sample/Calculator";)
public class Calculator {
public CalculatorResult calculate(CalculatorQuestion q) {
return new CalculatorResult(q);
}
}
This is deployed as web service:
http://com.sample/Calculator"/>
What i want to do, is call the service through the JVM (thus NOT
through
HTTP), with plain SOAP XML as input and plain XML as output, including
custom SOAP Headers, WS-Security headers, and what not.
If i use local transport i am stuck with the "Java interface" with
CalculatorQuestion and CalculatorResult.
Which are the absolute minimum classes i need to implement?
Thanks a lot for your info!
- Marcel
-Oorspronkelijk bericht-
Van: Daniel Kulp [mailto:dk...@apache.org]
Verzonden: woensdag 7 mei 2008 6:09
Aan: dev@cxf.apache.org
Onderwerp: Re: Writing my own transport
Depending on what you need to do, you may not need all of the below
classes.
For example, the CachedXXXputStream stuff may not be necessary
depending on your protocol and current stream implementations.
Actually, in most cases, you DON'T want to use that. Instead, use a
subclass of the AbstractWrappedOutputStream or your own stuff.
The TransportFactory is technically not required either. It depends
on what you need to do.
If you only need to write a client to talk to an existing service, you
need a Conduit and a ConduitInitiator.
Likewise, if you need to write a server only, you just need a
Destination and DestinationFactory. The TransportFactory is
basically a convienience if you need both as it can be the
ConduitInitiator and the DestinationFactory in on.
Most of the "Logic" occurs in the Conduit/Destination objects.
Generally, the Conduit.prepare adds an OutputStream to the method that
does a couple things:
1) On the first write, it will do whatever header processing stuff is
needed. For HTTP, it sets the HTTP headers.
2) On the close, it can do one of:
a) wait for the response and call the listener directly. The
http conduit does this. It's generally the faster way to do it in
most cases.
b) Just send the message if there is some other asyncronous way
that the response will come in and have the message listener called.
The local transport does this.
The AbstractWrappedOutputStream makes some of the above easier by
providing callbacks for those events, but it can be any stream.
Dan
On May 6, 2008, at 9:24 PM, Freeman Fang wrote:
Hi Marcel,
Assume the transport you want to i
Re: [VOTE] Release CXF dOSGi 1.0 (take 2)
+1, --Ulhas Eoghan Glynn wrote: 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-level READMEs - fix for algorithm used to compute DiscoveredServiceTracker property deltas - fix for name clash on some osgi.remote.* properties The distributions are staged at: http://people.apache.org/~eglynn/stage_cxf_dosgi/dist and the maven artifacts at: http://people.apache.org/~eglynn/stage_cxf_dosgi/maven This release is tagged with cxf-dosgi-ri-1.0 at: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 The vote will remain open for at least 72 hours. Please consider this call to vote as my +1. Cheers, Eoghan
Re: [VOTE] Release CXF 2.2.2
+1, -- Ulhas Daniel Kulp wrote: 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 release. :-) List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313901&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.2.2 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.2 I'm going to leave the vote open till at least Wednesday due to the long holiday weekend in the US and also due to me being on "vacation" next week so I'm not sure when I'll have time to close the vote and push the release.
Re: [RESULT] [VOTE] Release CXF 2.2.2
I think I also casted my +1 but don't see in the list. -- Ulhas Daniel Kulp wrote: We have +1 votes from: dkulp, bganesh, sberyozkin, willemjiang, davidb, seanoc, eglynn, ffang, schneider. and no other votes.Thus, this vote passes. I'll start getting the stuff synced to central and the dist dir. Dan On Fri May 22 2009 1:50:39 pm Daniel Kulp wrote: 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 release. :-) List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313901&sty leName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.2.2 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.2 I'm going to leave the vote open till at least Wednesday due to the long holiday weekend in the US and also due to me being on "vacation" next week so I'm not sure when I'll have time to close the vote and push the release.
Re: [VOTE] Alessio Soldano for committer
+1, -- Ulhas Daniel Kulp wrote: 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 in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1.
Re: [VOTE] Release CXF dOSGi 1.1
+1, -- Ulhas Bhole Eoghan Glynn wrote: 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 issues fixed in this release: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/release_notes.txt The staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-021 The various distributions can be downloaded as follows: - *Source:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1 - *Multi-bundle:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1 - *Single-bundle:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1 This release is tagged with cxf-dosgi-ri-1.1 at: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1 The vote will remain open for at least 72 hours. Please consider this call to vote as my +1. Cheers, Eoghan [1] http://www.osgi.org/Download/Release4V42
Re: [VOTE] Cyrille Le Clerc for committer....
+1, -- Ulhas Bhole Daniel Kulp wrote: 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 answering some questions.Thus, I think he's a bit over due to become a committer. Here is my +1. Vote will be open for at least 72 hours.
Re: [VOTE] Release CXF 2.1.9
+1, --ulhas Daniel Kulp wrote: 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 the last 2.1.x release of Apache CXF. Users are encouraged to start migrating to 2.2.x. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314380&styleName=Html&projectId=12310511&Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-056/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-056/org/apache/cxf/apache-cxf/2.1.9 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.9 The vote will be open for 72 hours. Here is my +1.
Re: [VOTE] Release CXF 2.2.6
+1, -- Ulhas 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 issues are resolved for 2.2.6. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314381&styleName=Html&projectId=12310511&Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-057/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-057/org/apache/cxf/apache-cxf/2.2.6 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.6 The vote will be open for 72 hours. Here is my +1.
Re: [VOTE] David Valeri for committer
+1, -- Ulhas Bhole On 10 Mar 2010, at 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 very complete with excellent unit tests and such.The WS- Security stuff is a very complex area of code and he's doing a great job picking it up and fixing issues in it. Here's my +1. Vote will be open for at least 72 hours. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
JMX enabling in CXF 2.2.6
Hi, I am trying to enable JMX instrumentation in CXF 2.2.6 sample (wsdl_first_rpclit) but when I try to connect to server using JConsole I don't see any CXF MBeans. Do I need to do anything in addition to configuring Instrumentation manager? Here is my cxf.xml that I am using to enable instrumentation. I am not updating any implementation to collect endpoint statistics just want to see cxf stats first like Bus. http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:jaxws="http://cxf.apache.org/jaxws"; xmlns:cxf="http://cxf.apache.org/core"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> Regards, Ulhas Bhole
Re: [VOTE] Release CXF 2.2.7
+1, -- Ulhas Bhole On Fri, Mar 19, 2010 at 1:21 AM, 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/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > The distributions are in: > > https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 > > > The vote will be open for 72 hours. > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: JMX enabling in CXF 2.2.6
Thanks Eoghan for quick reply. I will try to update build.xml target and
check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit
directory and I think it was picked up because when I ran client it did got
AddressAlreadyInUse 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,
>
> 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:
>
>
>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
>
>
> to:
>
>
>jvmarg1="-Dcxf.config.file=cxf.xml"
>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
>
>
> Alternatively, you could change the
> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java to
> use the SpringBusFactory to explicit identify the config file when creating
> the Bus.
>
> But obviously you must make the connection to the config in *some* way,
> otherwise the intrumentation config will have no effect. BTW I just
> confirmed that the CXF MBeans appear as expected with this demo using your
> config file and the first approach described.
>
> Cheers,
> Eoghan
>
>
> On 18 March 2010 17:24, Ulhas Bhole wrote:
>
> > Hi,
> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample
> > (wsdl_first_rpclit) but when I try to connect to server using JConsole I
> > don't see any CXF MBeans. Do I need to do anything in addition to
> > configuring Instrumentation manager?
> >
> > Here is my cxf.xml that I am using to enable instrumentation. I am not
> > updating any implementation to collect endpoint statistics just want to
> see
> > cxf stats first like Bus.
> >
> > http://www.springframework.org/schema/beans";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xmlns:jaxws="http://cxf.apache.org/jaxws";
> > xmlns:cxf="http://cxf.apache.org/core";
> >
> > xsi:schemaLocation="
> > http://www.springframework.org/schema/beans
> > http://www.springframework.org/schema/beans/spring-beans.xsd
> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
> >
> >
> > > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
> >
> >
> >
> >
> > > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
> >
> >
> >
> >
> > > class="org.apache.cxf.management.counters.CounterRepository">
> >
> >
> >
> >
> >
> > Regards,
> >
> > Ulhas Bhole
> >
>
Re: JMX enabling in CXF 2.2.6
Hi Eoghan,
I did a few tests and it looks like if I try to connect to the process from
JConsole it doesn't show CXF JMX stats. If I create a new connection using
JMX URL and username/password (cxf/cxf) I do see the CXF MBean appearing.
Thanks for the help.
Regards,
Ulhas Bhole
I just did a few tests
I just tried it on 2 different machines (Linux and Mac) using JDK 1.5
On Fri, Mar 19, 2010 at 10:05 AM, Ulhas Bhole wrote:
> Thanks Eoghan for quick reply. I will try to update build.xml target and
> check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit
> directory and I think it was picked up because when I ran client it did got
> AddressAlreadyInUse 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,
>>
>> 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:
>>
>>
>>>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
>>
>>
>> to:
>>
>>
>>>jvmarg1="-Dcxf.config.file=cxf.xml"
>>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
>>
>>
>> Alternatively, you could change the
>> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java
>> to
>> use the SpringBusFactory to explicit identify the config file when
>> creating
>> the Bus.
>>
>> But obviously you must make the connection to the config in *some* way,
>> otherwise the intrumentation config will have no effect. BTW I just
>> confirmed that the CXF MBeans appear as expected with this demo using your
>> config file and the first approach described.
>>
>> Cheers,
>> Eoghan
>>
>>
>> On 18 March 2010 17:24, Ulhas Bhole wrote:
>>
>> > Hi,
>> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample
>> > (wsdl_first_rpclit) but when I try to connect to server using JConsole I
>> > don't see any CXF MBeans. Do I need to do anything in addition to
>> > configuring Instrumentation manager?
>> >
>> > Here is my cxf.xml that I am using to enable instrumentation. I am not
>> > updating any implementation to collect endpoint statistics just want to
>> see
>> > cxf stats first like Bus.
>> >
>> > http://www.springframework.org/schema/beans";
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> > xmlns:jaxws="http://cxf.apache.org/jaxws";
>> > xmlns:cxf="http://cxf.apache.org/core";
>> >
>> > xsi:schemaLocation="
>> > http://www.springframework.org/schema/beans
>> > http://www.springframework.org/schema/beans/spring-beans.xsd
>> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
>> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
>> >
>> >
>> > > > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>> >
>> >
>> >
>> >
>> > > > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>> >
>> >
>> >
>> >
>> >> > class="org.apache.cxf.management.counters.CounterRepository">
>> >
>> >
>> >
>> >
>> >
>> > Regards,
>> >
>> > Ulhas Bhole
>> >
>>
>
>
Re: JMX enabling in CXF 2.2.6
Thanks Eoghan,
I will try it out.
Regards,
Ulhas Bhole.
On Fri, Mar 19, 2010 at 11:34 AM, Eoghan Glynn wrote:
> A-ha, my bad, I assumed you were using the remote process option ... so you
> just can't see the CXF MBeans when you connect via the jconsole local
> process option?
>
> That's easy, just ensure your injected InstrumentationManager bean picks up
> the *platform* MBeanServer as opposed to creating a fresh one. Its the
> platform MBeanServer that the local process option will go for by default.
>
> Simply modify your config as follows to set the usePlatformMBeanServer
> property:
>
> class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>
>
>
>
>
> value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>
> BTW in the remote case, you don't even need to specify the cxf/cxf as
> remote
> user/pass as this is not authenticated (unlike SMX/karaf).
>
> /Eoghan
>
> On 19 March 2010 10:29, Ulhas Bhole wrote:
>
> > Hi Eoghan,
> >
> > I did a few tests and it looks like if I try to connect to the process
> from
> > JConsole it doesn't show CXF JMX stats. If I create a new connection
> using
> > JMX URL and username/password (cxf/cxf) I do see the CXF MBean appearing.
> >
> > Thanks for the help.
> >
> > Regards,
> >
> > Ulhas Bhole
> >
> > I just did a few tests
> >
> > I just tried it on 2 different machines (Linux and Mac) using JDK 1.5
> > On Fri, Mar 19, 2010 at 10:05 AM, Ulhas Bhole
> > wrote:
> >
> > > Thanks Eoghan for quick reply. I will try to update build.xml target
> and
> > > check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit
> > > directory and I think it was picked up because when I ran client it did
> > got
> > > AddressAlreadyInUse 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,
> > >>
> > >> 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:
> > >>
> > >> depends="build">
> > >> > >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
> > >>
> > >>
> > >> to:
> > >>
> > >> depends="build">
> > >> > >>jvmarg1="-Dcxf.config.file=cxf.xml"
> > >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
> > >>
> > >>
> > >> Alternatively, you could change the
> > >>
> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java
> > >> to
> > >> use the SpringBusFactory to explicit identify the config file when
> > >> creating
> > >> the Bus.
> > >>
> > >> But obviously you must make the connection to the config in *some*
> way,
> > >> otherwise the intrumentation config will have no effect. BTW I just
> > >> confirmed that the CXF MBeans appear as expected with this demo using
> > your
> > >> config file and the first approach described.
> > >>
> > >> Cheers,
> > >> Eoghan
> > >>
> > >>
> > >> On 18 March 2010 17:24, Ulhas Bhole wrote:
> > >>
> > >> > Hi,
> > >> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample
> > >> > (wsdl_first_rpclit) but when I try to connect to server using
> JConsole
> > I
> > >> > don't see any CXF MBeans. Do I need to do anything in addition to
> > >> > configuring Instrumentation manager?
> > >> >
> > >> > Here is my cxf.xml that I am using to enable instrumentation. I am
> not
> > >> > updating any implementation to collect endpoint statistics just want
> > to
> > >> see
> > >> > cxf stats first like Bus.
> > >> >
> > >> > http://www.springframework.org/schema/beans";
> > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > >> > xmlns:jaxws="http://cxf.apache.org/jaxws";
> > >> > xmlns:cxf="http://cxf.apache.org/core";
> > >> >
> > >> > xsi:schemaLocation="
> > >> > http://www.springframework.org/schema/beans
> > >> > http://www.springframework.org/schema/beans/spring-beans.xsd
> > >> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> > >> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> ">
> > >> >
> > >> >
> > >> > > >> > class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > > >> > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > > >> > class="org.apache.cxf.management.counters.CounterRepository">
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Regards,
> > >> >
> > >> > Ulhas Bhole
> > >> >
> > >>
> > >
> > >
> >
>
Re: [VOTE] Apache CXF 2.5.1/2.4.5/2.3.8
+1, -- Ulhas Bhole On Thu, Dec 15, 2011 at 8:37 PM, Daniel Kulp wrote: > > > We've resolved over 75 issues since 2.5.0 and thus is time for a release. > We've also ported back over 40 of the fixes to 2.4.5 and 30 of those to > 2.3.8. > > List of issues: > 2.3.8: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12318348 > 2.4.5: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12318894 > 2.5.1: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=1231 > > > The Maven staging areas are at: > 2.3.8: > https://repository.apache.org/content/repositories/orgapachecxf-327/ > 2.4.5: > https://repository.apache.org/content/repositories/orgapachecxf-328/ > 2.5.1: > https://repository.apache.org/content/repositories/orgapachecxf-345/ > > > The distributions are in the org/apache/cxf/apache-cxf/ directory of the > Maven > staging areas. > > > This releases are tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.8 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.5 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.1 > > > This vote will be open for at least 72 hours. > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
Re: [VOTE] Apache CXF 2.7.8/2.6.11
+1, Ulhas Bhole On Wed, Nov 20, 2013 at 4:20 PM, Daniel Kulp wrote: > > We've resolved over 75 issues since 2.7.7 and almost 35 ported back to > 2.6.11. > > > List of issues: > 2.6.11 > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12325006 > 2.7.8 > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12325005 > > The Maven staging areas are at: > 2.6.11 > https://repository.apache.org/content/repositories/orgapachecxf-155/ > 2.7.8 > https://repository.apache.org/content/repositories/orgapachecxf-158/ > > The distributions are in the org/apache/cxf/apache-cxf/ directory of the > Maven staging areas. > > > This releases are tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.11 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.8 > > This vote will be open for at least 72 hours. > > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
Re: [VOTE] Apache CXF 3.0.0-milestone1
+1, -- Ulhas Bhole On Wed, Nov 20, 2013 at 9:28 PM, Daniel Kulp wrote: > > We’ve done quite a lot of work toward 3.0.0. While we still have work to > do, I think it’s a good idea to get a stable milestone release out that > users can depend on to start testing some of the new stuff and provide > feedback about some of the changes. I didn’t really want to call it an > alpha (implies to much of a level of instability) or beta/rc (implies too > close to actual release, I do expect some more API changes), so I just went > with a “milestone1” name. > > Anyway, I’ve started trying to accumulate information about 3.0.0 > migrations at: > http://cxf.apache.org/docs/30-migration-guide.html > to give you a better idea about what’s there. > > This also includes a new release of the xic-utils to have the new javadoc > plugin. > > > Tags: > http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.7.0/ > http://svn.apache.org/repos/asf/cxf/tags/cxf-3.0.0-milestone1/ > > Staging repos: > https://repository.apache.org/content/repositories/orgapachecxf-160/ > https://repository.apache.org/content/repositories/orgapachecxf-161/ > > > Here is my +1. Vote open till Monday. > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
Re: [VOTE] 3.0.0-milestone1 distributions...
+1, --Ulhas Bhole On Thu, Nov 28, 2013 at 12:59 AM, Freeman Fang wrote: > +1 > － > Freeman(Yue) Fang > > Red Hat, Inc. > FuseSource is now part of Red Hat > > > > On 2013-11-27, at 上午1:26, Daniel Kulp wrote: > > > > > This is a vote for the actually distributions to go along with the > 3.0.0-milestone1 release that is already in central. > > > > Staging area: > > https://repository.apache.org/content/repositories/orgapachecxf-008/ > > > > Now already part of the 3.0.0-milestone1 tag: > > > https://svn.apache.org/repos/asf/cxf/tags/cxf-3.0.0-milestone1/distribution > > > > > > Here is my +1 > > > > > > -- > > Daniel Kulp > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > >
Re: [VOTE] Apache CXF 2.7.10
+1, -- Ulhas Bhole On Wed, Feb 5, 2014 at 1:53 PM, Aki Yoshida wrote: > +1 > > Aki > > 2014-02-05 Daniel Kulp : > > > > This is a vote to release 2.7.10. This is mostly to fix the JAX-WS 2.2 > problems in the 2.7.9 release that would not allow it to work as a 2.2 > runtime. Also has a couple other minor fixes. > > > > > > Staging area: > > https://repository.apache.org/content/repositories/orgapachecxf-1007/ > > > > Tag: > > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.10 > > > > This vote will be open for at least 72 hours. > > > > -- > > Daniel Kulp > > dk...@apache.org - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > >
Re: [VOTE] CXF 3.1.1
+1, --Ulhas Bhole On 6 Jun 2015 02:19, "Daniel Kulp" wrote: > 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 > >
Re: [VOTE] Release CXF 2.1
+1 --Ulhas Bhole Daniel Kulp wrote: This is a vote to release CXF 2.1. Obviously, this is a pretty big release with a bunch of new things like JAX-WS 2.1 support, the JAX-RS stuff, the javascripts stuff, the CORBA binding from yoko, etc Of course, the other MAJOR new feature: it's no longer labeled "incubator"! The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the maven repository. (the REAL maven repository, not the incubating one this time!!!) This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1/ Here is my +1. The vote will be open here for at least 72 hours. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.0.6
+1, -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.0.6 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.5 release. Over 20 JIRA issues are marked as resolved for 2.0.6. Of course, the other MAJOR new feature: it's no longer labeled "incubator"! The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.6 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.6 Here is my +1. The vote will be open here for at least 72 hours. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.1 (take 2)
+1, -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.1. Obviously, this is a pretty big release with a bunch of new things like JAX-WS 2.1 support, the JAX-RS stuff, the javascripts stuff, the CORBA binding from yoko, etc Of course, the other MAJOR new feature: it's no longer labeled "incubator"! The changes between this and the first take are: 1) Fixed version (removed beta) in release notes 2) Fixed urls in poms to new location (since the new site is now live) 3) Moved one of the obscure schemas (object.xsd) into /schemas so it will match the others and be "live" with the others. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1-take2 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the maven repository. (the REAL maven repository, not the incubating one this time!!!) This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1/ Here is my +1. The vote will be open here for at least 72 hours. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.0.7
+1 --Ulhas Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.7 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.7 release. Over 48 JIRA issues are resolved for 2.0.7 which is a large number of fixes for the 2.0.x branch. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.7 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv Px3oDUHzRTC53LDAs2yxIz8= =fif0 -END PGP SIGNATURE- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.1.1
+1 --Ulhas Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.1.1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1 release. Over 74 JIRA issues are resolved for 2.1.1 which is a large number of fixes. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.1 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.1 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV80oq8juObtVB0YRAiLyAJ9+HiWq61I9JZ01kRpr4g+L1O7woQCcCHbK G1xxwnA5MSe77DORVGTRy3o= =cx57 -END PGP SIGNATURE- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Is cxf 2.0.x branch broken?
Hi, Is CXF 2.0.x branch broken currently? I am seeing compilation failure in simple-frontend as follows. /local1/work/cxf/apache/2.x/rt/frontend/simple/src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java:[84,22] cannot find symbol symbol : method setFeatures(java.util.List) location: class org.apache.cxf.service.factory.ReflectionServiceFactoryBean /local1/work/cxf/apache/2.x/rt/frontend/simple/src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java:[84,22] cannot find symbol symbol : method setFeatures(java.util.List) location: class org.apache.cxf.service.factory.ReflectionServiceFactoryBean Regards, Ulhas Bhole IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.0.8
+1 -- Ulhas Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.8 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.8 release. Over 28 JIRA issues are resolved for 2.0.8. Most importantly, this contains a critical fix that was preventing Geronimo from being able to upgrade to our recent releases. They need this so they can release Geronimo 2.1.2 which they would like to do next week. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313269&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.8 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.8 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIhos1q8juObtVB0YRAu+GAJ9wlLmUL603COMNIv52xwvB2+XMgACaA8K2 0OImzd5F9+EtcKeWx+Rf7i0= =kqY9 -END PGP SIGNATURE- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Can't edit some confluence pages
Hi Dan, I also had the same problem. I don't see the edit button anywhere even if I am logged on. Regards, Ulhas Bhole Daniel Kulp wrote: On Sunday 10 August 2008 2:57:45 pm Benson Margulies wrote: For some reason, http://cwiki.apache.org/confluence/display/CXF/Buildingdoesn't show me an edit button. Other pages do. Hmm The permissions on the two spaces (CXF and CXF20DOCS) are set exactly the same. Thus, that shouldn't be the issue. However, the "theme" is different. The main CXF space is set to the Left Navigation theme so that it looks exactly the same in the wiki as when generated for the site. However, that theme moves the "edit" button to the bottom of the Left navigation stuff within the "Page Operations" button. Can you check if that button is there and see if the "Edit" link is in there? IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release Apache CXF 2.1.2
+1, --Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.1.2 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.1 release. Over 67 JIRA issues are resolved for 2.1.2. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313268&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.2 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.2 Here is my +1. The vote will be open here for at least 72 hours. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Bug in handling JMS TextMessage encoding (see CXF-1668)?
Hi Christian, The place Eduard mentioned in Jira is correct. I was looking at this JIRA sometime back but had the same problem of how to determine encoding type. JMS TextMessage doesn't contain any encoding information so it's hard to know what is the encoding of the contents. Regards, Ulhas Bhole Christian Schneider wrote: In the issue CXF-1668 Eduard reported that CXF uses the system encoding for JMS Messages. This is wrong as most times messages are to be transmitted using UTF-8. I want to build a patch for this issue but need some conceptional help. When we receive a message from JMS how can we decide which encoding it uses? Should I try to use the tag? Where is a good point to add this functionality? Should I add it in handleResponse like Eduard suggested? Best regards Christian https://issues.apache.org/jira/browse/CXF-1668 IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Bug in handling JMS TextMessage encoding (see CXF-1668)?
Hi Christian, One option (bit limited though) is to use file.encoding property and if it's set use that for encoding. In this case the application need to pass in -Dfile.encoding property to the JVM. However, this doesn't guarantee the encoding used will always be same as the one that original message was encoded in. Regards, Ulhas Bhole Ulhas Bhole wrote: Hi Christian, The place Eduard mentioned in Jira is correct. I was looking at this JIRA sometime back but had the same problem of how to determine encoding type. JMS TextMessage doesn't contain any encoding information so it's hard to know what is the encoding of the contents. Regards, Ulhas Bhole Christian Schneider wrote: In the issue CXF-1668 Eduard reported that CXF uses the system encoding for JMS Messages. This is wrong as most times messages are to be transmitted using UTF-8. I want to build a patch for this issue but need some conceptional help. When we receive a message from JMS how can we decide which encoding it uses? Should I try to use the tag? Where is a good point to add this functionality? Should I add it in handleResponse like Eduard suggested? Best regards Christian https://issues.apache.org/jira/browse/CXF-1668 IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: mvn -Pfastinstall failure with current trunk
I think this is happening on some unclean/old snaspshot. I also got this
yesterday but after my low level clean alternative (find . -name
"target" | xargs rm -rf) followed by svn update cured the problem and
didn't see it again.
-- Ulhas Bhole
Willem Jiang wrote:
It is OK for me too (Windows, JDK 1.5.0-13)
Which version of JDK are you using ?
Willem
Daniel Kulp wrote:
Seems to be working OK for me. Not sure why it wouldn't be working
for you. :-(
Dan
On Wednesday 13 August 2008 8:43:34 pm Benson Margulies wrote:
[INFO] FastInfosetting 0 resource
[INFO] [jaxb:generate {execution: default}]
[INFO] failure in the XJC task. Use the Ant -verbose switch for more
details [INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] unrecognized parameter -Xdv
[INFO]
[INFO] Trace
unrecognized parameter -Xdv
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:409)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:397)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:332)
at com.sun.tools.xjc.maven2.XJCMojo.execute(XJCMojo.java:310)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag
er.java:443) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
ecycleExecutor.java:539) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl
e(DefaultLifecycleExecutor.java:480) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife
cycleExecutor.java:459) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai
lures(DefaultLifecycleExecutor.java:311) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def
aultLifecycleExecutor.java:278) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycl
eExecutor.java:143) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: com.sun.tools.xjc.BadCommandLineException: unrecognized
parameter -Xdv
at com.sun.tools.xjc.Options.parseArguments(Options.java:664)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:407)
... 21 more
--- Nested Exception ---
com.sun.tools.xjc.BadCommandLineException: unrecognized parameter -Xdv
at com.sun.tools.xjc.Options.parseArguments(Options.java:664)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:407)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:397)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:332)
at com.sun.tools.xjc.maven2.XJCMojo.execute(XJCMojo.java:310)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag
er.java:443) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
ecycleExecutor.java:539) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl
e(DefaultLifecycleExecutor.java:480) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife
cycleExecutor.java:459) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai
lures(DefaultLifecycleExecutor.java:311) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def
aultLifecycleExecutor.java:278) at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycl
eExecutor.java:143) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at
org.codehaus.classworlds.Launcher.ma
Re: can we use asyn way for jms transport
Hi Freeman, I was looking at code and here are two main problems that we will need to tackle. 1. By default, we create separate TemporaryQueue for repsonse so we will need receiver per tempqueue waiting on reply. (so that many threds.) 2. to propogate the JMS response headers back we use JAXWS responseContext which I assume is threadlocal so we need to find out how it will react when the response goes on different thread. If we ignore for moment point 2 we will either need to use one TemporaryQueue for all responses if no replyDestination is defined. Also will neeed to have separate pool of listeners for scalability.(I don't know how the JMS callback works so will need to look into it more) Regards, Ulhas Bhole Freeman Fang wrote: Any thoughts? Cheers Freeman Freeman Fang wrote: Hi, Currently we are using sync way for jms transport which means the thread get blocked until response messsage is coming or the client side timeout, see the handleResponse() method of JMSConduit? Is it possible that we use non-block way for JMSConduit, something like implement JMS MessageListener API? Or any special reason we need this sync invocation for JMS conduit? Thanks Freeman IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: can we use asyn way for jms transport
Hi Freeman, As per 2.2 roadmap ideas we want to change/rewrite CXF JMS transport to support SPEC/JMS and use spring JMSTemplates but I guess we need to do it in such a way that we can keep the current one if someone already using it atleast for some time. I didn't got a chance to look at how we can integrate both (SPEC/JMS and spring jmsTemplate together) in CXF JMS transport. I would surely be in favor of the new transport which would be more flexible than the current one. Regards, Ulhas Bhole Freeman Fang wrote: Hi Ulhas, Thanks. How about we introduce Spring JmsTemplate to cxf jms transport, is it helpful? I'm not familar with spring JmsTemplate but I wanna get more ideas about it . Thanks again Freeman Ulhas Bhole wrote: Hi Freeman, I was looking at code and here are two main problems that we will need to tackle. 1. By default, we create separate TemporaryQueue for repsonse so we will need receiver per tempqueue waiting on reply. (so that many threds.) 2. to propogate the JMS response headers back we use JAXWS responseContext which I assume is threadlocal so we need to find out how it will react when the response goes on different thread. If we ignore for moment point 2 we will either need to use one TemporaryQueue for all responses if no replyDestination is defined. Also will neeed to have separate pool of listeners for scalability.(I don't know how the JMS callback works so will need to look into it more) Regards, Ulhas Bhole Freeman Fang wrote: Any thoughts? Cheers Freeman Freeman Fang wrote: Hi, Currently we are using sync way for jms transport which means the thread get blocked until response messsage is coming or the client side timeout, see the handleResponse() method of JMSConduit? Is it possible that we use non-block way for JMSConduit, something like implement JMS MessageListener API? Or any special reason we need this sync invocation for JMS conduit? Thanks Freeman IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Question about JMS Session Pool
Hi Christian, comments inline... -- Ulhas Christian Schneider wrote: Guillaume Nodet schrieb: 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. I think you are right that CXF should not take care of it. But in case the user does not run the application in an appserver he will need a connection pool that he can configure as a wrapper on his ConnectionFactory. I guess the ActiveMQ pooling is not useable for other providers? The Spring CachingConnectionFactory is described here: http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/jms/connection/CachingConnectionFactory.html http://static.springframework.org/spring/docs/2.5.x/reference/jms.html#jms-connections In the second link they detail that for a JMStemplate in a standalone environment the SingleConnectionFactory should be used to avoid opening a connection on every call to the template. Currently the JMSConduit works in the following way. It fetches a PooledSession from the SessionFactory. The PooledSession contains already initialized Session, MessageProducer and MessageConsumer. If the reply queue is temporary each pooled session has a different already created temporary Queue that is reused each time the PooledSession is fetched. Then it sends out a message to the targetDestination and sets the replyDestination from the pooledSession as replyTo. After that it waits synchronously with a consumer on the replyDestination for the reply to come. I think this behaviour is not implemented in any of the Connection Pools I know. So my question here is how would we implement this with a JMSTemplate. Without any further configuration the JMSTemplate even with SingleConnectionFactory would create a new Session, Producer, Temporary Queue and Consumer for each message. I am not sure if this is acceptable. I think we should get away from creating temporary queue each time. I think it is acceptable to have one temp queue serving as replyDestination if no replyDestination is explicitly set. The default behavior CXF states should be like " JMS transport will use temporary queue if no replyDestination is specified" which can be implemented as one temporary queue or pool of temporary queues (with listener for each) or the current way (which is highly discouraged as far as I got the feedback). One idea I have is to Simply create one or more listenerthreads with consumers on the replyDestination. They would then receive the responses completely asynchronous and we could find the right exchange by using the correlationId. One issue with this idea is that we can only have one Thread on a temporary queue as the queue is only visible to the Session that created the queue. (At least I think so). Any ideas for this? Currently, for request/reponse MEP we set JMSMessageID as correlationID so it should not be difficult to implement the correlate response (we can maintain hashmap or some collection which would hold the Request Exchange keyed using JMSMessageID when the message is sent however, I think we will need to look into what will happen to the JAX-WS request and response context which when last I knew were thread local becuse we pump in JMS_REPONSE_HEADERS into it. Best regards Christian IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Christian Schneider for committer
+1 -- Ulhas Daniel Kulp wrote: Christian has been doing quite a bit of very good work doing an almost "ground up" re-write of the JMS transport which is a very challenging and complicated task. He's done quite a bit of work documenting various JMS things on the Wiki and even wrote an article about how to integrate the Camel transport into CXF. He's also been very good about talking about his ideas on the dev list, responding to user queries about the areas he's familiar with, etc... Basically, I think he's already been a valuable asset to the project and has earned a spot as a committer. [ ] +1 [ ] -1 Vote will remain open for at least 72 hours. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release CXF 2.0.9
+1 -- Ulhas 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 of fixes for the 2.0.x branch. List of issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310511&fixfor=12313314 The staging area is at: http://people.apache.org/~ningjiang/stage_cxf/2.0.9 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.0.9 Here is my +1. The vote will be open here for at least 72 hours. Willem -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjvTt8ACgkQI1CSmK6N6eTuWACdFBA+C8R3DzKTWCIinln0sCaC zWAAn04fkhek/PMlgRHwCeevV45CTwN6 =4dc9 -END PGP SIGNATURE- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: [VOTE] Release Apache CXF 2.1.3
+1, -- Ulhas Willem Jiang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.2 release. Over 51 JIRA issues are resolved for 2.1.3. List of issues: https://issues.apache.org/jira/browse/CXF/fixforversion/12313354 The staging area is at: http://people.apache.org/~ningjiang/stage_cxf/2.1.3 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.3 Here is my +1. The vote will be open here for at least 72 hours. Willem -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj3RZMACgkQI1CSmK6N6eQjugCfTRF0/8ITShj5jBWz5AqqTEko kjEAnAjOhm3LVyc2ZJoY8ZA8E1WSo8Jb =bSq2 -END PGP SIGNATURE-
Re: [VOTE] Release Apache CXF 2.1.3 (2nd try)
+1, -- Ulhas Willem Jiang wrote: Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.2 release. Over 52 JIRA issues are resolved for 2.1.3. List of issues: https://issues.apache.org/jira/browse/CXF/fixforversion/12313354 The staging area is at: http://people.apache.org/~ningjiang/stage_cxf/2.1.3 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.3 Here is my +1. The vote will be open here for at least 72 hours. Willem
Re: [VOTE] David Bosschaert for committer
+1, I have worked with David in past and he will surely be an asset to CXF given the knowledge he would bring in on general WS-* stuff and mainly OSGI. -- Ulhas Eoghan Glynn 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
Re: Bug in ReadHeadersInterceptor?
I indeed is worng. Please raise a jira and someone will surely take a
look. (probably me but need to find some time.)
-- Ulhas
Peter Liljenberg wrote:
We tried to use soapheaders by adding a HeaderProcessor. When looking at the
CXF code (2.1.2) we find this:
HeaderProcessor p = bus.getExtension(HeaderManager.class)
.getHeaderProcessor(hel.getNamespaceURI());
Object obj;
DataBinding dataBinding = null;
if (p == null || p.getDataBinding() == null) {
obj = node;
} else {
obj = p.getDataBinding().createReader(Node.class).read(node);
}
//TODO - add the interceptors
SoapHeader shead = new SoapHeader(new
QName(node.getNamespaceURI(),node.getLocalName()), obj, dataBinding);
This looks like a bug to me.
Should the dataBinding that is extraced be used when constructing the
SoapHeader instead of ALWAYS be null. I'm just guessing but shouldn't it
look like this:
} else {
dataBinding = p.getDataBinding();
obj = dataBinding.createReader(Node.class).read(node);
}
This might be fixed in later version already, or there might even exist an
issue for this?
/Peter
Re: [VOTE] Release CXF 2.0.10
+1, -- Ulhas Daniel Kulp wrote: Since it's been about 4 months since the 2.0.9 release, I decided to go ahead and do a 2.0.10 release along with 2.1.4. This is a vote to release CXF 2.0.10 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.10 release. Over 35 JIRA issues are resolved for 2.0.10. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313462&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.10 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.10 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
Re: [VOTE] Release Apache CXF 2.1.4
+1, -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.1.4 With a longer than normal cycle, a LOT of stuff is in this. Over 88 JIRA issues are resolved for 2.1.3 which is quite a bit of work. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313463&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.4 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.4 Here is my +1. The vote will be open here for at least 72 hours.
Re: [VOTE] Release CXF 2.0.10 (Take 2)
+1 -- Ulhas Daniel Kulp wrote: (The issue with the J2EE has been corrected. This is a new vote on the new artifacts) Since it's been about 4 months since the 2.0.9 release, I decided to go ahead and do a 2.0.10 release along with 2.1.4. This is a vote to release CXF 2.0.10 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.10 release. Over 35 JIRA issues are resolved for 2.0.10. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313462&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.10 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.10 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
Re: [VOTE] Release Apache CXF 2.1.4 (Take 2)
+1 --Ulhas Daniel Kulp wrote: (The issue with the J2EE has been corrected. This is a new vote on the new artifacts) This is a vote to release CXF 2.1.4 With a longer than normal cycle, a LOT of stuff is in this. Over 88 JIRA issues are resolved for 2.1.3 which is quite a bit of work. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313463&styleName=Html&projectId=12310511&Create=Create The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.4 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.4 Here is my +1. The vote will be open here for at least 72 hours.
Re: [VOTE] Andrzej Michalec for committer
+1, -- Ulhas Bhole Sergey Beryozkin wrote: As you all know we've been looking for people to help us with our JAXRS project for a while. We've had some great feedback and a number of patches submitted from our JAXRS users which helped us tremendously. Andrzej Michalec (Andy) has been the first user who contributed in a major way to our effort. Andy has completed a long pending task to do with JAXRS UriBuilder and UriInfo implementations by submitting 3 high quality patches, by adapting his own private implementations to CXF ones. It was a time consuming and difficult task which required anyone who'd attempt to tackle it to understand quite deeply the advanced HTTP and URI concepts. Andy submitted a number of queries to a JAXRS user list to ensure CXF UriBuilder implementation matched the intentions of JAXRS authors in a best possible way. Personally, I've been delighted with this task being completed and it was of great and immediate help to us in the client api work - I believe it saved us about 3 weeks. Andy has also highlighted the problems CXF JAXRS had around the dynamic sub-resource resolution and helped us to get things right. He experimented with the arbitrary regular expression support in CXF JAXRS and opened an issue suggesting how one of edge cases might need to be solved. He also raised an issue to do with the CXF logging. Finally, Andy has just gone ahead and improved the way CXF JAXRS documentation can be bookmarked and accessed, as well as added a section on dealing with UriBuilder and UriInfo. I do believe Andy has had an immediately positive impact on CXF JAXRS and thus I offer this vote to CXF committers. Here's my +1. Vote will remain open for at least 72 hours. Sergey
Re: Nexus, Hudson, and CXF snapshots deploys....
I am +1 on the idea because of the more regular latest snapshots. -- Ulhas Daniel Kulp wrote: They've recently setup the hudson instances to allow them to deploy snapshots to the Nexus instance using a special "snapshot" account. Thus, we could now have automated builds that do deploys of snapshots. We couldn't really do that previously without giving out some authentication stuff so this is kind of a big deal. So, are we interested? The only "downside" is the snapshot URL's that people may be using would need to change to: https://repository.apache.org/content/groups/snapshots/ which would affect some people. However, they would get updates on a daily basis, which is probably also a good thing. I guess I'd like to hear from the users that might be using the snapshots. How annoying would it be to update your URL's? (Note: that URL also proxies the original snapshot repo so you would UPDATE your pom/repository manager, not add a new repo) Would having more consistent snapshots help you?
Re: [VOTE] Release Apache CXF 2.2
+1, -- Ulhas Daniel Kulp wrote: This is a vote to release CXF 2.2 This release is a major step forward for CXF with several new features including: * WS-SecurityPolicy support * WS-SecureConversation * Some WS-Trust support (client side) * JAX-RS 1.0 along with MANY other improvements and enhancements. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.2 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.2 Here is my +1. The vote will be open here for at least 72 hours.
Re: [VOTE] Apache CXF 2.3.11/2.4.8/2.5.4/2.6.1
+1, -- Ulhas Bhole On 30 May 2012, at 19:15, Daniel Kulp wrote: > > > We've resolved over 90 issues since 2.6.0 was released. We've back ported > over 70 of them to 2.5.4 and 40 to 2.4.8 and 25 to 2.3.11. > > > List of issues: > 2.3.11: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320749 > 2.4.8: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320748 > 2.5.4: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320747 > 2.6.1: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320746 > > > The Maven staging areas are at: > 2.3.12: > https://repository.apache.org/content/repositories/orgapachecxf-149/ > 2.4.8: > https://repository.apache.org/content/repositories/orgapachecxf-159/ > 2.5.4: > https://repository.apache.org/content/repositories/orgapachecxf-160/ > 2.6.1: > https://repository.apache.org/content/repositories/orgapachecxf-161/ > > > The distributions are in the org/apache/cxf/apache-cxf/ directory of the > Maven staging areas. > > > This releases are tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.11 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.8 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.4 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.1 > > > This vote will be open for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
+1 for both branching out and dropping Java 5 Support. Regards, Ulhas Bhole On 5 Jun 2012, at 10:11, Colm O hEigeartaigh wrote: > +1. > > I intend on introducing streaming WS-Security support in 2.7, which will > depend on Santuario 2.0 and WSS4J 2.0, both of which are slated to require > JDK 1.6. > > Colm. > > On Fri, Jun 1, 2012 at 4:10 PM, Daniel Kulp wrote: > >> >> With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts >> about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here >> is a list of some things I'd like to start thinking about for 2.7: >> >> 1) Drop support for Java 5 - this may be a bit contentious. :-) It would >> simplify the poms a little bit, allow use of @Override, remove some jars >> from the lib dir, etc... The bigger issue is that several of the things we >> test with and depend on are now Java 6+ such as ActiveMQ and gwt and such >> so >> we've been stuck on older versions. >> >> 2) Async http client - this is been on my "maybe next version of CXF" for >> quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-) >> Would definitely help with some of the Camel integration scenarios. >> >> 3) WS-Discovery - really two parts to this. Runtime support to broadcast >> availability and discover endpoints is the first part. Second part MAY be >> a simple WS-Discovery proxy service for /services. >> >> 4) SOAP/UDP - Required for #3. >> >> 5) Possible re-write of the http-jetty transport to base it off the Servlet >> transport or similar so it can take more advantage of things like the >> services list, etc... Additionally, that may make it easier to create an >> http-tomcat transport (which people DID ask about at CamelOne BTW). >> >> Those are the things *I've* been thinking on and off about. Obviously the >> other folks around here may have additional things.I'm sure Colm has >> some security things, Sergey has some REST things, etc :-) >> >> So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes >> branch now? >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com
Re: [VOTE] Release Apache CXF Fediz 1.0.0
+1, -- Ulhas Bhole On 20 Jun 2012, at 00:22, Oliver Wulff wrote: > It's been over 6 months since work started on Fediz and it's time for the > first > release. The features in this release are: > > * WS-Federation 1.0/1.1/1.2 > * SAML 1.1/2.0 Tokens > * Custom token support > * Publish WS-Federation Metadata document > * Role information encoded as AttributeStatement in SAML 1.1/2.0 tokens > * Claims information provided by FederationPrincipal interface > > The documentation is available here: > http://cxf.apache.org/fediz.html > > The maven staging area: > https://repository.apache.org/content/repositories/orgapachecxf-250/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/fediz/tags/fediz-1.0.0 > > The distributions are in the org/apache/cxf/fediz/apache-fediz/ directory of > the > Maven staging area. > > This vote will be open for at least 72 hours. > > > > > -- > > Oliver Wulff > > Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/> > Solution Architect > http://coders.talend.com > > <http://coders.talend.com>Talend Application Integration Division > http://www.talend.com
Re: [VOTE] Release Apache CXF 2.4.9/2.5.5/2.6.2
+1, -- Ulhas On 15 Aug 2012, at 02:20, Daniel Kulp wrote: > > We've resolved over 80 issues since 2.6.1 and we're a little overdue for a > release. > > List of issues: > 2.4.9 > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321666 > 2.5.5 > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321667 > 2.6.2 > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321668 > > > The Maven staging areas are at: > 2.4.9 > https://repository.apache.org/content/repositories/orgapachecxf-001/ > 2.5.5 > https://repository.apache.org/content/repositories/orgapachecxf-002/ > 2.6.2 > https://repository.apache.org/content/repositories/orgapachecxf-004/ > > The distributions are in the org/apache/cxf/apache-cxf/ directory of the > Maven staging areas. > > > This releases are tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.9 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.5 > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.2 > > This vote will be open for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
Re: [VOTE] New features.xml for 2.5.5(.1)
+1, -- Ulhas Bhole On 22 Aug 2012, at 15:27, Daniel Kulp wrote: > > The Karaf features.xml file that was released with 2.5.5 is corrupt which is > preventing it from actually being usable to install CXF 2.5.5 into Karaf. > This vote is just to release a new features file (version 2.5.5.1) that fixes > that issue. It installs all the CXF 2.5.5 artifacts that have previously > been released. > > Again, this is ONLY a features.xml file release. > > Staging are: > https://repository.apache.org/content/repositories/orgapachecxf-029/ > > Tag: > http://svn.apache.org/repos/asf/cxf/tags/apache-cxf-features-xml-2.5.5.1/ > > > Here is my +1 > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
Re: [VOTE] Release CXF Fediz 1.0.1
+1, -- Ulhas Bhole On 24 Aug 2012, at 18:02, Glen Mazza wrote: > Hi all, this new release provides significant documentation updates within > the samples as well as new sample keys to help clarify necessary trust > requirements. Oli has also gotten some programmatic fixes/enhancements in. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313420&version=12321857 > > Maven staging areas: > https://repository.apache.org/content/repositories/orgapachecxf-006/ > > Releases are tagged at: > http://svn.apache.org/repos/asf/cxf/fediz/tags/fediz-1.0.1/ > > Here is my +1. The vote will be open for at least 72 hours. > > Thanks, > Glen > > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/VOTE-Release-CXF-Fediz-1-0-1-tp5713126.html > Sent from the cxf-dev mailing list archive at Nabble.com.
