Error when adding security-oauth2-starter dependency in Jmix 1.7.0 with JDK 11

Support
#1

I created a new project using Jmix version 1.7.0 with JDK 11. However, when I add the following dependency:
implementation ‘io.jmix.security:jmix-security-oauth2-starter’

I get the following exception:

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration’: Unsatisfied dependency expressed through method ‘setFilterChains’ parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘sec_AuthorizationServerSecurityFilterChain’ defined in class path resource [io/jmix/securityoauth2/config/AuthorizationServerSecurityConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.security.web.SecurityFilterChain]: Factory method ‘securityFilterChain’ threw exception; nested exception is java.lang.RuntimeException: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.

Question:
How can I resolve this JAXBException? Is there an additional dependency required for JDK 11 compatibility?

#3

Hi,

Please use Jmix 1.7.1.

Regards,
Ivan

#4

Hi ,
Thank you for suggesting an upgrade to Jmix 1.7.1. However, I have other projects running on 1.7.0, and upgrading might introduce inconsistencies.

  1. Is there a workaround to use jmix-security-oauth2-starter in 1.7.0 without encountering the JAXBException?
  • For example, would manually adding JAXB dependencies (e.g., javax.xml.bind:jaxb-api) resolve this?
  1. If not, are there alternative approaches to implement OAuth2 security in 1.7.0?
  • Could a different dependency or configuration be used temporarily?

I’d prefer to avoid upgrading just one project while others remain on 1.7.0. Any guidance would be appreciated!

#5

The only change that comes with 1.7.1 is the fix for that issue.
That’s the purpose of that patch.

Regards,
Ivan

#6

Thank you for the clarification. I had already upgraded my add-on module from 1.7.0 to 1.7.1 while keeping the core project at 1.7.0, but the same exception persisted when adding the add-on’s dependency.

However, after upgrading the core project from 1.7.0 to 1.7.1, the issue was resolved. This is puzzling because my core project does not explicitly depend on io.jmix.security:jmix-security-oauth2-starter—this dependency only exists in my add-on.

Could you explain why the core project version affects this behavior, even though the OAuth2 dependency is only in the add-on?

#7

Hi,

I assume because core project uses bom version 1.7.0 it brings the different versions of libraries which cause an issue. And because within the fix in 1.7.1 dependencies versions were lowered - gradle chose more fresh (invalid) version of those libs.

You can use gradle tasks dependencies or dependencyInsight to check your dependency tree and track the origin of specific dependency.

Regards,
Ivan

#8

Key Questions:

  1. Is there a recommended way to isolate versions so that:
  • Each add-on works with its specified version (even if they differ)
  • The core project remains on its current version (1.7.0)
  • Neither affects the other’s dependencies?
#9

In short - no.

All libraries in project will affect each other in terms of dependencies. You can’t avoid it. You can only adjust it via exclusion and version forcing.

If you have some project with version X, all the add-ons must be compatible to it one way or another.

Regards,
Ivan

#10

I’m converting my monolithic project to an add-ons architecture and have questions about version compatibility:

Higher Base Version Scenario:-

If my base project uses a newer version (e.g., 1.7.1) than add-ons (e.g., Addon A: 1.7.0, Addon B: 1.6.0), will this remain stable?

Lower Base Version Scenario:-

Conversely, if the base project is on an older version (e.g., 1.6.0) while add-ons use newer versions (e.g., Addon A: 1.7.0, Addon B: 1.6.0), will this work?

Future Compatibility:-

Can add-ons built for newer major versions (e.g., 2.0.0+) work with an older base project (e.g., 1.7.1)?

Conversely, can older add-ons (e.g., 1.6.0) function in a newer base project (e.g., 2.0.0+)?

I’d appreciate guidance on version tolerance between components and any best practices for long-term maintenance.

#11

Hi,

In general - it should be the same Jmix version in every part.
Specific Jmix version brings specific baseline of dependencies (both 3rd-party and framework) which can be incompatible.

In theory in some specific case different version of base project and add-on can be compatible - it depends of what this add-on actually doing. But it can’t be called stable.
If your add-on uses some framework functionality from version which requires some specific feature from the same version of another framework module, but you don’t have it - application will fail.

So basically verifying the compatibility between your custom project and your custom add-on is on you. And the best way to maintain it - use the same version.

Versions 1.x. and 2.x are not compatible at all.

Regards,
Ivan