Re: Error reading XMLStreamReader @ SOAPUI but works fine in browser

[harilal.a.s]

will look in to this

The header is different while accessing through direct application. if we
hit the application server directly,  getting header

Headers: {accept-encoding=[gzip,deflate], connection=[Keep-Alive],
Content-Length=[1251], content-type=[text/xml;charset=UTF-8],
Host=[hostip:port], SOAPAction=["urn:GetAccountProfile"],
User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)

Thanks & regards,
Harilal.A.S.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/Error-reading-XMLStreamReader-SOAPUI-but-works-fine-in-browser-tp5738545p5738607.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: DefaultCryptoCoverageChecker property checkFaults

[José Manuel Prieto]

Sorry, I explain:
1.- Start Tomcat.
2.- In folder "identidad-paxaseMock" run: mvn install. It generate a war
file.
3.- Deploy war file in Tomcat.
4.- In folder "identidad-cliente_xunta":
- src/main/resources/spring/spring-client_paxase: it has the
property "checkFaults".
- Test to run (TestNG):
-
es.depontevedra.soap.interoperabilidad.identidad.paxase.ClientPaxase.consultarIdentidad_prueba
(OK)
-
es.depontevedra.soap.interoperabilidad.identidad.paxase.ClientPaxase.consultarIdentidad_excepcion.
(SoapFault, but test must OK)
5.- Change property "checkFault" and run again the tests.

thanks
JMPrieto


2014/1/15 José Manuel Prieto 

> Hi coheigea,
> I left a project in Google Drive:
>
>
> https://drive.google.com/file/d/0B9NfBsCykkXqNWhielRla0ZiY00/edit?usp=sharing
>
> thanks
> JMPrieto
>
>
> 2014/1/15 Colm O hEigeartaigh 
>
>> Could you create a test-case that shows the problem?
>>
>> Colm.
>>
>>
>> On Wed, Jan 15, 2014 at 9:23 AM, José Manuel Prieto <
>> joseman...@prietopalacios.net> wrote:
>>
>> > Unsolved
>> >
>> > I followed this steps:
>> > 0.- Create diferent calls in spring file to
>> DefaultCryptoCoverageChecker,
>> > ref, bean, property --> no changes
>> > 1.- I create a custom Interceptor --> no changes
>> > public class CustomDefaultCryptoCoverageChecker extends
>> > DefaultCryptoCoverageChecker {
>> >
>> > public CustomDefaultCryptoCoverageChecker(){
>> > setCheckFaults(false);
>> > }
>> > }
>> >
>> > 2.- Change jaxb library version: form jaxb-impl:2.2.5-2 to
>> > jaxb-impl:2.1.13. --> no changes
>> > 3.- Change spring library version form spring:3.0.5.RELEASE to
>> > spring:3.2.6.RELEASE --> no changes
>> > 4.- Continuing the trace, I get to:
>> > DocLiteralInInterceptor.handleMessage(Message message){
>> >...
>> >o = dr.read(p, xmlReader); call to -->
>> > DataReaderImpl.read(MessagePartInfo part, T reader)
>> >...
>> > }
>> >
>> > DataReaderImpl.read(MessagePartInfo part, T reader){
>> >return JAXBEncoderDecoder.unmarshall(createUnmarshaller(), reader,
>> part,
>> >  unwrapJAXBElement);
>> > }
>> >
>> > Who instance JAXB? spring?.
>> > Why only one parameter change my wolrd?
>> >
>> > thanks for readme
>> > JMPrieto
>> >
>> >
>> >
>> > 2014/1/14 José Manuel Prieto 
>> >
>> > > Hello,
>> > >
>> > > If I put property checkFaults="false" (in sringframework application
>> > > context file), only SoapFault Messages runs as expected.
>> > > My service return a Response object. The service response is 200 (OK),
>> > > send me a Response (I see it, in the server-log), my client obtain a
>> > > Response object but, all atributes to null.
>> > >
>> > > I trace until to SoapHeaderInterceptor.handleMessage(Message m). This
>> > > methods contains:
>> > > public void handleMessage(Message m) throws Fault {
>> > > SoapMessage message = (SoapMessage) m;
>> > > SoapVersion soapVersion = message.getVersion();
>> > > Exchange exchange = message.getExchange();
>> > >
>> > > MessageContentsList parameters =
>> > > MessageContentsList.getContentsList(message);
>> > > 
>> > >
>> > > When checkFaults="true", the var parameters(MessageContentsList) has a
>> > > List [size=1] with Response object and atributes with some values.
>> > > When checkFaults="false", the var parameters(MessageContentsList) has
>> a
>> > > List [size=1] with Response object and atributes to NULL.
>> > >
>> > > I thought it was a problem with springframework, but now i don´t now.
>> > > can anybody help me?
>> > >
>> > > Thanks in advance
>> > > JMPrieto
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>

STR-Transform for IssuedToken in WS-Policy

[bimjoeipa]

Hi,

We are currently using a particular ESB which requires that SAML tokens with
the Sender Vouches (SV) confirmation method must have a STR-Transform
signature in the security header.  We use an STS that generates signed SAML
SV Tokens (we are using SV because we are exchanging a proprietary Single
Sign on Token for a SAML token).

I debugged
org.apache.cxf.systest.wssec.examples.saml.SamlTokenTest.testSymmetricSV()
compared with
org.apache.cxf.systest.wssec.examples.saml.SamlTokenTest.testSymmetricIssuedToken()
(I realise this example is HOK) and from what I can tell, it basically came
down to sp:IssuedToken's can't generate STR-Transforms, but the sp:SamlToken
does.  

Does this sound correct, does CXF have a technical limitation that it won't
generate a STR-Transform for sp:IssuedToken's?  I understand that
IssuedTokens are signed, so don't technically need another signature, but
our ESB is a bit stubborn in this area...

Thanks,

Joel



--
View this message in context: 
http://cxf.547215.n5.nabble.com/STR-Transform-for-IssuedToken-in-WS-Policy-tp5738605.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: wadl2java generates invalid method names

[tomstark]

Update:  It's not like the bug mentioned in the previous post since it
doesn't have anything to do with a collision with java reserved names but
requires the same substitution for method names that are generated based on
multiple representations.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/wadl2java-generates-invalid-method-names-tp5738564p5738601.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Accessing temporary file name of attachments

[Sergey Beryozkin]

Hmm...
I start thinking that may be I've misunderstood the issue and applying 
your original patch (with possible modifications as indicated by Dan) is 
the simplest/cheapest solution in the end,

Dan if you are OK then may be we can indeed work on the patch

Thanks, Sergey

On 15/01/14 16:39, Henry Clout wrote:

Hi Sergey.

I don't think we'd want to create the file in its final destination because:

i) The destination base directory and path vary from service method to service 
method, and are also a function of the request parameters.  I wouldn't have 
thought there would be sufficient information in the interface you're proposing 
to figure this out, and even if there were I'm not sure it sounds like a good 
idea to pull this out of the service methods.

ii) We don't really want to copy a file directly to the target until the 
request has been validated.  Other processes operate over the target directory 
which require the input to have been validated.

However, let's say the interface were something like (caveat: I don't know if 
this is possible!) :

import java.io.File;
import org.apache.cxf.jaxrs.ext.multipart.Attachment;

public interface TempFileGenerator {
/**
 * Return a file which will be used as the destination for the payload
 * for the given attachment.
 * @param attachment
 * @return
 */
File generateTempFile(Attachment attachment);
}

Then an implementation which would achieve what we were after would be:

public class MyTempFileGenerator implements TempFileGenerator {

private File tempBasePath;

@Override
public File generateTempFile(Attachment attachment) {
return new File(tempBasePath, attachment.getContentId());
}

}

So our service implementation could then figure out where the temp file is (if 
not in memory) based on the Attachment object.  This is what I meant when I 
mentioned that that the service implementation should be able to figure out the 
temp file location.

If this is what you were proposing for the temp file interface (or something 
comparable), then it would work for the use case I was describing.

Cheers,

Henry


On 15 Jan 2014, at 14:14, Sergey Beryozkin  wrote:


Hi Henry
On 15/01/14 13:53, Henry Clout wrote:

Hi Sergey.

For us at least this wouldn't really address our problem.  Our flow is:

- Content is uploaded to CXF.
- Our service method performs some validation on the input.
- If all is ok, the content is moved to the correct place.

In our case, the correct place is a location on a NAS.  The CXF temp file 
location is also on the NAS   So to go via an InputStream, we have pull the 
data from the NAS across the network into memory, then transfer it out again 
over the network back to the NAS.  Even on a gigabit network, this is a 
significant slowdown for large files vs a file rename, which is what transferTo 
amounts to if the CXF temp directory is placed on the NAS.

Dealing exclusively with InputStreams prevents any kind of file move style 
optimisation.  I agree that this is an application specific optimisation, but I 
guess I thought it would be useful if CXF could allow this kind of 
functionality via some sort of interface to those that would benefit from it.  
My gut feeling was that it wasn't just us who are using CXF to transfer large 
files, so someone else may benefit from this functionality.

As it happens, we've worked around this by using Spring multipart parsing 
within CXF:

@POST
@Path("/kulus/{guid}/media")
public void addMediaToKulu(@PathParam("guid") String guid) throws 
IOException {
MultipartFile multipartFile = null;
if (commonsMultipartResolver.isMultipart(httpServletRequest)) {
MultipartHttpServletRequest multipartHttpServletRequest 
= commonsMultipartResolver.resolveMultipart(httpServletRequest);
Iterator fileNamesIterator = 
multipartHttpServletRequest.getFileNames();
if (fileNamesIterator.hasNext()) {
String firstFileName = fileNamesIterator.next();
multipartFile = 
multipartHttpServletRequest.getFile(firstFileName);
}
}
// We call multipartFile.transferTo(file) later on ...
}

At the end of the day, maybe this workaround is sufficient rather than changing 
the core CXF code.  I guess if you think this functionality wouldn't be useful 
to others, then I'm happy to accept that :-)


What I'm not getting is this:

Suppose CXF will let developers customize the way, or rather, where temp files 
are created and I guess with the option to be notified when a temp file needs 
to be closed. In your case you'd register a handler which would ensure that if 
a temporarily file is needed then it would be created immediately in the right 
place.

So now you have an InputStream, p

Re: When is CXF 2.7.9 being released?

[Daniel Kulp]

On Jan 15, 2014, at 4:01 PM, Freddy Exposito  wrote:

> Hi All,
> 
> We are working with CXF  in our company and we are relying on some fixes
> that are expected to be released in CXF 2.7.9.
> 
> It would be great for us to have CXF 2.7.9 released soon. Do you have an
> approximated date for the 2.7.9 release?

Probably within the next few weeks.2.7.8 was the end of November so end of 
January would be the right time, but I know I’ve been pulled in a few 
directions at work so haven’t had time to devote to thinking about it and 
running tests and paying attention to the automated builds and such like I 
normally do.:-(



-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

When is CXF 2.7.9 being released?

[Freddy Exposito]

Hi All,

We are working with CXF  in our company and we are relying on some fixes
that are expected to be released in CXF 2.7.9.

It would be great for us to have CXF 2.7.9 released soon. Do you have an
approximated date for the 2.7.9 release?

Thanks,
Freddy



--
View this message in context: 
http://cxf.547215.n5.nabble.com/When-is-CXF-2-7-9-being-released-tp5738598.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Error reading XMLStreamReader @ SOAPUI but works fine in browser

[Daniel Kulp]

No idea really, but if it’s not getting any content, that’s certainly a 
problem.   Definitely try a wireshark or TCP dump or something to verify what 
is being sent on the wire.

On “questionable” thing I see is:


> , conten-lengtth=[1594],

That’s obviously spelled very wrong.   I’m wondering if that would be causing 
it to not know how long the content is and thus is causing an issue.   Not sure 
sure where that header would be coming from.   Possibly something in the web 
server configured strangely?   If you can wireshark the transfer to verify that 
the raw message  on the wire has that spelled wrong, you’d at least know which 
side to look at more closely.

Dan



On Jan 14, 2014, at 9:42 AM, harilal.a.s  wrote:

> Hi,
> We have a spring-cxf ( Spring 3.0.4, CXF 2.5.10, Java 6) web service
> application deployed in WAS 8.0.0.7 @ Linux machine. We are able to access
> all services through soap ui by directly using ip on url (through Linux IP
> in which application installed). Now the app server is behind the Web server
> (iplanet, & configured by client) and now the issue comes(we are using https
> to hit the web server where as web server to app server is http).
> We are able to see xml content in browser using the url provided by client
> but when we access the web service through SOAPUI we are getting "Error
> reading XMLStreamReader." and following exception in WAS log
> 
> --
>[1/14/14 5:14:34:375 GMT] 0040 AccDetailsInt I
> org.apache.cxf.services.AccountDetailsWSService.AccountDetailsWSPort.AccDetailsInt
>  
> Inbound Message
> 
> 
>ID: 13
>Address: https://{ip:port}/infox/services/AccountDetailsWSPort
>Encoding: UTF-8
>Http-Method: POST
>Content-Type: text/xml;charset=UTF-8
>Headers: {$WSCS=[SSL_RSA_WITH_RC4_128_MD5-128], $WSIS=[true],
> $WSPR=[HTTP/1.1], $WSRA=[10.203.118.218], $WSRH=[10.203.118.218],
> $WSSC=[https],
> $WSSI=[Q1IrQ29oeGJCMFNHRWFPNzdBYjBRSU1RNEVZd3RWSHhlVWJyRGtnaDBEWT0=],
> $WSSN=[ip], $WSSP=[2006], _WS_HAPRT_WLMVERSION=[-1],
> accept-encoding=[gzip,deflate], conten-lengtth=[1594],
> content-type=[text/xml;charset=UTF-8], Host=[{ip:port}],
> SOAPAction=["urn:GetAccountProfile"],
> Surrogate-Capability=[WS-ESI="ESI/1.0+"],
> User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)]}
>--
> 
>[1/14/14 5:14:34:376 GMT] 0040 SystemOut O Request XML : 
>[1/14/14 5:14:34:376 GMT] 0040 PhaseIntercep W
> org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging Interceptor for
> {http://wsbroker.core.infx.com/}AccountDetailsWSService has thrown
> exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader.
>at
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.handleMessage(SAAJInInterceptor.java:139)
>at
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor$SAAJPreInInterceptor.handleMessage(SAAJInInterceptor.java:102)
>at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
>at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
>at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:233)
>at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
>at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:194)
>at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:129)
>at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:223)
>at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:143)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:199)
>at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
>at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
>at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
>at
> com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
>at
> com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
>at
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
>at
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:909)
>at
> com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
>at
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
>at
> com.ibm.w

Re: handleFault() method not called when exception occurs in handleMessage()

[Daniel Kulp]

You are catching the Exception and then just printing a stack trace.  You 
aren’t then throwing something from your handleMessage.   The handleFault 
method is called if and exception /fault is thrown from the handleMessage 
method.  If nothing is thrown from there, CXF assumes everything has processed 
normally and continues.

Dan


On Jan 15, 2014, at 5:57 AM, nikosdim  wrote:

> Hi
> 
> I have an inbound interceptor that performs some actions before invoking my
> webservice. In my interceptor I call method from classes that I instantiate
> on runtime with Class.forName(cls);
> 
> I am currently testing what happens when I give invalid class name in the
> cls variable and I noticed that despite the fact that ClassNotFoundException
> occurs (which I am catching) the method handleFault() is never called. 
> 
> Why is that happening? I've read that handleFault() is called when the
> process in the handleMessage is interrupted but what this exactly means?
> Isn't an Exception an interruption?
> 
> My code:
> 
> public class ESMAPISecurityInterceptor extends
>   AbstractPhaseInterceptor {
> 
>   public ESMAPISecurityInterceptor(String phase) {
>   super(phase);
>   }
> 
>   @Override
>   public void handleMessage(Message message) throws Fault {
>   try {
>   Class c = Class.forName("an.invalid.class.name");
>   } catch (ClassNotFoundException e) {
>   e.printStackTrace();
>   }
>   }
> 
>   @Override
>   public void handleFault(Message message) {
>   System.out.println("Prints from handleFault()");
>   }
> }
> 
> Thanks
> 
> 
> 
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/handleFault-method-not-called-when-exception-occurs-in-handleMessage-tp5738573.html
> Sent from the cxf-user mailing list archive at Nabble.com.

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Accessing temporary file name of attachments

[Henry Clout]

Hi Sergey.

I don't think we'd want to create the file in its final destination because:

i) The destination base directory and path vary from service method to service 
method, and are also a function of the request parameters.  I wouldn't have 
thought there would be sufficient information in the interface you're proposing 
to figure this out, and even if there were I'm not sure it sounds like a good 
idea to pull this out of the service methods.

ii) We don't really want to copy a file directly to the target until the 
request has been validated.  Other processes operate over the target directory 
which require the input to have been validated.

However, let's say the interface were something like (caveat: I don't know if 
this is possible!) :

import java.io.File;
import org.apache.cxf.jaxrs.ext.multipart.Attachment;

public interface TempFileGenerator {
/**
 * Return a file which will be used as the destination for the payload
 * for the given attachment.
 * @param attachment
 * @return
 */
File generateTempFile(Attachment attachment);
}

Then an implementation which would achieve what we were after would be:

public class MyTempFileGenerator implements TempFileGenerator {

private File tempBasePath;

@Override
public File generateTempFile(Attachment attachment) {
return new File(tempBasePath, attachment.getContentId());
}

}

So our service implementation could then figure out where the temp file is (if 
not in memory) based on the Attachment object.  This is what I meant when I 
mentioned that that the service implementation should be able to figure out the 
temp file location.

If this is what you were proposing for the temp file interface (or something 
comparable), then it would work for the use case I was describing.

Cheers,

Henry


On 15 Jan 2014, at 14:14, Sergey Beryozkin  wrote:

> Hi Henry
> On 15/01/14 13:53, Henry Clout wrote:
>> Hi Sergey.
>> 
>> For us at least this wouldn't really address our problem.  Our flow is:
>> 
>> - Content is uploaded to CXF.
>> - Our service method performs some validation on the input.
>> - If all is ok, the content is moved to the correct place.
>> 
>> In our case, the correct place is a location on a NAS.  The CXF temp file 
>> location is also on the NAS   So to go via an InputStream, we have pull the 
>> data from the NAS across the network into memory, then transfer it out again 
>> over the network back to the NAS.  Even on a gigabit network, this is a 
>> significant slowdown for large files vs a file rename, which is what 
>> transferTo amounts to if the CXF temp directory is placed on the NAS.
>> 
>> Dealing exclusively with InputStreams prevents any kind of file move style 
>> optimisation.  I agree that this is an application specific optimisation, 
>> but I guess I thought it would be useful if CXF could allow this kind of 
>> functionality via some sort of interface to those that would benefit from 
>> it.  My gut feeling was that it wasn't just us who are using CXF to transfer 
>> large files, so someone else may benefit from this functionality.
>> 
>> As it happens, we've worked around this by using Spring multipart parsing 
>> within CXF:
>> 
>>  @POST
>>  @Path("/kulus/{guid}/media")
>>  public void addMediaToKulu(@PathParam("guid") String guid) throws 
>> IOException {
>>  MultipartFile multipartFile = null;
>>  if (commonsMultipartResolver.isMultipart(httpServletRequest)) {
>>  MultipartHttpServletRequest multipartHttpServletRequest 
>> = commonsMultipartResolver.resolveMultipart(httpServletRequest);
>>  Iterator fileNamesIterator = 
>> multipartHttpServletRequest.getFileNames();
>>  if (fileNamesIterator.hasNext()) {
>>  String firstFileName = fileNamesIterator.next();
>>  multipartFile = 
>> multipartHttpServletRequest.getFile(firstFileName);
>>  }
>>  }
>>  // We call multipartFile.transferTo(file) later on ...
>>  }
>> 
>> At the end of the day, maybe this workaround is sufficient rather than 
>> changing the core CXF code.  I guess if you think this functionality 
>> wouldn't be useful to others, then I'm happy to accept that :-)
>> 
> What I'm not getting is this:
> 
> Suppose CXF will let developers customize the way, or rather, where temp 
> files are created and I guess with the option to be notified when a temp file 
> needs to be closed. In your case you'd register a handler which would ensure 
> that if a temporarily file is needed then it would be created immediately in 
> the right place.
> 
> So now you have an InputStream, possible completely in the memory and may be 
> backed up by a temp file in the right location.
> 
> Can you please explain again why that won't be sufficient in your case ?
> 
> Thanks, Sergey

Re: DefaultCryptoCoverageChecker property checkFaults

[José Manuel Prieto]

Hi coheigea,
I left a project in Google Drive:

https://drive.google.com/file/d/0B9NfBsCykkXqNWhielRla0ZiY00/edit?usp=sharing

thanks
JMPrieto


2014/1/15 Colm O hEigeartaigh 

> Could you create a test-case that shows the problem?
>
> Colm.
>
>
> On Wed, Jan 15, 2014 at 9:23 AM, José Manuel Prieto <
> joseman...@prietopalacios.net> wrote:
>
> > Unsolved
> >
> > I followed this steps:
> > 0.- Create diferent calls in spring file to DefaultCryptoCoverageChecker,
> > ref, bean, property --> no changes
> > 1.- I create a custom Interceptor --> no changes
> > public class CustomDefaultCryptoCoverageChecker extends
> > DefaultCryptoCoverageChecker {
> >
> > public CustomDefaultCryptoCoverageChecker(){
> > setCheckFaults(false);
> > }
> > }
> >
> > 2.- Change jaxb library version: form jaxb-impl:2.2.5-2 to
> > jaxb-impl:2.1.13. --> no changes
> > 3.- Change spring library version form spring:3.0.5.RELEASE to
> > spring:3.2.6.RELEASE --> no changes
> > 4.- Continuing the trace, I get to:
> > DocLiteralInInterceptor.handleMessage(Message message){
> >...
> >o = dr.read(p, xmlReader); call to -->
> > DataReaderImpl.read(MessagePartInfo part, T reader)
> >...
> > }
> >
> > DataReaderImpl.read(MessagePartInfo part, T reader){
> >return JAXBEncoderDecoder.unmarshall(createUnmarshaller(), reader,
> part,
> >  unwrapJAXBElement);
> > }
> >
> > Who instance JAXB? spring?.
> > Why only one parameter change my wolrd?
> >
> > thanks for readme
> > JMPrieto
> >
> >
> >
> > 2014/1/14 José Manuel Prieto 
> >
> > > Hello,
> > >
> > > If I put property checkFaults="false" (in sringframework application
> > > context file), only SoapFault Messages runs as expected.
> > > My service return a Response object. The service response is 200 (OK),
> > > send me a Response (I see it, in the server-log), my client obtain a
> > > Response object but, all atributes to null.
> > >
> > > I trace until to SoapHeaderInterceptor.handleMessage(Message m). This
> > > methods contains:
> > > public void handleMessage(Message m) throws Fault {
> > > SoapMessage message = (SoapMessage) m;
> > > SoapVersion soapVersion = message.getVersion();
> > > Exchange exchange = message.getExchange();
> > >
> > > MessageContentsList parameters =
> > > MessageContentsList.getContentsList(message);
> > > 
> > >
> > > When checkFaults="true", the var parameters(MessageContentsList) has a
> > > List [size=1] with Response object and atributes with some values.
> > > When checkFaults="false", the var parameters(MessageContentsList) has a
> > > List [size=1] with Response object and atributes to NULL.
> > >
> > > I thought it was a problem with springframework, but now i don´t now.
> > > can anybody help me?
> > >
> > > Thanks in advance
> > > JMPrieto
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Re: wadl2java generates invalid method names

[Sergey Beryozkin]

Can you type a sample fragment ?

I've added



mediaType="application.vnd.myvnd.some-object+xml" 
element="prefix1:thebook"/>
mediaType="application.vnd.myvnd.some-object-v2+xml" 
element="prefix1:theBook2"/>






to a test WADL and all is generated correctly with a 
supportMultipleXmlReps option.


Sergey

On 15/01/14 00:07, tomstark wrote:

I have a particular wadl that has a method that has multiple representations
(different versions of the same object).  Using the -supportMultipleXmlReps,
produces method names that have invalid characters in the name.  The
representations in the wadl are something like this:

application.vnd.myvnd.some-object+xml
application.vnd.myvnd.some-object-v2+xml

The resulting method names are generated with "some-object" and
"some-object-v2" as part of the method name.

Tested this on wadl2java v2.5.2 and 2.7.8.

Similar to issue  https://issues.apache.org/jira/browse/CXF-4932
   but has to do with method
names, not parameters.




--
View this message in context: 
http://cxf.547215.n5.nabble.com/wadl2java-generates-invalid-method-names-tp5738564.html
Sent from the cxf-user mailing list archive at Nabble.com.




--
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com

Question on using CXF STS with 3rd party server without Spring

[Walters, Jay M]

I have poked around a bit and not found a good example of what I need to do to 
get this working. I have a WCF C# webservice I am trying to call.  I have 
working Metro code and also C# code calling the service (a third party 
product), but not getting any traction with CXF.  So far all the examples 
appear to use Spring which I cannot use.

I am trying to use CXF 2.7.8 with JDK 1.6.0_21.

Do I need to instantiate an STSClient object, or does this happen 
automatically?  If automatic, what do I need to configure in order to make it 
work. I have a X509 certificate as a byte stream, I do not have a keystore 
though I suppose I could make it if required to use CXF.

So far I have uses wsdl2java to generate loads of stuff which I try to use as 
follows.

SymbolService_Service factory = new SymbolService_Service();
SymbolService ss = factory.getSymbolServiceHttp();
ArrayOfSymbolContract array = ss.queryForAll();

This yields the following output/trace

[org.apache.cxf.service.factory.ReflectionServiceFactoryBean] - Creating 
Service {...}SymbolService from 
WSDL: http://bosdvpmapp1:8010/VPM/Core/Tables/SymbolService?wsdl
[org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl] - No assertion builder 
for type 
{http://schemas.microsoft.com/ws/06/2004/mspolicy/netbinary1}BinaryEncoding 
registered.
[org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl] - No assertion builder 
for type 
{http://schemas.microsoft.com/ws/2006/05/framing/policy}SslTransportSecurity 
registered.
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider] - 
Failed to build the policy 
'SymbolServiceTcp_policy':org.apache.neethi.builders.PrimitiveAssertion cannot 
be cast to org.apache.cxf.ws.security.policy.model.Token

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: None of the 
policy alternatives can be satisfied.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
at $Proxy44.queryForAll(Unknown Source)
at Client.main(Client.java:112)
Caused by: org.apache.cxf.ws.policy.PolicyException: None of the policy 
alternatives can be satisfied.
at 
org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(EndpointPolicyImpl.java:166)
at 
org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyImpl.java:145)
at 
org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:141)


Thanks for any help

Re: Accessing temporary file name of attachments

[Sergey Beryozkin]

Hi Henry
On 15/01/14 13:53, Henry Clout wrote:

Hi Sergey.

For us at least this wouldn't really address our problem.  Our flow is:

- Content is uploaded to CXF.
- Our service method performs some validation on the input.
- If all is ok, the content is moved to the correct place.

In our case, the correct place is a location on a NAS.  The CXF temp file 
location is also on the NAS   So to go via an InputStream, we have pull the 
data from the NAS across the network into memory, then transfer it out again 
over the network back to the NAS.  Even on a gigabit network, this is a 
significant slowdown for large files vs a file rename, which is what transferTo 
amounts to if the CXF temp directory is placed on the NAS.

Dealing exclusively with InputStreams prevents any kind of file move style 
optimisation.  I agree that this is an application specific optimisation, but I 
guess I thought it would be useful if CXF could allow this kind of 
functionality via some sort of interface to those that would benefit from it.  
My gut feeling was that it wasn't just us who are using CXF to transfer large 
files, so someone else may benefit from this functionality.

As it happens, we've worked around this by using Spring multipart parsing 
within CXF:

@POST
@Path("/kulus/{guid}/media")
public void addMediaToKulu(@PathParam("guid") String guid) throws 
IOException {
MultipartFile multipartFile = null;
if (commonsMultipartResolver.isMultipart(httpServletRequest)) {
MultipartHttpServletRequest multipartHttpServletRequest 
= commonsMultipartResolver.resolveMultipart(httpServletRequest);
Iterator fileNamesIterator = 
multipartHttpServletRequest.getFileNames();
if (fileNamesIterator.hasNext()) {
String firstFileName = fileNamesIterator.next();
multipartFile = 
multipartHttpServletRequest.getFile(firstFileName);
}
}
// We call multipartFile.transferTo(file) later on ...
}

At the end of the day, maybe this workaround is sufficient rather than changing 
the core CXF code.  I guess if you think this functionality wouldn't be useful 
to others, then I'm happy to accept that :-)


What I'm not getting is this:

Suppose CXF will let developers customize the way, or rather, where temp 
files are created and I guess with the option to be notified when a temp 
file needs to be closed. In your case you'd register a handler which 
would ensure that if a temporarily file is needed then it would be 
created immediately in the right place.


So now you have an InputStream, possible completely in the memory and 
may be backed up by a temp file in the right location.


Can you please explain again why that won't be sufficient in your case ?

Thanks, Sergey




Cheers,

Henry



On 15 Jan 2014, at 12:23, Sergey Beryozkin  wrote:


Hi
On 14/01/14 21:19, Henry Clout wrote:

Hi Sergey.

Sure, so long as it's possible for the service implementation to map an 
attachment to the the generated temp file, that'd work.  I guess for the 
particular use case I was describing it's slightly less clean, since the user 
needs to take into account the fact that the data may be in memory rather than 
on disk.  But then having access to the file itself is more flexible.


What I've understood so far is that it is really an issue of the temporarily 
files stored in the locations which make it expensive and may be less secure to 
process the actual attachment stream.

So suppose we have an application code accepting InputStream representing a 
given attachment part. IMHO the application code does not need to know or deal 
with the temporarily file which may have or not been created, the concern of 
the application is to read the available stream; as such I'm not really keen 
too on Attachment offering a transferFile operation, IMHO this is an extra 
concern for the application code :-)

IMHO, offering the developers a chance to customize the way CachedOutputStream 
creates temporarily files will solve the problem under the hood, while the 
application code will just continue processing InputStream the high level way...

Thanks, Sergey




Yours,
Henry


On 12 Jan 2014, at 18:19, Sergey Beryozkin  wrote:


Hi Henry, Dan,

Should we offer an interface for users to create a temporary file instead ?
For example, by default a temp file is created in the system temp drive, 
developers can customize it by creating a temp File in the right location and 
with the more user-friendly name if needed ?

Cheers. Sergey





--

Henry Clout
Software Engineer

Kulu Valley Ltd
91 Goswell Road
London EC1V 7EX

Direct: +44 (0) 207 017 8322
Mobile: +44 (0) 777 576 2963
Office: +44 (0) 207 253 8080
www.kuluvalley.com

—

The Information contained in this e-mail and any attached files are intended 
for the named recipient(s) only

Re: Accessing temporary file name of attachments

[Henry Clout]

Hi Sergey.

For us at least this wouldn't really address our problem.  Our flow is:

- Content is uploaded to CXF.
- Our service method performs some validation on the input.
- If all is ok, the content is moved to the correct place.

In our case, the correct place is a location on a NAS.  The CXF temp file 
location is also on the NAS   So to go via an InputStream, we have pull the 
data from the NAS across the network into memory, then transfer it out again 
over the network back to the NAS.  Even on a gigabit network, this is a 
significant slowdown for large files vs a file rename, which is what transferTo 
amounts to if the CXF temp directory is placed on the NAS.

Dealing exclusively with InputStreams prevents any kind of file move style 
optimisation.  I agree that this is an application specific optimisation, but I 
guess I thought it would be useful if CXF could allow this kind of 
functionality via some sort of interface to those that would benefit from it.  
My gut feeling was that it wasn't just us who are using CXF to transfer large 
files, so someone else may benefit from this functionality.

As it happens, we've worked around this by using Spring multipart parsing 
within CXF:

@POST
@Path("/kulus/{guid}/media")
public void addMediaToKulu(@PathParam("guid") String guid) throws 
IOException {
MultipartFile multipartFile = null;
if (commonsMultipartResolver.isMultipart(httpServletRequest)) {
MultipartHttpServletRequest multipartHttpServletRequest 
= commonsMultipartResolver.resolveMultipart(httpServletRequest);
Iterator fileNamesIterator = 
multipartHttpServletRequest.getFileNames();
if (fileNamesIterator.hasNext()) {
String firstFileName = fileNamesIterator.next();
multipartFile = 
multipartHttpServletRequest.getFile(firstFileName);
}
}
// We call multipartFile.transferTo(file) later on ...
}

At the end of the day, maybe this workaround is sufficient rather than changing 
the core CXF code.  I guess if you think this functionality wouldn't be useful 
to others, then I'm happy to accept that :-)

Cheers,

Henry



On 15 Jan 2014, at 12:23, Sergey Beryozkin  wrote:

> Hi
> On 14/01/14 21:19, Henry Clout wrote:
>> Hi Sergey.
>> 
>> Sure, so long as it's possible for the service implementation to map an 
>> attachment to the the generated temp file, that'd work.  I guess for the 
>> particular use case I was describing it's slightly less clean, since the 
>> user needs to take into account the fact that the data may be in memory 
>> rather than on disk.  But then having access to the file itself is more 
>> flexible.
> 
> What I've understood so far is that it is really an issue of the temporarily 
> files stored in the locations which make it expensive and may be less secure 
> to process the actual attachment stream.
> 
> So suppose we have an application code accepting InputStream representing a 
> given attachment part. IMHO the application code does not need to know or 
> deal with the temporarily file which may have or not been created, the 
> concern of the application is to read the available stream; as such I'm not 
> really keen too on Attachment offering a transferFile operation, IMHO this is 
> an extra concern for the application code :-)
> 
> IMHO, offering the developers a chance to customize the way 
> CachedOutputStream creates temporarily files will solve the problem under the 
> hood, while the application code will just continue processing InputStream 
> the high level way...
> 
> Thanks, Sergey
> 
> 
>> 
>> Yours,
>> Henry
>> 
>> 
>> On 12 Jan 2014, at 18:19, Sergey Beryozkin  wrote:
>> 
>>> Hi Henry, Dan,
>>> 
>>> Should we offer an interface for users to create a temporary file instead ?
>>> For example, by default a temp file is created in the system temp drive, 
>>> developers can customize it by creating a temp File in the right location 
>>> and with the more user-friendly name if needed ?
>>> 
>>> Cheers. Sergey
> 
> 

--

Henry Clout
Software Engineer

Kulu Valley Ltd
91 Goswell Road
London EC1V 7EX 

Direct: +44 (0) 207 017 8322
Mobile: +44 (0) 777 576 2963 
Office: +44 (0) 207 253 8080 
www.kuluvalley.com

—

The Information contained in this e-mail and any attached files are intended 
for the named recipient(s) only. It may contain legal, privileged and/or 
confidential information and if you are not an intended recipient, you should 
not copy, distribute or take any action in reliance on it or disclose its 
contents. If you have received this e-mail in error, please notify the sender 
immediately and then delete it.

Internet e-mail is not a secure medium. Any reply to this message could be 
intercepted and read by someone else. Please bear that in mind when deciding 
whether to send material in response.

Re: Accessing temporary file name of attachments

[Sergey Beryozkin]

Hi
On 14/01/14 21:19, Henry Clout wrote:

Hi Sergey.

Sure, so long as it's possible for the service implementation to map an 
attachment to the the generated temp file, that'd work.  I guess for the 
particular use case I was describing it's slightly less clean, since the user 
needs to take into account the fact that the data may be in memory rather than 
on disk.  But then having access to the file itself is more flexible.


What I've understood so far is that it is really an issue of the 
temporarily files stored in the locations which make it expensive and 
may be less secure to process the actual attachment stream.


So suppose we have an application code accepting InputStream 
representing a given attachment part. IMHO the application code does not 
need to know or deal with the temporarily file which may have or not 
been created, the concern of the application is to read the available 
stream; as such I'm not really keen too on Attachment offering a 
transferFile operation, IMHO this is an extra concern for the 
application code :-)


IMHO, offering the developers a chance to customize the way 
CachedOutputStream creates temporarily files will solve the problem 
under the hood, while the application code will just continue processing 
InputStream the high level way...


Thanks, Sergey




Yours,
Henry


On 12 Jan 2014, at 18:19, Sergey Beryozkin  wrote:


Hi Henry, Dan,

Should we offer an interface for users to create a temporary file instead ?
For example, by default a temp file is created in the system temp drive, 
developers can customize it by creating a temp File in the right location and 
with the more user-friendly name if needed ?

Cheers. Sergey

Re: Error reading XMLStreamReader @ SOAPUI but works fine in browser

[harilal.a.s]

And one more thing that I found is, there is no pay load (for request in WAS
log). So there is no request is coming to application...




--
View this message in context: 
http://cxf.547215.n5.nabble.com/Error-reading-XMLStreamReader-SOAPUI-but-works-fine-in-browser-tp5738545p5738579.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: DefaultCryptoCoverageChecker property checkFaults

[Colm O hEigeartaigh]

Could you create a test-case that shows the problem?

Colm.


On Wed, Jan 15, 2014 at 9:23 AM, José Manuel Prieto <
joseman...@prietopalacios.net> wrote:

> Unsolved
>
> I followed this steps:
> 0.- Create diferent calls in spring file to DefaultCryptoCoverageChecker,
> ref, bean, property --> no changes
> 1.- I create a custom Interceptor --> no changes
> public class CustomDefaultCryptoCoverageChecker extends
> DefaultCryptoCoverageChecker {
>
> public CustomDefaultCryptoCoverageChecker(){
> setCheckFaults(false);
> }
> }
>
> 2.- Change jaxb library version: form jaxb-impl:2.2.5-2 to
> jaxb-impl:2.1.13. --> no changes
> 3.- Change spring library version form spring:3.0.5.RELEASE to
> spring:3.2.6.RELEASE --> no changes
> 4.- Continuing the trace, I get to:
> DocLiteralInInterceptor.handleMessage(Message message){
>...
>o = dr.read(p, xmlReader); call to -->
> DataReaderImpl.read(MessagePartInfo part, T reader)
>...
> }
>
> DataReaderImpl.read(MessagePartInfo part, T reader){
>return JAXBEncoderDecoder.unmarshall(createUnmarshaller(), reader, part,
>  unwrapJAXBElement);
> }
>
> Who instance JAXB? spring?.
> Why only one parameter change my wolrd?
>
> thanks for readme
> JMPrieto
>
>
>
> 2014/1/14 José Manuel Prieto 
>
> > Hello,
> >
> > If I put property checkFaults="false" (in sringframework application
> > context file), only SoapFault Messages runs as expected.
> > My service return a Response object. The service response is 200 (OK),
> > send me a Response (I see it, in the server-log), my client obtain a
> > Response object but, all atributes to null.
> >
> > I trace until to SoapHeaderInterceptor.handleMessage(Message m). This
> > methods contains:
> > public void handleMessage(Message m) throws Fault {
> > SoapMessage message = (SoapMessage) m;
> > SoapVersion soapVersion = message.getVersion();
> > Exchange exchange = message.getExchange();
> >
> > MessageContentsList parameters =
> > MessageContentsList.getContentsList(message);
> > 
> >
> > When checkFaults="true", the var parameters(MessageContentsList) has a
> > List [size=1] with Response object and atributes with some values.
> > When checkFaults="false", the var parameters(MessageContentsList) has a
> > List [size=1] with Response object and atributes to NULL.
> >
> > I thought it was a problem with springframework, but now i don´t now.
> > can anybody help me?
> >
> > Thanks in advance
> > JMPrieto
> >
> >
> >
> >
> >
>



-- 
Colm O hEigeartaigh

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

Re: CXF-Metro WS-SecureConversation Interop issue (CXF client to Metro service)

[Colm O hEigeartaigh]

Hi Cyril,

Thanks for the test-case. The problem is that CXF is using 256 bits as the
keysize, whereas Metro is using 128 bits, hence the signature verification
error. You can adjust CXF by editing the client-cxf.xml file in your
project, + adding the following jaxws:property to the client bean:








Let me know if this doesn't work.

Colm.


On Tue, Jan 14, 2014 at 12:53 AM, Cyril  wrote:

> Hello Colm,
> please find the test case in the zip uploaded here (file size was rejected
> by the mail server):
>
> https://drive.google.com/file/d/0Bx-J-1KEN3jNLWcwVXQ5c3daaGM/edit?usp=sharing
> Filename: cxf-client-metro-wssc-interop-test.zip
>
> It is a maven project with a JUnit test case that launches the Metro
> service in an embedded Jetty, then runs the CXF client against it. Make
> sure the port 8443 is available locally, or change the port in file
> src/test/resources/cxf-client.xml (jaxws:client element) and class
> simple.client.PingServiceClientTest. If this is not what you expect, please
> tell me, as I am not used to create such test cases.
>
> Thanks for reviewing, and sorry for my late reply.
>
> Regards,
> Cyril
>
>
> On Thu, Jan 9, 2014 at 2:48 PM, Colm O hEigeartaigh  >wrote:
>
> >
> > Hi Cyril,
> >
> > Could you create a test-case that reproduces the problem + I will take a
> > look?
> >
> > Colm.
> >
> >
> > On Tue, Jan 7, 2014 at 3:28 PM, Cyril  wrote:
> >
> >> Hello,
> >> I tried with Basic128 to no avail. Please find the client/server logs in
> >> attachment. I have improved the Metro server logs a bit. In particular,
> I
> >> enabled HTTP message dumping there as well to make it easier to
> correlate
> >> client logs with server logs. Besides, you mentioned the fact that the
> >> client and service might be deriving keys differently. Yet, I have no
> >>  assertion in the WSDL. Should there be some key
> >> derivation process happening anyway? I looked for derivation-related
> stuff
> >> in the logs and did not find any. But maybe logs are not detailed
> enough.
> >>
> >> Thanks for your help.
> >>
> >> Regards,
> >> Cyril
> >>
> >>
> >> On Tue, Jan 7, 2014 at 10:58 AM, Colm O hEigeartaigh <
> cohei...@apache.org
> >> > wrote:
> >>
> >>>
> >>> Ok thanks. Could you try changing the two "Basic256" policies in the
> >>> WSDL to "Basic128" + try again to see if it works?
> >>>
> >>> Colm.
> >>>
> >>>
> >>> On Mon, Jan 6, 2014 at 5:09 PM, Cyril  wrote:
> >>>
>  Hello,
>  I've tried again, with CXF 2.7.8 this time. Please find the logs in
>  attachment (zip). The zip contains:
>  - The debug logging on the Metro service side (any log from classes in
>  packages com.sun.xml.ws.*): metro_wsp_requested by_cxf_wsc.log
>  - The corresponding CXF client debug logs: cxf_client.log.
> 
>  Regards,
>  Cyril
> 
> 
> 
>  On Fri, Jan 3, 2014 at 12:50 PM, Colm O hEigeartaigh <
>  cohei...@apache.org> wrote:
> 
> > Hi,
> >
> > Could you try with CXF 2.7.8 to see if it works? Could you also send
> > debug
> > logging of the service side? It looks like the problem might be that
> > the
> > client + service might be deriving the secret keys in different
> ways. I
> > fixed some issues on trunk relating to this, but I'm not sure if
> there
> > were
> > any fixes in 2.7.x or not.
> >
> > Colm.
> >
> >
> > On Thu, Dec 26, 2013 at 1:08 PM, Cyril  wrote:
> >
> > > Hi Dennis,
> > >
> > > Yes, the issue occurs only when calling the service after the
> > security
> > > context token has been successfully obtained.
> > >
> > > 1) If you look for "Outbound Message" from the beginning of the CXF
> > client
> > > log attached, you'll find the first client request which is the
> > RST/SCT
> > > (ID: 1):
> > >
> > > http://www.w3.org/2003/05/soap-envelope
> > "> > > xmlns="http://www.w3.org/2005/08/addressing";>
> > > http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
> >  > > xmlns="http://www.w3.org/2005/08/addressing
> > ">urn:uuid:a052c8f0-184e-43a6-8fb7-d74ca81f3e03 > > xmlns="http://www.w3.org/2005/08/addressing";>
> > > https://localhost:8443/jaxws-sc/simplehttp://www.w3.org/2005/08/addressing";>
> > > http://www.w3.org/2005/08/addressing/anonymous
> >  > > xmlns:wsse="
> > >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> > "
> > > xmlns:wsu="
> > >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> > "
> > > soap:mustUnderstand="true"> > >
> >
> wsu:Id="TS-1">2013-12-19T17:37:08.811Z2013-12-19T17:42:08.811Z > >
> >
> wsu:Id="UsernameToken-2">alice > > Type="
> > >
> >
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> >
> ">ali

handleFault() method not called when exception occurs in handleMessage()

[nikosdim]

Hi

I have an inbound interceptor that performs some actions before invoking my
webservice. In my interceptor I call method from classes that I instantiate
on runtime with Class.forName(cls);

I am currently testing what happens when I give invalid class name in the
cls variable and I noticed that despite the fact that ClassNotFoundException
occurs (which I am catching) the method handleFault() is never called. 

Why is that happening? I've read that handleFault() is called when the
process in the handleMessage is interrupted but what this exactly means?
Isn't an Exception an interruption?

My code:

public class ESMAPISecurityInterceptor extends
AbstractPhaseInterceptor {

public ESMAPISecurityInterceptor(String phase) {
super(phase);
}

@Override
public void handleMessage(Message message) throws Fault {
try {
Class c = Class.forName("an.invalid.class.name");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}

@Override
public void handleFault(Message message) {
System.out.println("Prints from handleFault()");
}
}

Thanks



--
View this message in context: 
http://cxf.547215.n5.nabble.com/handleFault-method-not-called-when-exception-occurs-in-handleMessage-tp5738573.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Message correlation with the JMS transport

[Jens]

Jens wrote
> Assuming there is no way to specify MsgIDAsCorrelID, can the request
> message be modified in an interceptor before the destination gets to
> create the response message? Is the JMSMessage available at that point?

Okay, so an interceptor that erases the correlation ID from the received
request seems to do the trick.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/Message-correlation-with-the-JMS-transport-tp5738552p5738572.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: DefaultCryptoCoverageChecker property checkFaults

[José Manuel Prieto]

Unsolved

I followed this steps:
0.- Create diferent calls in spring file to DefaultCryptoCoverageChecker,
ref, bean, property --> no changes
1.- I create a custom Interceptor --> no changes
public class CustomDefaultCryptoCoverageChecker extends
DefaultCryptoCoverageChecker {

public CustomDefaultCryptoCoverageChecker(){
setCheckFaults(false);
}
}

2.- Change jaxb library version: form jaxb-impl:2.2.5-2 to
jaxb-impl:2.1.13. --> no changes
3.- Change spring library version form spring:3.0.5.RELEASE to
spring:3.2.6.RELEASE --> no changes
4.- Continuing the trace, I get to:
DocLiteralInInterceptor.handleMessage(Message message){
   ...
   o = dr.read(p, xmlReader); call to -->
DataReaderImpl.read(MessagePartInfo part, T reader)
   ...
}

DataReaderImpl.read(MessagePartInfo part, T reader){
   return JAXBEncoderDecoder.unmarshall(createUnmarshaller(), reader, part,
 unwrapJAXBElement);
}

Who instance JAXB? spring?.
Why only one parameter change my wolrd?

thanks for readme
JMPrieto



2014/1/14 José Manuel Prieto 

> Hello,
>
> If I put property checkFaults="false" (in sringframework application
> context file), only SoapFault Messages runs as expected.
> My service return a Response object. The service response is 200 (OK),
> send me a Response (I see it, in the server-log), my client obtain a
> Response object but, all atributes to null.
>
> I trace until to SoapHeaderInterceptor.handleMessage(Message m). This
> methods contains:
> public void handleMessage(Message m) throws Fault {
> SoapMessage message = (SoapMessage) m;
> SoapVersion soapVersion = message.getVersion();
> Exchange exchange = message.getExchange();
>
> MessageContentsList parameters =
> MessageContentsList.getContentsList(message);
> 
>
> When checkFaults="true", the var parameters(MessageContentsList) has a
> List [size=1] with Response object and atributes with some values.
> When checkFaults="false", the var parameters(MessageContentsList) has a
> List [size=1] with Response object and atributes to NULL.
>
> I thought it was a problem with springframework, but now i don´t now.
> can anybody help me?
>
> Thanks in advance
> JMPrieto
>
>
>
>
>