Re: svn commit: r1100921 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java

Hi Dan, Thanks for your clarification. I'll revert my change, and Willem's 1100162 commit already store application context classloader for spring bus and your 1087406 commit already set correct application context classloader which retrieved from SpringBus or BlueprintBus for MessageObser

Re: svn commit: r1100162 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java

On Tuesday, May 10, 2011 12:40:16 PM Alessio Soldano wrote: > Hi Willem, > > On 05/10/2011 04:02 PM, Willem Jiang wrote: > > Hi Alessio, > > > > I checked the code of CXF before I commit the patch, there is no code > > which set the ClassLoad extension on the bus. I think the patch just > > bring

Re: svn commit: r1100921 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java

I have to -1 this commit as it breaks a few use cases. Primarily, the STS server we now have as part of the CXF bundle. In the case of the STS, the classloader that loads the STS class will likely be the CXF bundle classloader, not the application context. However, the user code will likely

Re: Custom Reuqest Param Name for Bean Request Object

Thanks for the reply. But in the first approach the client users has to follow Java naming conventions (espc a non-java client) right? Regarding the MultiValueMap, i like the idea, but not for Bean based. Here the developers need to convert the map to Bean right? I still prefer to use *@FormPara

Re: Custom Reuqest Param Name for Bean Request Object

Hi Please see comments inline On Tue, May 10, 2011 at 8:29 PM, Biju Nair wrote: > Hi Team, > > Currently I was helping a team in building rest based services using CXF. I > noticed that for bean based service arguments (*Ex. String > getData(@FormParam("") TestObj tObj)*) > you have to include @

Custom Reuqest Param Name for Bean Request Object

Hi Team, Currently I was helping a team in building rest based services using CXF. I noticed that for bean based service arguments (*Ex. String getData(@FormParam("") TestObj tObj)*) you have to include @FormParam with empty qualifer name and the request parameter should follow bean property namin

Re: svn commit: r1100162 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java

Hi Willem, On 05/10/2011 04:02 PM, Willem Jiang wrote: Hi Alessio, I checked the code of CXF before I commit the patch, there is no code which set the ClassLoad extension on the bus. I think the patch just bring the issue of ClientImpl::doInvoke() to the table. Yes, I agree. The ClassLoade

Re: EXTERNAL: Social Event in Washington DC May 23rd.

Hi there, I'll be going too! -- View this message in context: http://cxf.547215.n5.nabble.com/Social-Event-in-Washington-DC-May-23rd-tp4370681p4384563.html Sent from the cxf-dev mailing list archive at Nabble.com.

Re: CXF 2.4.0 SAML 2.0 support

Hi David, > Question: Can CXF 2.4.0 currently support the wsse:Security header attached? Yes, it should be able to both generate and process such a Security header. The best way to find out is to try it, and then log a JIRA if you run in to a problem. What are your requirements in general? What s

Re: svn commit: r1100162 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java

Hi, I'm looking at the changes for CXF-3497 as it seems I've a regression because of that. As far as I understand, the ClassLoader that was used to create the bus application context is stored within the bus as an extension. Given the same extension is then later retrieved in ClientImpl::doInvo

Re: Is there any way to maintain Queue without JMS?

Camel provides some kind of message routing, if you want to persistent the message into queue, you still need to leverage the JMS. On 5/10/11 8:59 AM, James Carr wrote: I think what you want is outside the scope of CFX. You should probably look at Apache Camel, Mule or Fuse for different routin