Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declare osgi.serviceloader.registrar requirement as optional #155

Merged

Conversation

chrisr3
Copy link
Contributor

@chrisr3 chrisr3 commented Aug 10, 2022

The osgi.serviceloader.registrar requirement is satisfied by Apache Aries SPI-Fly, and java.util.ServiceLoader cannot work inside an OSGi framework without it.

However, it is probably better to allow people to discover a need for SPI-Fly themselves rather that throwing bundle resolution errors at them when they upgrade woodstox-core 😊.

@cowtowncoder
Copy link
Member

Sounds good, will merge for 6.3.1.

@cowtowncoder cowtowncoder merged commit bc4ce73 into FasterXML:master Aug 11, 2022
@cowtowncoder cowtowncoder changed the title Declare osgi.serviceloader.registrar requirement as optional. Declare osgi.serviceloader.registrar requirement as optional Aug 11, 2022
cowtowncoder added a commit that referenced this pull request Aug 11, 2022
@cowtowncoder
Copy link
Member

Merged; I will try to get 6.3.1 release out in near future, given that this can avoid awkward upgrade experiences that users like @selundqma have had :)

@cowtowncoder
Copy link
Member

Sigh. Looks like this just causes issues through-out non-OSGi Java realm.

And I will probably need to revert this from 6.5.0.
Not sure how to help OSGi use cases.

@chrisr3
Copy link
Contributor Author

chrisr3 commented Dec 14, 2022

I've had a chat with the Bnd developers, and they reckon they can modify their annotations to use String rather than enums.

@cowtowncoder
Copy link
Member

@chrisr3 That would be great.

@kriegfrj
Copy link

The osgi.serviceloader.registrar requirement is satisfied by Apache Aries SPI-Fly, and java.util.ServiceLoader cannot work inside an OSGi framework without it.

Actually, this isn't ''strictly'' true in more recent versions of SPI-Fly. Because the lack of the necessary osgi.serviceloader.registrar property was a common problem, @rotty3000 added a configurable override so that you can manually configure SPI-Fly to treat certain bundles as if they had the necessary provider/consumer metadata. See Dynamic weaving by auto properties.

However, it is still better to have the bundle declare its own requirements, rather than throw that responsibility back onto the pour soul trying to assemble the application...

However, it is probably better to allow people to discover a need for SPI-Fly themselves rather that throwing bundle resolution errors at them when they upgrade woodstox-core 😊.

Agree. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants