Hey guys, as I mentioned in the last request I sent to the list, I was unable
to make use the Policy-based Rampart configuration due to the malformation of
the SOAP messages – Rampart seems to have replace all empty default namespaces
with the parent element’s default namespace, causing both
In the axis2.xml file on the server/service side, you should see this line:
parameter name=sendStacktraceDetailsWithFaultsfalse/parameter
Set that parameter to true.
Additionally, you might want to change this parameter as well:
parameter
into this before? Is there any way to work around the
issue and make the responses preserve the proper default namespaces?
From: Doughty, Michael [mailto:michael_doug...@bmc.com]
Sent: Sunday, February 14, 2010 12:57 AM
To: axis-user@ws.apache.org
Subject: Strange issue with Axis2 setting improper
We've been porting our Web services from another provider to Axis2. Both
support XML bean bindings, and we used them in our original implementation, so
that has made the porting easier than it would have been otherwise.
However, I've run into an odd issue that I haven't caught up to now using
In your services.xml file, add 'scope= application' to the service element,
as follows:
service name=***your service name*** scope= application
The service will then be deployable in application mode.
Now a question to Deepal... will this actually load the implementation class
immediately on
I have three questions that I need some information on. One of them is on
Rampart, and one on Axis2, and one on a particular scenario of the first two
questions.
(1) I've noticed that Rampart seems to support the WS-SecurityPolicy 1.0
tokens SupportingTokens, SignedSupportingTokens,
I have a problem that I am hoping someone could shed some light on.
I have enabled both HTTP and one-way HTTPS in my Tomcat 6 instance. Likewise,
I have added the correct configuration information to my axis2.xml in the war
distribution of Axis2 1.5.1. The HTTP port is 8080 and the HTTPS
trunk the configuration mechanism to enable HTTP and HTTPS
in a servlet environment is much more transparent (and known to work
properly).
Andreas
[1] http://people.apache.org/~veithen/axis2/1_6/servlet-transport.html
On Mon, Feb 8, 2010 at 14:10, Doughty, Michael michael_doug...@bmc.com wrote:
I
We've rewritten several of our services from another Web services stack to
Axis2 1.5.1. We are using Rampart 1.4 to handle the WS-Security 1.0
functionality from our previous services.
There have been a few differences though and I am unable to resolve some of
them. The most important one
That seems to have worked. Thanks very much for your help.
From: Amila Suriarachchi [mailto:amilasuriarach...@gmail.com]
Sent: Sunday, February 07, 2010 9:46 PM
To: axis-user@ws.apache.org
Subject: Re: Preventing Axis2/Rampart from encrypting faults
On Mon, Feb 8, 2010 at 7:25 AM, Doughty
I use the -R option in Axis 1.5.1 and it works ok for me. However, I supply a
relative path. If I try to supply an absolute path as you have here, I get a
CodeGenerationException.
From: rahul yadav [mailto:rahulyada...@gmail.com]
Sent: Wednesday, January 27, 2010 5:07 AM
To:
Just an FYI, since you are talking about Axis2/C, you need to go to the Axis2/C
user list for an answer. The address for that is axis-c-u...@ws.apache.org.
You may need to subscribe first though.
-Original Message-
From: Brody Lodmell [mailto:brodylodm...@gmail.com]
Sent: Friday,
I mistakenly sent this request to the Rampart list last time. Hopefully this
list is the correct one.
The first issue I have is with Web service initialization using AXIS2. We have
an eventing service which keeps persistent data on events serialized to disc.
We do this because our events
when signing the Body
Hi,
Can you send the client code?
Regards,
Shankar
On Thu, Oct 15, 2009 at 4:38 PM, Doughty, Michael
michael_doug...@bmc.com wrote:
Just a follow-up here on the problem. I did a bit of searching around on
this and I found the following from a user having almost exactly
I am trying to write a client to consume a set of about 15 Web services secured
by an implementation of the WS-Security 1.0 standard. These Web services
require a usernametoken, that the content of the body be signed and encrypted,
and that the entire usernametoken element be encrypted as
Responses below marked with [mdoughty]:
-Original Message-
From: uthaiyashan...@gmail.com [mailto:uthaiyashan...@gmail.com] On Behalf Of
Uthaiyashankar
Sent: Wednesday, July 29, 2009 1:50 AM
To: Apache AXIS C User List
Subject: Re: Applying Nonce and Created to PasswordText UsernameToken
16 matches
Mail list logo
