There are actually two things: 1. Neethi 2 (which is used in Axis2 1.5.x and 1.6.0) is much more lenient and parses certain invalid policies without throwing an exception. Neethi 3 (which is used starting with Axis2 1.6.1) no longer accepts those policies and triggers the exception that you are seeing.
2. When generating client code, Axis2 doesn't simply copy the policy from the WSDL. It actually re-serializes the model created by Neethi from the original policy. The problem is that in all released Rampart versions (i.e. all versions up to and including 1.6.1), the code responsible for serializing the policy has some issues that cause it to produce invalid serialized policies in some cases. These invalid policies are accepted by Neethi 2, but not by Neethi 3. That problem has been fixed in Rampart 1.6.2-SNAPSHOT and 1.7.0-SNAPSHOT. Therefore the problem should only exist in Axis2/Rampart 1.6.1. Work on the 1.6.2 releases will start soon, but there are no plans for 1.7.0. Therefore you should test your code with 1.6.2-SNAPSHOT and report if there are still issues (so that there is a chance to get them fixed before the release). Andreas On Thu, Apr 12, 2012 at 23:51, Gordon2 <gordon_dak...@yahoo.com> wrote: > Jaime, > > I got the latest axis2-1.7.0 and rampart snapshot using maven, and I found > that my client actually succeeds in adding the UsernameToken security > policy, which it fails to do in 1.6.1 (for me at least). I see axis2-1.7.0 > uses neethi 3.0.2, and axis2-1.6.1 uses 3.0.1. I don't know if that > accounts for why my error occurs with 1.6.1, but not 1.7.0. > > Using the debugger, I get these 2 parsing behaviors, when the parser reaches > the SupportingTokens element, which contains the Policy that contains the > UsernameToken: > > With 1.7.0: > > SupportingTokensBuilder.build receives the SupportingTokens element, and > UsernameTokenBuilder.build returns a UsernameToken with no problem. > > With 1.6.1: > > SupportingTokensBuilder.build receives the Policy containing the > UsernameToken (instead of the SupportingTokens itself), and it calls > PolicyEngine.getPolicy for the Policy's child UsernameToken. That leads to > PolicyBuilder.processOperationElement calling isInPolicyNS, which complains > that UsernameToken's namespace is not one of the 3 policy namespace in > Constants.java. > > With 1.5.1, neethi 2 doesn't check the UsernameToken's namespace, and > parsing succeeds. > > Is UsernameToken definitely known to work on the client side with 1.6.1? If > so, maybe my system isn't configured correctly with 1.6.1. > > BTW, do you know roughly when 1.7.0 will be released? > > Gordon > > > Jaime Hablutzel Egoavil wrote >> >> I had a similar problem to this... but this was happening in axis2 1.4 and >> it got fixed in newer versions... your problem seems to be different.. >> altought UsernameToken is well supported... I'm not sure about your >> problem, but I suggest you a couple of things, first try stepping with a >> debugger through >> >> org.apache.neethi.PolicyBuilder.getPolicyOperator(PolicyBuilder.java:177) >> >> download the source for that (if using maven that is really easy) and >> check >> around, check well the versions for libraries you are using... specially >> neethi version for your axis2 version. >> >> Another suggestion would be to download the last development version of >> axis from their subversion trunk and try using that... it is packaged with >> maven so if you know maven you won't have too much problems. >> >> GOod luck >> >> > > > -- > View this message in context: > http://axis2.867.n6.nabble.com/Policy-not-supported-is-it-a-bug-tp4340911p4865622.html > Sent from the Axis2-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
