Ah no, the sealing violation was just because I now had three sets of opensaml jars from previous builds. The failure is due to a conflict with our processing and Compare plaintext UsernameToken passwords and stop trusting bare BSTs
I'll have a poke. We have a registered Callback class for processing UNTs, the flow I was using to test the concurrency issue happened to be one of the UNT tests. cheers, Andreas From: Andreas Martens <[email protected]> Date: Tuesday, 13 October 2026 at 08:43 To: [email protected] <[email protected]> Subject: [EXTERNAL] RE: [Axis2] Removal of TargetResolver in Axis2 core 2.0.1 This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-_FVHVY-Xk9bWls5ToTgMNKVbVwpK4Z8NWIQu8bTWe0ZzU9DhTMxIJLuZPYyM-1V-pQbvpYRA1qWJ-HXR_SuiTGfngffrCV8iG9vSpSjgCq9olaFvwMJRrE-Vv8ppvJ_jzPTLZhRvUA$> Thanks Robert, Part of me wants to run screaming into the hills, and part of me thinks "yeah, that sounds great". I'll need to run it past legal to ensure I have permission, but the answer from them is usual a resounding yes. We used to take our copy of Sandesha from another IBM product (who took a copy of the OS version decades ago), but they're ditching Axis2 in favour of CXF. We (I) decided to stick with Axis2. There's another IBM (now) product also using an Axis2, but they took 1.8.2 and "customised" it and I think they're just going to sit on that till "the end". On a related note, Rampart seems to break with the latest initialization changes with a sealing violation, putting some more debugging in to see the path. cheers, Andreas From: robertlazarski <[email protected]> Date: Monday, 12 October 2026 at 15:38 To: [email protected] <[email protected]> Subject: [EXTERNAL] Re: [Axis2] Removal of TargetResolver in Axis2 core 2.0.1 Hello, welcome to the Axis2/Java community. The last commit to Sandesha was over 12 years ago. I myself never used Sandesha. I saw your PR last week to resurrect it. We actually were planning to move sandesha to the attic this quarter - the Apache equivalent of EOL. I had Claude take a look, see AI generated response below. The bottom line in Apache projects is the 3 active member requirements. Short answer: the ContextListener approach should work, and the switch to the OperationContext is what makes it work. Sandesha's TargetResolver never resolved a target. It only set USE_ASYNC_OPERATIONS and DISABLE_RESPONSE_ACK to false on messages not covered by RM, overriding the true that SandeshaModule sets on the ConfigurationContext. TargetResolver was removed in 2.0.1 with the clustering code (AXIS2-6097). A ContextListener that handles creation of an OperationContext can do the same thing. When it fires, the OperationContext already has its AxisOperation and ServiceContext, so the global, service and operation engagement checks all still work. MessageContext.getProperty() checks the message, then its Options, then the OperationContext, before falling back to the ConfigurationContext, so false set on the OperationContext overrides the configuration-level true for every message in that operation. Reacting to MessageContext creation would not work, because at that point the service and operation are not set yet. One edge case for your regression run: a message context with no OperationContext falls through to the ConfigurationContext and sees true. Some things that affect the PR: - PR #4 builds against Axis2 2.0.0, which still had TargetResolver, so it will not compile against 2.0.1 or the upcoming 2.0.2. The ContextListener change needs to go into the PR. - Axis2 2.0.2 refuses decoupled WS-Addressing responses by default. Async RM depends on them, so you will need allowNonAnonymousResponseEndpoints=true in axis2.xml, and httpFrontendHostUrl set to your external URL. Please also test acks to a non-anonymous AcksTo. The 2.0.2 release notes cover the details. - On getting axis2, rampart and sandesha to agree: Rampart 2.0.0 is not released yet, and its master builds against Axis2 2.0.1. The order is Axis2 2.0.2 (in progress now), then Rampart 2.0.0, then Sandesha. None of them can be released against SNAPSHOT dependencies. On Sandesha itself: it has had no release or active maintainer for over a decade, and the PMC has been discussing retiring it. I'd much rather keep it, and you are the first person in years to turn up with both a need for it and a working patch. An Apache release needs three binding +1 votes from PMC members, so Sandesha needs someone on the inside to look after it. Would you be willing to become a committer? Your PR is enough for us. If you say yes, I'll start a vote here on the dev list, and once it passes you file an Individual Contributor License Agreement (ICLA) with the ASF and your account gets set up. That is the whole process. You could then merge Sandesha work yourself, and joining the PMC later would give you a binding vote on its releases. Regards, Robert On Mon, Oct 12, 2026 at 3:12 AM Andreas Martens <[email protected]> wrote: > > Hi all, > > First email to the mailing list, forgive me (and correct me) if I get > something wrong (I can’t seem to find an option to send an email as > plain-text in Outlook for Mac, even CoPilot can’t find it). > > Quick question on the AXIS2-6097 Change in > https://github.com/apache/axis-axis2-java-core/commit/e6f53b230bddcb40577c84ff290ba51e7265fa15#diff-01575283d2d0988dea113ae3b9f40b50069d55fb8751841ec3039d54ab896dd9 > > The TargetResolver class has been removed, which breaks Sandesha as it uses a > TargetResolver to turn off async behaviour for outgoing messages that don’t > need RM. > > My LLM (Bob) says I can work around it by switching to using a Context > Listener instead of a TargetResolver. The bit about the code change that > worries me the most is that it has changed the code from using the > Configuration Context on the messageContext to using the operationContext. I > haven’t yet run it through our regression test system (maven isn’t my forte > and trying to get a version of axis2+rampart+sandesha that are happy together > appears to be more of an art form than I expected), so I was wondering if > anyone could think of a reason it wouldn’t work? > > Cheers, > Andreas Martens > -- > Senior Engineer > IBM App Connect Enterprise > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 > Registered office: Building C, IBM Hursley Office, Hursley Park Road, > Winchester, Hampshire SO21 2JN --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
