Can't remove all compression algorithms

[amichair]

Describe the bug
In our application we have a system property that enabled/disables compression support for JWS. In the old codebase (0.11.5) there was a custom CompressionCodecResolver that checks the flag, and either delegates to one of the built-in compressions or throws an exception stating that compression is not supported.

In the new codebase (0.12.6) this has been deprecated in favor of using JwtParserBuilder.zip(). There are two issues here:

1. Calling JwtParserBuilder.zip().clear() to remove all compression algorithm results in "java.lang.IllegalArgumentException: Collection of Identifiable instances may not be null or empty.", so there's no way to disable all of them.
2. It is no longer possible to have one piece of code to handle all compressions (e.g. throw the exception if disabled). The workaround is to create individual custom CompressionAlgorithm for DEF and GZIP that replace the built-in ones and throw an unsupported exception in each one if necessary, but this is quite cumbersome and still doesn't allow handling of any other unknown compression ID.

To Reproduce
Invoke JwtParserBuilder.zip().clear()

Expected behavior
All compression algorithms are removed to disable compression altogether.

[bdemers]

@amichair thanks opening the issue!

Can you tell us little more about your usage? Are you using JJWT as part of another framework (and just exposing configuration options to your users?). How often are your users configuring this flag? Do they often support more than one type of compression? I'm just trying to understand the full flow so if needed, we could implement better solution.

[amichair]

It's the Apache James mail server, I'm trying to upgrade the jjwt dependency and bumped into all the api changes :-)

Ideally the first step would be to just update the code to the new api without changing any functionality and passing the existing tests, I'm not 100% sure what the original design and use cases are so don't want to change it much, but if necessary the logic can be moved around a bit, I don't think it's that critical.

[lhazlewood]

Thanks for the issue @amichair !

Without being able to look at code just yet, I think it probably makes sense to be able to clear the zip collection. I agree that if you don't want any compression at all, it is too heavy-handed to be forced to implement a CompressionAlgorithm just to reject all decompression attempts. The algorithm registry implementation that backs the zip collection I believe already throws an appropriate exception if it can't find a matching algorithm, so that should suffice. I'll have to dig in a little further to confirm.