date:20120323

RE: Issue CXF-4181

2012-03-23 Thread Carlos Rodríguez Fernández


Hi Aki,I added something else to the test. The unmarshalFault methods is used 
by the SAAJInInterceptor also, and it is there when the class receives the 
XMLStreamReader.class content for the fault only since the SAAJInInterceptor 
prepares it like that for this method.
I added this: SAAJInInterceptor saajInInterceptor = new SAAJInInterceptor();
saajInInterceptor.handleMessage(m);fault2 = 
(SoapFault)m.getContent(Exception.class);assertNotNull(fault2); 
   assertEquals(Soap12.getInstance().getSender(), fault2.getFaultCode());   
 assertEquals(new QName("http://schemas.xmlsoap.org/ws/2005/02/trust";, 
"FailedAuthentication"),  fault2.getSubCode());



The test passes successfully. I think the issue is resolved.
Regards,C.


> From: dk...@apache.org
> To: dev@cxf.apache.org
> CC: carlosrodrifernan...@live.com
> Subject: Re: Issue CXF-4181
> Date: Fri, 23 Mar 2012 14:13:51 -0400
> 
> 
> Just committed a fix for this to trunk using Aki's unit test.   Can you and 
> Aki take a quick look?
> 
> Basically, the SOAP Envelope/Body is stored on the message as a DOM node.   
> Thus, when we parse the fault to the DOM, we can actually parse it right 
> into the correct place in the original DOM.   All the namespaces would be 
> resolvable and such at that point. 
> 
> Dan
> 
> 
> On Thursday, March 22, 2012 03:44:34 PM Carlos Rodríguez Fernández wrote:
> > Hello,This issue is because the Soap12FaultInInterceptor.unmarshalFault
> > receives a XMLStreamReader only for the Fault element. This is because it
> > is what the SAAJInInterceptor.handleMessage does with the XMLSreamReader
> > content when the message is a fault.Well, I think this issue requires a
> > lot of changes. These are my options:1. Let the unmarshalFault has access
> > to the whole message passing a XMLStreamReader of the whole message. Will
> > this change the whole "style" of how CXF interceptors processes soap
> > messages, i.e. by fragments? Since cxf is dealing with XML (ns
> > declarations can be in any ancestor) I don't think it is a bad idea
> > passing the XMLStreamReader for the whole message, so that, interceptors
> > are not allowed to change the XMLStreamReader for specific fragments.2.
> > Having a SOAPMessage content always available for when an interceptor
> > needs it. For some reason, this content is not presented when the
> > Soap12FaultInInterceptor is processing the message.3. Leaving everything
> > as it is and assuming that CXF needs you not to have any namespace
> > declaration in Bodies or Envelope element :S. This is it. I'm willing to
> > send a big patch :).
> > Regards,C.
> -- 
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: base-address for CXF

2012-03-23 Thread William Tam

Finally, I got a chance to follow up.   Thanks Freeman for creating a 
Jira and addressing the issue.


On 01/16/2012 01:08 AM, Freeman Fang wrote:

Hi William,

Sorry for the late response, last week I was on travel so can't catch 
email in time.


Your suggestion looks good for me, could you please raise a jira and 
append a patch?


Thanks
Freeman
On 2012-1-14, at 上午3:40, William Tam wrote:


Anyone else can response, too.   (Perhaps, Freeman is unavailable).

Thanks.

On 01/11/2012 06:20 PM, William Tam wrote:

Hi Freeman,

I think I see an issue that can prevent publishedEndpointUrl 
property to be set on EndpointInfo object if the endpoint is created 
by a non-jaxws frontend.  (it is done when 
org.apache.cxf.jaxws.EndpointImp.doPublish() is  called)


In AbstractWSDLBasedEndpointFactory, the following snippet will set 
publishedEndpointUrl property which is inside createEndpointInfo()  
method.


   if (publishedEndpointUrl != null && 
!"".equals(publishedEndpointUrl)) {
   ei.setProperty("publishedEndpointUrl", 
publishedEndpointUrl);

   }

However, the EndpointInfo object could be created by other factories 
(e.g. SoapTransportFactory) and so the 
AbstractWSDLBasedEndpointFactory.createEndpointInfo() method may not 
be called at all.  As a result, the publishedEndpointUrl may not be 
set.


I would suggest moving the snippet to the createEndpoint() need line 
159.  (see diff from trunk below). That way, the 
publishedEndpointUrl is set on EndpointInfo regardless how it was 
created.


Index: 
src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java

===
--- 
src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java
(revision 1229797)
+++ 
src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java
(working copy)

@@ -157,6 +157,10 @@
ei.setAddress(getAddress());
}

+if (publishedEndpointUrl != null && 
!"".equals(publishedEndpointUrl)) {
+ei.setProperty("publishedEndpointUrl", 
publishedEndpointUrl);

+}
+
if (endpointReference != null) {
ei.setAddress(endpointReference);
}
@@ -294,10 +298,6 @@
ei.setAddress(getAddress());
ei.setBinding(bindingInfo);

-if (publishedEndpointUrl != null && 
!"".equals(publishedEndpointUrl)) {
-ei.setProperty("publishedEndpointUrl", 
publishedEndpointUrl);

-}
-
if (wsdlEndpointFactory != null) {
wsdlEndpointFactory.createPortExtensors(ei, service);
}

Thanks.

On 11/30/2011 07:59 PM, Freeman Fang wrote:


On 2011-11-30, at 下午9:30, rickthemick wrote:


I cant see that it works like you describe it.

Adding publishedEndpointUrl in my Spring conf:







Hi,

You need change the publishedEndpointUrl value to 
http://myserver/cxf/myservice
Also in the Service List Page, you can find the wsdl URL there is 
http://myserver/cxf/myservice?wsdl.

I just tested it with 2.4.4, it works for me.

Freeman


- Does not affect the service listing, I dont get "myserver" as 
host for the

services.
- And in the WSDL, it affects the whole service URL, not just the
host/server part:




It should be: http://myserver/cxf/myservice I believe.
- Even if it would work, I dont want to control this in the "code" 
(the

spring config in the service bundle).

In my understanding its still base-address that would solve my 
problem, but
I dont know how to make it affective and I havent found the 
definition of it

either.




--
View this message in context: 
http://cxf.547215.n5.nabble.com/base-address-for-CXF-tp5034937p5035493.html

Sent from the cxf-user mailing list archive at Nabble.com.


-
Freeman Fang

FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com












-
Freeman Fang

FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com

Re: Issue CXF-4181

2012-03-23 Thread Daniel Kulp


Just committed a fix for this to trunk using Aki's unit test.   Can you and 
Aki take a quick look?

Basically, the SOAP Envelope/Body is stored on the message as a DOM node.   
Thus, when we parse the fault to the DOM, we can actually parse it right 
into the correct place in the original DOM.   All the namespaces would be 
resolvable and such at that point. 

Dan


On Thursday, March 22, 2012 03:44:34 PM Carlos Rodríguez Fernández wrote:
> Hello,This issue is because the Soap12FaultInInterceptor.unmarshalFault
> receives a XMLStreamReader only for the Fault element. This is because it
> is what the SAAJInInterceptor.handleMessage does with the XMLSreamReader
> content when the message is a fault.Well, I think this issue requires a
> lot of changes. These are my options:1. Let the unmarshalFault has access
> to the whole message passing a XMLStreamReader of the whole message. Will
> this change the whole "style" of how CXF interceptors processes soap
> messages, i.e. by fragments? Since cxf is dealing with XML (ns
> declarations can be in any ancestor) I don't think it is a bad idea
> passing the XMLStreamReader for the whole message, so that, interceptors
> are not allowed to change the XMLStreamReader for specific fragments.2.
> Having a SOAPMessage content always available for when an interceptor
> needs it. For some reason, this content is not presented when the
> Soap12FaultInInterceptor is processing the message.3. Leaving everything
> as it is and assuming that CXF needs you not to have any namespace
> declaration in Bodies or Envelope element :S. This is it. I'm willing to
> send a big patch :).
> Regards,C.
-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

RE: Issue CXF-4181

2012-03-23 Thread Carlos Rodríguez Fernández



Hi,
Thanks Aki for the test :), the issue really needed it.I can change the 
SAAJInInterceptor so that it does not set the XMLStreamReader.class 
SoapMessage's content for only the fault. But if there are more classes that 
are programmed to use the XMLStreamReader for the fault, I think it is better 
if the saaj interceptor provides an alternative content like a 
SOAPMessage.class for these cases. Then, in the fault interceptor, the 
XUtils.getQName will work since it has the Envelope Node as ancestors 
(SOAPMessage.getSOAPPart().getSOAPEnvelope()). This is like "we provide you 
with exactly what you need for your interceptor (the xmlstreamreader for the 
fault element only in this case) but, just in case, you can have access to more 
resources, like SOAPMessage, if needed". This last option implies a change in 
the SAAJInInterceptor and in the fault one only.What do you think?Waiting for 
other proposals :).Regards,C.

> Date: Fri, 23 Mar 2012 15:34:15 +0100
> Subject: Re: Issue CXF-4181
> From: elak...@googlemail.com
> To: dev@cxf.apache.org
> 
> Hi,
> I attached a unit test for this problem to your jira ticket.
> 
> I thought a quick solution is to copy all the namespace bindings from
> the reader object to the root dom element but the public API does not
> have an iterator to access all the bindings. So, that didn't work.
> 
> Someone might have a simple solution.
> 
> regards, aki
> 
> El día 22 de marzo de 2012 23:44, Carlos Rodríguez Fernández
>  escribió:
> >
> > Hello,This issue is because the Soap12FaultInInterceptor.unmarshalFault 
> > receives a XMLStreamReader only for the Fault element. This is because it 
> > is what the SAAJInInterceptor.handleMessage does with the XMLSreamReader 
> > content when the message is a fault.Well, I think this issue requires a lot 
> > of changes. These are my options:1. Let the unmarshalFault has access to 
> > the whole message passing a XMLStreamReader of the whole message. Will this 
> > change the whole "style" of how CXF interceptors processes soap messages, 
> > i.e. by fragments? Since cxf is dealing with XML (ns declarations can be in 
> > any ancestor) I don't think it is a bad idea passing the XMLStreamReader 
> > for the whole message, so that, interceptors are not allowed to change the 
> > XMLStreamReader for specific fragments.2. Having a SOAPMessage content 
> > always available for when an interceptor needs it. For some reason, this 
> > content is not presented when the Soap12FaultInInterceptor is processing 
> > the message.3. Leaving everything as it is and assuming that CXF needs you 
> > not to have any namespace declaration in Bodies or Envelope element :S.
> > This is it. I'm willing to send a big patch :).
> > Regards,C.

Re: Ajax form submit for Maultipart contetnt type along with other form fields

2012-03-23 Thread Sergey Beryozkin


Hi
On 23/03/12 14:07, Ganesh wrote:

Hi All,

The requirements is to post the the form data along with the image/flash
file upload via AJAX sumbit.

In the server side we used @Consume("multipart/form-data") and the API
argument is org.apache.cxf.jaxrs.ext.multipart.MultipartBody

When we do a AJAX submit along with file upload everything is working fine.
We have a use case to submit the form without file upload. when we do the
AJAX sumbit without file upload the request content type is
"application/x-www-form-urlencoded" and in the server side we are getting
the below exception

[org.apache.cxf.jaxrs.utils.JAXRSUtils] .No operation matching request path
/ is found, HTTP Method : POST, ContentType :
application/x-www-form-urlencoded;charset=UTF-8, Accept :
application/json,text/javascript,*/*,.
2012-03-22 21:46:27,596 WARN
[org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper]
WebApplicationException has been caught : no cause is available

We tried to add  @Consume("application/x-www-form-urlencoded") in the server
side, but still we faced the same issue.

In one of the thread we found to use org.apache.cxf.jaxrs.ext.RequestHandler
to set the content type explicitly in the server side.

Could you please tell us whether can we follow the above approach or any
other solution to resolve the issue.


You definitely need to have 
@Consume("application/x-www-form-urlencoded") if the Content-Type is 
application/x-www-form-urlencoded, however the FormEncodingProvider does 
not deal with unmarshalling application/x-www-form-urlencoded payloads 
into MultipartBody.


Thus you need to have two POST handlers, one for dealing with 
application/x-www-form-urlencoded and having say MultivalueMap 
parameter, and another (existing) one - for handling multiparts


Cheers, Sergey



Regards,
Ganesh

--
View this message in context: 
http://cxf.547215.n5.nabble.com/Ajax-form-submit-for-Maultipart-contetnt-type-along-with-other-form-fields-tp5589560p5589560.html
Sent from the cxf-dev mailing list archive at Nabble.com.



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Issue CXF-4181

2012-03-23 Thread Aki Yoshida

Hi,
I attached a unit test for this problem to your jira ticket.

I thought a quick solution is to copy all the namespace bindings from
the reader object to the root dom element but the public API does not
have an iterator to access all the bindings. So, that didn't work.

Someone might have a simple solution.

regards, aki

El día 22 de marzo de 2012 23:44, Carlos Rodríguez Fernández
 escribió:
>
> Hello,This issue is because the Soap12FaultInInterceptor.unmarshalFault 
> receives a XMLStreamReader only for the Fault element. This is because it is 
> what the SAAJInInterceptor.handleMessage does with the XMLSreamReader content 
> when the message is a fault.Well, I think this issue requires a lot of 
> changes. These are my options:1. Let the unmarshalFault has access to the 
> whole message passing a XMLStreamReader of the whole message. Will this 
> change the whole "style" of how CXF interceptors processes soap messages, 
> i.e. by fragments? Since cxf is dealing with XML (ns declarations can be in 
> any ancestor) I don't think it is a bad idea passing the XMLStreamReader for 
> the whole message, so that, interceptors are not allowed to change the 
> XMLStreamReader for specific fragments.2. Having a SOAPMessage content always 
> available for when an interceptor needs it. For some reason, this content is 
> not presented when the Soap12FaultInInterceptor is processing the message.3. 
> Leaving everything as it is and assuming that CXF needs you not to have any 
> namespace declaration in Bodies or Envelope element :S.
> This is it. I'm willing to send a big patch :).
> Regards,C.

Re: svn commit: r1304181 - /cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

2012-03-23 Thread Willem Jiang


Hi Dan,
I did some test by using the .
It doesn't work and the created HttpConduit 's getBeanName return null.

I didn't see the   can do the trick.

On Fri Mar 23 19:38:09 2012, Daniel Kulp wrote:


Willem,

Not objecting to this, but wondering why it's necessary?   Such conduits
really should be configured based on URL, not some strange internal name or
similar.   Seriously, a conduit thing like:

  ...

would likely accomplish the exact same thing.

Dan


On Friday, March 23, 2012 04:01:19 AM ningji...@apache.org wrote:

Author: ningjiang
Date: Fri Mar 23 04:01:19 2012
New Revision: 1304181

URL: http://svn.apache.org/viewvc?rev=1304181&view=rev
Log:
CXF-4195 fixed the configuration issue of http conduit for WsdlUrl

Modified:

cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java

Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/t
ransport/TransportURIResolver.java?rev=1304181&r1=1304180&r2=1304181&view=
diff
=
= ---
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java (original) +++
cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
.java Fri Mar 23 04:01:19 2012 @@ -26,6 +26,8 @@ import
java.net.URISyntaxException;
  import java.util.HashSet;
  import java.util.Set;

+import javax.xml.namespace.QName;
+
  import org.xml.sax.InputSource;

  import org.apache.cxf.Bus;
@@ -101,6 +103,8 @@ public class TransportURIResolver extend
  }
  if (ci != null) {
  EndpointInfo info = new EndpointInfo();
+// set the endpointInfo name which could be used for
configuration +info.setName(new
QName("http://cxf.apache.org";, "TransportURIResolver"));
info.setAddress(base.toString());
  final Conduit c = ci.getConduit(info);
  Message message = new MessageImpl();




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang 
Weibo: willemjiang

Ajax form submit for Maultipart contetnt type along with other form fields

2012-03-23 Thread Ganesh

Hi All,

The requirements is to post the the form data along with the image/flash
file upload via AJAX sumbit.

In the server side we used @Consume("multipart/form-data") and the API
argument is org.apache.cxf.jaxrs.ext.multipart.MultipartBody

When we do a AJAX submit along with file upload everything is working fine.
We have a use case to submit the form without file upload. when we do the
AJAX sumbit without file upload the request content type is
"application/x-www-form-urlencoded" and in the server side we are getting
the below exception

[org.apache.cxf.jaxrs.utils.JAXRSUtils] .No operation matching request path
/ is found, HTTP Method : POST, ContentType :
application/x-www-form-urlencoded;charset=UTF-8, Accept :
application/json,text/javascript,*/*,.
2012-03-22 21:46:27,596 WARN
[org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper]
WebApplicationException has been caught : no cause is available

We tried to add @Consume("application/x-www-form-urlencoded") in the server
side, but still we faced the same issue.

In one of the thread we found to use org.apache.cxf.jaxrs.ext.RequestHandler
to set the content type explicitly in the server side.

Could you please tell us whether can we follow the above approach or any
other solution to resolve the issue.

Regards,
Ganesh

--
View this message in context:
http://cxf.547215.n5.nabble.com/Ajax-form-submit-for-Maultipart-contetnt-type-along-with-other-form-fields-tp5589560p5589560.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: svn commit: r1304292

2012-03-23 Thread Simmons, Andre [USA]



Sent from my Verizon Wireless Phone

- Reply message -
From: "Sergey Beryozkin" 
Date: Fri, Mar 23, 2012 8:05 am
Subject: svn commit: r1304292
To: "dev@cxf.apache.org" 

Hi
On 23/03/12 11:58, serg...@apache.org wrote:
> Author: sergeyb
> Date: Fri Mar 23 11:58:10 2012
> New Revision: 1304292
>
> URL: http://svn.apache.org/viewvc?rev=1304292&view=rev
> Log:
> [CXF-4198] Moving JSONProvider to rt-rs-extension-providers
>
> Modified:
>  cxf/trunk/distribution/pom.xml
>  
> cxf/trunk/distribution/src/main/release/samples/corba/hello_world/src/main/idl/HelloWorld.idl
>  
> cxf/trunk/distribution/src/main/release/samples/jax_rs/content_negotiation/pom.xml
>  
> cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/server/Server.java
>  
> cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/sts/Server.java
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/bin/gencerts.sh
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/certs/demoCA/index.txt
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/Client.java
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/wssec.xml
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/GreeterImpl.java
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/Server.java
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/wssec.xml
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world.wsdl
>  
> cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world_no_policy.wsdl

For whatever reasons corba, sts, ws-security demos have been apparently
modified during this merge, which I do not recall doing, how can it
happen really ? I'm a bit lost :-)

Sergey

Re: svn commit: r1304292

2012-03-23 Thread Sergey Beryozkin

Those the 'changes' made seem to not really change anything in those 
demos, so may be I should not revert...


Sergey
On 23/03/12 12:04, Sergey Beryozkin wrote:

Hi
On 23/03/12 11:58, serg...@apache.org wrote:

Author: sergeyb
Date: Fri Mar 23 11:58:10 2012
New Revision: 1304292

URL: http://svn.apache.org/viewvc?rev=1304292&view=rev
Log:
[CXF-4198] Moving JSONProvider to rt-rs-extension-providers

Modified:
cxf/trunk/distribution/pom.xml
cxf/trunk/distribution/src/main/release/samples/corba/hello_world/src/main/idl/HelloWorld.idl

cxf/trunk/distribution/src/main/release/samples/jax_rs/content_negotiation/pom.xml

cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/server/Server.java

cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/sts/Server.java

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/bin/gencerts.sh

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/certs/demoCA/index.txt

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/Client.java

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/wssec.xml

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/GreeterImpl.java

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/Server.java

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/wssec.xml

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world.wsdl

cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world_no_policy.wsdl



For whatever reasons corba, sts, ws-security demos have been apparently
modified during this merge, which I do not recall doing, how can it
happen really ? I'm a bit lost :-)

Sergey



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: svn commit: r1304292

2012-03-23 Thread Sergey Beryozkin


Hi
On 23/03/12 11:58, serg...@apache.org wrote:

Author: sergeyb
Date: Fri Mar 23 11:58:10 2012
New Revision: 1304292

URL: http://svn.apache.org/viewvc?rev=1304292&view=rev
Log:
[CXF-4198] Moving JSONProvider to rt-rs-extension-providers

Modified:
 cxf/trunk/distribution/pom.xml
 
cxf/trunk/distribution/src/main/release/samples/corba/hello_world/src/main/idl/HelloWorld.idl
 
cxf/trunk/distribution/src/main/release/samples/jax_rs/content_negotiation/pom.xml
 
cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/server/Server.java
 
cxf/trunk/distribution/src/main/release/samples/sts/src/demo/wssec/sts/Server.java
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/bin/gencerts.sh
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/certs/demoCA/index.txt
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/Client.java
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/client/wssec.xml
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/GreeterImpl.java
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/Server.java
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/src/demo/wssec/server/wssec.xml
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world.wsdl
 
cxf/trunk/distribution/src/main/release/samples/ws_security/ut_policy/wsdl/hello_world_no_policy.wsdl


For whatever reasons corba, sts, ws-security demos have been apparently 
modified during this merge, which I do not recall doing, how can it 
happen really ? I'm a bit lost :-)


Sergey

Re: svn commit: r1304181 - /cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

2012-03-23 Thread Daniel Kulp


Willem,

Not objecting to this, but wondering why it's necessary?   Such conduits 
really should be configured based on URL, not some strange internal name or 
similar.   Seriously, a conduit thing like:

 ...

would likely accomplish the exact same thing.

Dan


On Friday, March 23, 2012 04:01:19 AM ningji...@apache.org wrote:
> Author: ningjiang
> Date: Fri Mar 23 04:01:19 2012
> New Revision: 1304181
> 
> URL: http://svn.apache.org/viewvc?rev=1304181&view=rev
> Log:
> CXF-4195 fixed the configuration issue of http conduit for WsdlUrl
> 
> Modified:
>
> cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
> .java
> 
> Modified:
> cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
> .java URL:
> http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/t
> ransport/TransportURIResolver.java?rev=1304181&r1=1304180&r2=1304181&view=
> diff
> =
> = ---
> cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
> .java (original) +++
> cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver
> .java Fri Mar 23 04:01:19 2012 @@ -26,6 +26,8 @@ import
> java.net.URISyntaxException;
>  import java.util.HashSet;
>  import java.util.Set;
> 
> +import javax.xml.namespace.QName;
> +
>  import org.xml.sax.InputSource;
> 
>  import org.apache.cxf.Bus;
> @@ -101,6 +103,8 @@ public class TransportURIResolver extend
>  }
>  if (ci != null) {
>  EndpointInfo info = new EndpointInfo();
> +// set the endpointInfo name which could be used for
> configuration +info.setName(new
> QName("http://cxf.apache.org";, "TransportURIResolver"));
> info.setAddress(base.toString());
>  final Conduit c = ci.getConduit(info);
>  Message message = new MessageImpl();
-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

RE: Issue CXF-4181

Re: base-address for CXF

Re: Issue CXF-4181

RE: Issue CXF-4181

Re: Ajax form submit for Maultipart contetnt type along with other form fields

Re: Issue CXF-4181

Re: svn commit: r1304181 - /cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

Ajax form submit for Maultipart contetnt type along with other form fields

Re: svn commit: r1304292

Re: svn commit: r1304292

Re: svn commit: r1304292

Re: svn commit: r1304181 - /cxf/trunk/api/src/main/java/org/apache/cxf/transport/TransportURIResolver.java

12 matches

Site Navigation

Mail list logo

Footer information