Hi,
It seems that classloader takes other Neethi jar anyway.
I would firstly look for Neethi class (AssertionBuilderFactory.class) to
determine where it really loaded and ask WAS forums how to avoid that.
Regards,
Andrei.
-Original Message-
From: ganeshatmail
Hi,
You can try the same way as WSS4JInInterceptor does:
private SOAPMessage getSOAPMessage(SoapMessage msg) {
SAAJInInterceptor.INSTANCE.handleMessage(msg);
return msg.getContent(SOAPMessage.class);
}
Regards,
Andrei.
-Original Message-
From: Faz
Thank you Andrei, of course you were right.
I've Base64 encoded my credentials and now i see ApplicationPolicy and
NamePasswordCallbackHandler initialized correctly.
...
URL myURL = new URL(serviceURL);
HttpURLConnection myURLConnection =
(HttpURLConnection)myURL.openConnection();
String
You can use the technique described in:
https://issues.apache.org/jira/browse/CXF-4424
to override appserver libraries.
(Although you need to override neethi - not jaxb - it seems)
2014/1/13 Andrei Shakirin ashaki...@talend.com
Hi,
It seems that classloader takes other Neethi jar anyway.
Thanks Sergey,
Your information was helpful and I narrowed the problem down to the
-Djava.security.auth.login.config environment variable not being configured
in my environment, setting this has got everything working.
Note that I do get the same exception even though it's working, it appears
to
Hi,
On 13/01/14 10:46, Paul O'Brien wrote:
Thanks Sergey,
Your information was helpful and I narrowed the problem down to the
-Djava.security.auth.login.config environment variable not being configured
in my environment, setting this has got everything working.
Note that I do get the same
Dan,
You're right, it was the byte array that was becoming too big.
After I commented out the first send to server and the MTOM client code
seems to send file,
as you said , now the OOM error has moved to server .
However - I am still splitting my hair to see what wrongdoing I did in my
Thanks Daniel for your reply
My testing enviroment was
Java: version 1.6.0_24, vendor Sun Microsystems Inc.
-XX:MaxPermSize=128m
-Xmx1024m
-Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=true
Tomcat 6.0.23 + Apache CXF 2.7.8 + WS Addressing enabled
Can you capture both
Thanks for this. I finally had some time to look into this and by ensuring
that the CXF runtime is picked up rather than the Axis2 runtime has resulted in
the problem being resolved.
However, I am interested in finding out what the problem with the Axis2
implementation is in this case, as we
On Jan 13, 2014, at 7:13 AM, Jose María Zaragoza demablo...@gmail.com wrote:
?xml version=1.0 encoding=utf-8 standalone=yes?
SOAP-ENV:Envelope
xmlns:add=http://schemas.xmlsoap.org/ws/2004/08/addressing;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
2014/1/13 Daniel Kulp dk...@apache.org:
These are showing that the RelatesTo header wasn’t there or similar as it
couldn’t correlate the response message to a request.That is certainly
the cause of the “leak” as the WS-Addressing stuff is not seeing a proper
response to the request.
On Jan 13, 2014, at 2:52 PM, Jose María Zaragoza demablo...@gmail.com wrote:
2014/1/13 Daniel Kulp dk...@apache.org:
These are showing that the RelatesTo header wasn’t there or similar as it
couldn’t correlate the response message to a request.That is certainly
the cause of the
On Jan 13, 2014, at 6:39 AM, yogesh...@yahoo.com wrote:
Dan,
You're right, it was the byte array that was becoming too big.
After I commented out the first send to server and the MTOM client code
seems to send file,
as you said , now the OOM error has moved to server .
However - I am
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
14 matches
Mail list logo
