Crypto Factories via Function instead of Supplier?

[wjans]

Hi @phax ,

The com.helger.phase4.servlet.AS4XServletHandler currently accepts a Supplier<? extends IAS4CryptoFactory>. If I understand correctly, this has been implemented to allow for resolving a crypto factory for each incoming document.

Would it be an idea/feasible to also accept a Function to which the request context can be provided? Something like Function<? extends IRequestWebScopeWithoutResponse, ? extends IAS4CryptoFactory> ?

This could be nice in scenario's where providing the correct crypto factory would rely on the incoming document request.

[phax]

@wjans thank you for your suggestion. That nicely fits into the recent requests for being better able to support different AS4 profiles for different use cases in the same solution.

However, the AS4XServletHandler is only the wrapper for the AS4RequestHandler to deal with the Servlet specific API. In other scenarios (like when running as AWS Lambda) there is no Servlet specific binding available.

But for the majority of cases, like for Spring Boot or classical WAR based applications it might be a good choice.
I will need to find a way to make all of the parameters of AS4RequestHandler more easily customizable in a nice way, and that would be one option. So please stay tuned and also monitor the respective Wiki page https://github.com/phax/phase4/wiki/Multi-Profile-Handling

[phax]

@wjans Okay, I think I thought it through properly and I think here's my proposal, which unfortunately would be API breaking so I can't implement it easily:

• Instead of passing all necessary parameters into the AS4RequestHandler constructor, I will create a default constructor and use getters and setters for the members instead - as this is the "framework independent handler" it adds general flexibility, without affecting existing users that are happy with the way it is
• That way, all the parameters become accessible via the IHandlerCustomizer as well
• Eventually I will rework the AS4XServletHandler totally, to remove all the setters for the "default" values and instead totally rely on the "per request" configuration

This would all be something for v3.

As the total amount of breaking changes collected over time seems to be large enough now, I tend to make a final 2.8.2 release and then move over to v3 to implement the proposed changes.

Any comments are appreciated

[phax]

Okay, so now the current main branch v3 should be usable in that regard.
All the setters from AS4XServletHandler were removed, and only AS4RequestHandler has all the setters.
This means that via the IAS4RequestHandlerCustomizer you can set all the parameters you need in one place. Hope that suits you

[wjans]

@phax Thanks for the quick analysis and implementation! It looks like this covers our needs just fine. If I understand correctly, the AS4RequestHandler being passed to the customizer is always scoped to a single request? So we could do something like this?

as4XServletHandler.setRequestHandlerCustomizer(new IAS4ServletRequestHandlerCustomizer() {
  @Override
  public void customizeBeforeHandling(@Nonnull IRequestWebScopeWithoutResponse aRequestScope, @Nonnull AS4UnifiedResponse aUnifiedResponse, @Nonnull AS4RequestHandler aRequestHandler) {
    IAS4CryptoFactory cryptoFactory = ...;// get the correct IAS4CryptoFactory based on aRequestScope
    aRequestHandler.setCryptoFactory(cryptoFactory);
  }

  @Override
  public void customizeAfterHandling(@Nonnull IRequestWebScopeWithoutResponse aRequestScope, @Nonnull AS4UnifiedResponse aUnifiedResponse, @Nonnull AS4RequestHandler aRequestHandler) {

  }
});

[phax]

Yes, your assumption is correctly. A new AS4RequestHandler is instantiated per incoming message - I will outline this in the documentation as well.

So yes, your code looks totally as intended.

Question to you as a user: would you think it improves clarity, if the IAS4ServletRequestHandlerCustomizer needs to be provided directly in the constructor to indicate its "most likely usage"? Or does it complicate things unnecessarily?

[wjans]

For me personally, an optional customizer using a setter is fine. As a regular Spring Boot user, we are used to having optional customizers that don't need to be provided by default.