Rampart basic: security processing failed (actions mismatch)
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 my SOATest testing tool and my Axis2/Rampart based clients to be unable to parse the resulting contents. In all cases, the inner elements are not recognized and the clients error out complaining that they were expecting different elements. So I decided to try out the deprecated Rampart configuration model, and I discovered that the resulting encryption doesn’t seem to produce the same error in the responses. After that, I decided to go ahead with that and replaced my Policy-based configurations with the basic configurations completely. However, now I am running into another odd error “WSDoAllReceiver: security processing failed (actions mismatch)”. The odd thing is that the service seems to be handling the request’s security just fine, verifying all signatures, decrypting the message, and then parsing the UsernameToken. Only after going through every feature does it fail like this. The “actions” I list in the InflowSecurity section do actually match what I am sending, so I am unsure why this is happening. Does anyone have any ideas? I’d greatly appreciate your assistance as trying to get Rampart to work properly with my testing tool and clients has been a bit of a struggle for the last few weeks. Below is the information coming from Tomcat’s console (including my own trace messages in the password callback handler): Password Callback Handler called for DECRYPT: wsserver Password Callback Handler called for USERNAME_TOKEN_UNKNOWN: admin [INFO] Verification successful for URI "#id-32295991" [INFO] Verification successful for URI "#id-22237361" [INFO] Verification successful for URI "#id-14067086" [ERROR] WSDoAllReceiver: security processing failed (actions mismatch) org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed (actions mismatch) at org.apache.rampart.handler.WSDoAllReceiver.processBasic(WSDoAllReceiv er.java:344) at org.apache.rampart.handler.WSDoAllReceiver.processMessage(WSDoAllRece iver.java:86) at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java: 72) at org.apache.axis2.engine.Phase.invoke(Phase.java:318) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq uest(HTTPTransportUtils.java:167) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:1 42) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:45 4) at java.lang.Thread.run(Thread.java:595)
RE: Axis2-1.5.1 and user exceptions
In the axis2.xml file on the server/service side, you should see this line: false Set that parameter to "true". Additionally, you might want to change this parameter as well: false Setting that to "true" should force more stack trace detail to be sent along with it, including the details of the root cause exception. -Original Message- From: glopezm [mailto:gmlopez.mackin...@gmail.com] Sent: Monday, February 15, 2010 8:32 PM To: axis-user@ws.apache.org Subject: Axis2-1.5.1 and user exceptions Hi, I'm using axis2 v1.5.1 as it is stated in the subject of this message and I've found that user exceptions are not being reported as they used to be with axis1. If one declare an operation throwing an exception, whenever the exception is thrown the detail part of the soap fault element used to be populated by axis1 with all exception data. However it is not working (at least in this way) anymore. The tag is empty. There is a bug that was filed almost two years ago (https://issues.apache.org/jira/browse/AXIS2-3443) which explains the situation very clearly but it has not even been assigned yet! Now I'm wondering whether someone is aware of a workaround to overcome this issue since it does not happen that the bug will be corrected anytime soon :-(. Thanks in advance for your help! -- View this message in context: http://old.nabble.com/Axis2-1.5.1-and-user-exceptions-tp27602949p27602949.html Sent from the Axis - User mailing list archive at Nabble.com.
RE: Strange issue with Axis2 setting improper default namespaces in responses
So I tested an existing client written using Axis2 1.4.1 and Rampart 1.4
against the Web service today written using Axis2 1.5.1 and Rampart 1.5. With
encryption and signature turned off things went fine, but when encryption and
signature were turned on, the client sent a proper request that was understood
by the server, but the response sent by the server caused the client to error
out with "Expecting one of {classList}".
This is almost certainly due to the fact that "classList" is supposed to have
the empty default Namespace, but Axis2 1.5.1 and Rampart 1.5 are changing that
namespace to the parent namespace of
"http://atrium.bmc.com/2009/01/classes/types"; on encrypting and signing the
body.
I am relatively sure this isn't correct behavior, but I am unable to get the
Axis2 1.5.1/Rampart 1.5 combo to work differently. Is this a known issue with
Rampart? Has anyone run 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 default namespaces in
responses
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 the
testing tool we use during dev. The old tool is properly setting the default
namespace to child elements to empty, which allows the responses to be properly
handled by the clients. However, the Axis2 services seem to be setting the
default namespace in each case to the parent namespace. This causes validation
of the responses against the WSDL and the schemas to be incorrect.
So then I decided to see what happens in the Axis2-based responses when I turn
security off and just accept a UsernameToken without encryption or signature.
Turns out the response is just fine when I do that, as this snippet shows:
http://atrium.bmc.com/2009/01/classes/types";>
BMC.CORE
BMC_Mainframe
BMC.CORE
BMC_Printer
http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
However, the minute I turn the Signature and Encryption components on in the
Rampart configuration, I get the bad behavior again, as shown here:
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE'
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC_Mainframe
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE
http://atrium.bmc.com/2009/01/classes/types";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Strange issue with Axis2 setting improper default namespaces in responses
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 the testing tool we use during dev. The old tool is properly setting the default namespace to child elements to empty, which allows the responses to be properly handled by the clients. However, the Axis2 services seem to be setting the default namespace in each case to the parent namespace. This causes validation of the responses against the WSDL and the schemas to be incorrect. So then I decided to see what happens in the Axis2-based responses when I turn security off and just accept a UsernameToken without encryption or signature. Turns out the response is just fine when I do that, as this snippet shows: http://atrium.bmc.com/2009/01/classes/types";> BMC.CORE BMC_Mainframe BMC.CORE BMC_Printer http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/> However, the minute I turn the Signature and Encryption components on in the Rampart configuration, I get the bad behavior again, as shown here: http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE' http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC_Mainframe http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC_Printer http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/> http://atrium.bmc.com/2009/01/classes/types"; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/> So it seems to be not so much a problem with Axis2 as it is with Rampart. In every case, the xmlns default namespace of child elements are listed as the full namespace of the parent when Rampart Signature/Encryption are turned on, but are set properly when it is not. As a result, our stricter clients are failing right away because they see the message as incomplete. Am I missing something here? Is there an option in Rampart to rectify this? I am using Axis2 1.5.1 with Rampart 1.5.
RE: Initializing Web Service (Server) before first request received
In your services.xml file, add 'scope=" application"' to the "service" element, as follows: The service will then be deployable in application mode. Now a question to Deepal... will this actually load the implementation class immediately on deployment and thus cause all static initialization in the class to take place? I know that application mode will cause Axis2 to treat the implementation class as a singleton and reuse the same instance for each service call, but I was still under the impression that it would require that first service call to be made still. If the class is loaded on deployment or the singleton is constructed prior to the first service call, then that is definitely good news. -Original Message- From: Oded Onn [mailto:oded@mobixell.com] Sent: Wednesday, February 10, 2010 3:21 AM To: axis-user@ws.apache.org Subject: RE: Initializing Web Service (Server) before first request received Deepal, Can you please elaborate a bit more. I am not sure I quite understand what you mean. Thanks, Oded -Original Message- From: Deepal Jayasinghe [mailto:dee...@opensource.lk] Sent: Wednesday, February 10, 2010 00:58 To: axis-user@ws.apache.org Subject: Re: Initializing Web Service (Server) before first request received Deploy there service in Application scope. Thanks, Deepal > > Hi all, > > > > I am deploying an AXIS2 web service (server side). > > > > My problem: The skeleton class (the one that performs all the business > logic) is read for the first time only when the first request is > received by the server. It means that the first response takes a > really long time (up to 20 seconds on a weak machine) since there are > a lot of initialization I have to perform (static init). > > > > Solution: I am assuming I can write some sort of a main class that > will try to call the skeleton class. This is not only ugly but also > prone to all sorts of errors. Is there a proper way to init my service > class? I would expect some mechanism to be used, such as utilizing the > servlet init of the axis servlet. > > > > Anyone? Thanks! > > Oded > -- Thank you! http://blogs.deepal.org http://deepal.org
RE: Inaccessible WSDL files after enabling both HTTP and HTTPS in Axis2/Tomcat
Thanks for the information. I am glad to hear it is fixed in the main trunk, which I hope means it will make it into the next version of Axis2. For the time being I've implemented my own logic to create these files at deployment time by modifying the original WSDL file to contain the policy reference, the policy statements, and the modified service endpoint. They will just have to be accessible for now from the "http(s)://host:port/axis2/services/service/service.wsdl" format. -Original Message- From: Andreas Veithen [mailto:andreas.veit...@gmail.com] Sent: Monday, February 08, 2010 8:44 AM To: axis-user@ws.apache.org Subject: Re: Inaccessible WSDL files after enabling both HTTP and HTTPS in Axis2/Tomcat Michael, This looks like another example of the issue described in AXIS2-4465. Not sure if it is possible to make this work properly in 1.5.1, but in the current 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 wrote: > 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 > port is 8443. They are running on a 1.5 JRE. > > > > Doing so seems to work ok. The Web services are all accessible at both the > HTTP and HTTPS endpoints, so there seems to be no real issue there. > However, the WSDL and XSD files are inaccessible. The same endpoints that > allow SOAP requests no longer allow any of these "GET" requests to access > WSDL and XSD files: "?wsdl", "?wsdl=somefile.wsdl", "?xsd=somefile.xsd". > In all cases, I get the message "Internal server error". This happens > whether or not I use the HTTP or HTTPS endpoints to access them. Note that > I can still access these files directly by simply adding "/somefile.wsdl" > to the end of the endpoint, but this is undesirable in the case of the main > WSDL of the service as the service endpoints are not replaced properly. > > > > Note that this happens whether or not I explicitly declare the available > transports in services.xml for the services in question. I found a FAQ > somewhere that said I needed to make sure that xalan-2.7.0.jar was copied > into the lib directory of the war distribution, but that file is already > there. > > > > Is there something else I need to do here to make this work? Or is this a > known issue that cannot be worked around at this time?
Inaccessible WSDL files after enabling both HTTP and HTTPS in Axis2/Tomcat
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 port is 8443. They are running on a 1.5 JRE. Doing so seems to work ok. The Web services are all accessible at both the HTTP and HTTPS endpoints, so there seems to be no real issue there. However, the WSDL and XSD files are inaccessible. The same endpoints that allow SOAP requests no longer allow any of these "GET" requests to access WSDL and XSD files: "?wsdl", "?wsdl=somefile.wsdl", "?xsd=somefile.xsd". In all cases, I get the message "Internal server error". This happens whether or not I use the HTTP or HTTPS endpoints to access them. Note that I can still access these files directly by simply adding "/somefile.wsdl" to the end of the endpoint, but this is undesirable in the case of the main WSDL of the service as the service endpoints are not replaced properly. Note that this happens whether or not I explicitly declare the available transports in services.xml for the services in question. I found a FAQ somewhere that said I needed to make sure that xalan-2.7.0.jar was copied into the lib directory of the war distribution, but that file is already there. Is there something else I need to do here to make this work? Or is this a known issue that cannot be worked around at this time?
Two questions about security features
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", "EncryptedSupportingTokens", and "SignedEncryptedSupportingTokens". However, if any variation of the "SupportingTokens" element is used to specify a UsernameToken be sent to the service, none of them actually seem to be enforced on the service-side in the same way. This means if I use "SignedSupportingTokens" to specify UsernameToken, the service does not require that the client actually sign its UsernameToken in the request. Similarly, "EncryptedSupportingTokens" and "SignedEncryptedSupportingTokens" do not enforce encryption. When the "EncryptedParts" element is used to specify that the SOAP Body should be encrypted, it returns an error "The signature or decryption is invalid" when a message is sent to it without the SOAP Body encrypted. However, when I specify the UsernameToken with the Name and Namespace fields of the "EncryptedParts" element, the same sort of enforcement doesn't happen. Is there any way at all to enforce UsernameToken encryption in Rampart outside of writing my own module to do the enforcing? (2) We use UsernameToken in PasswordText encoding to send credentials to pass to the underlying application. However, we also add Nonce and Created. We realize this is not required by PasswordText encoding, but it isn't disallowed by the standard (the word "SHOULD" is used to describe the addition of these values when using PasswordText encoding). What we could like to do is enforce the uniqueness of the combination of Nonce and Created values when they are passed in. Now I realize that this is not something Rampart will do automatically, so I'd like to retrieve the decrypted message at runtime, perhaps from the password callback class, retrieve those values from that message and enforce their uniqueness there. Is it possible to retrieve the decrypted SOAP header so that I could look for the proper values inside of the implementation of the password callback class? If not, is it possible to do from the implementation of each Web service? I guess if those are not possible, I could write a module to do this. We were trying to avoid having to do this though because I perceive it would add more processing time. (3) If I have to write modules for 1 and 2, then I would likely have to position the first one to be executed before the rampart module is executed and the message decrypted, and the latter one to be executed after the rampart module does this decryption. How would I modify the configuration to allow one module to be executed before Rampart and one to be executed after? Any help you could give me would be greatly appreciated at this point. I've looked as hard as possible for answers to these things on the net and through two Axis2 books I purchased, but I can't seem to find complete information.
RE: Preventing Axis2/Rampart from encrypting faults
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, Michael mailto:michael_doug...@bmc.com>> wrote: 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 right now is in the fault messages being sent from the service. In our previous implementation, Fault messages were never signed and encrypted. However, in this Axis2 version they are always signed and encrypted. I've tried a few things I've seen from Google searches to see if I can prevent this. One of them was to remove the security phase from the OutFaultFlow section of the axis2.xml file in the WEB-INF/conf directory. However, this causes the Axis2 bundle to fail to load properly. Is there any way to prevent the faults from being signed and encrypted while still allowing the standard outbound messages to be signed and encrypted? you can unpack the rampart.mar file and edit the module.xml file so that no handlers goes to outFaultFlow. Then recreate the mar file. This won't create any problem when loading modules. thanks, Amila. -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
Preventing Axis2/Rampart from encrypting faults
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 right now is in the fault messages being sent from the service. In our previous implementation, Fault messages were never signed and encrypted. However, in this Axis2 version they are always signed and encrypted. I've tried a few things I've seen from Google searches to see if I can prevent this. One of them was to remove the security phase from the OutFaultFlow section of the axis2.xml file in the WEB-INF/conf directory. However, this causes the Axis2 bundle to fail to load properly. Is there any way to prevent the faults from being signed and encrypted while still allowing the standard outbound messages to be signed and encrypted?
RE: wsdl2java -R option
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: u...@xmlbeans.apache.org; axis-user@ws.apache.org Subject: wsdl2java -R option Has anybody used -R option in wsdl2java codegeneration with xmlbeans binding, I am using Axis1.5.1 ? here is my command line... wsdl2java -uri d:\test.wsdl -d xmlbeans -o d:\src -p com.axis.test -R d:\resourceTest It throws following exception... org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException running same command without -R flag generates code successfully. Thanks, Rahul Yadav
OFFLIST RE: [axis2] axis2c memory management process unclear
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, January 15, 2010 12:50 PM To: axis-user@ws.apache.org Subject: [axis2] axis2c memory management process unclear we're using axis2 to consume soap services. this function axiom_node_to_string AXIS2_EXTERN axis2_char_t *AXIS2_CALL axiom_node_to_string( axiom_node_t * om_node, const axutil_env_t * env); declared in \axiom\include\axiom_node.h and defined in \axiom\src\om\om_node.h returns a different address each time I call it, indicating it might be dynamically allocated memory. but when I try to free it, I get errors. I can't find any documentation on how this memory might be freed. is it the job of axiom_node_free_tree()? any insight anyone can provide would be helpful.
Web service init and Custom endpoints with Tomcat/Axis2 1.5.1
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 are stateful in a sense -- they have a status and can be modified over time, meaning that the same event can be sent out multiple times with updated information. The problem we are running into is that the Web service code is never unless a client request is made to the service to either subscribe or poll for events. This means that until a request is made, clients that consume events in the push model rather than the pull model won't receive events until a client that receives events through the pull model makes a request because the data and processes needed for this activity won't start until that time. Another reason is for persistency in case the server goes down. Since the eventing service saves persistent events on the service side in case the events did not send to cell or events did not retrieved by the clients. If the eventing service restarts, it should load the events and attempted to send to cell without a dependency on receiving a request from a client. The second issue I have is that I need to be able to customize my endpoint address in Axis2 running in the WAR distribution on Tomcat. I know that I can change the "contextRoot" root property without changing the corresponding property in the axis2.xml file in the WEB-INF/conf directory because Tomcat treats the context root as the name of the directory in its "webapps" directory instead. However, I also need to change the "servicePath" property to be "server" instead of "services". The reason for this is that we are translating an entrenched legacy Web service from another Web service stack to Axis2, and several customers have integrated with that Web service using a hardcoded path that fits the previous Web service stack's convention for forming endpoints. The problem is that when I change the axis2.xml file's "servicePath" property, it only seems to affect the main services page's links to the WSDL files of each service. Those links are broken, because though they are listed as "server" as I specified, the Web services and WSDL files are still only accessible from the address when "services" is the "servicePath" in the endpoints, not "server". Is this a bug? Is there any way to fix this so that we can make this work for a whole set of customers without requiring them to recode?
