[
https://issues.apache.org/jira/browse/KARAF-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17946872#comment-17946872
]
Robert Varga edited comment on KARAF-7768 at 4/23/25 10:26 PM:
---------------------------------------------------------------
So, as far as I am reading this right, specification-wise, we should be
bridging to either
# SPI-Fly as [a
consumer|https://aries.apache.org/documentation/modules/spi-fly.html#_consumers],
or
# XML Parser Service as [specified as OSGi Companion
R8|https://docs.osgi.org/specification/osgi.cmpn/8.0.0/util.xml.html]
The former boils down to a Require-Capability header, which can be added via
[the wrap:
protocol|https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833898/Wrap+Protocol].
The latter has a well-known API which user can exploit and we should provide,
probably as part the framework feature, perhaps bridging to a
reasonably-configured platform provider.
Also note that features.core implies Jackson, which implies woodstox, which
implies stax2-api: our JSON library brings into the picture a StAX
implementation which has its own [OSGi injection
mechanism|https://www.javadoc.io/static/org.codehaus.woodstox/stax2-api/4.2.2/org/codehaus/stax2/osgi/package-summary.html].
We need to decide how this dependency is integrated: we can say all Karaf
installations are using WoodStox for XML parsing -- which feels like a third
parsing option.
was (Author: nite):
So, as far as I am reading this right, specification-wise, we should be
bridging to either
# SPI-Fly as [a
consumer|https://aries.apache.org/documentation/modules/spi-fly.html#_consumers],
or
# XML Parser Service as [specified as OSGi Companion
R8|https://docs.osgi.org/specification/osgi.cmpn/8.0.0/util.xml.html]
The former boils down to a Require-Capability header, which can be added via
[the wrap:
protocol|https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833898/Wrap+Protocol].
The latter has a well-known API which user can exploit and we should provide,
probably as part the framework feature, perhaps bridging to a
reasonably-configured platform provider.
Also note that features.core implies Jackson, which implies woodstox, which
implies stax2-api: our JSON library brings into the picture a StAX
implementation which has its own [OSGi injection
mechanism|https://www.javadoc.io/static/org.codehaus.woodstox/stax2-api/4.2.2/org/codehaus/stax2/osgi/package-summary.html].
We need to decide how this dependency is integrated: we can say all Karaf
installations are using WoodStox for XML parsing, but is that a reasonable
thing to do?
> Remove karaf.specs
> ------------------
>
> Key: KARAF-7768
> URL: https://issues.apache.org/jira/browse/KARAF-7768
> Project: Karaf
> Issue Type: Improvement
> Reporter: Robert Varga
> Assignee: Jean-Baptiste Onofré
> Priority: Major
>
> As noted in https://lists.apache.org/thread/dhfzyyph43h9hqn9fd47qwh1krvx83tl,
> it seems we can remove our patching of javax.xml(.ws) by including SPI Fly
> directly in the system.
> Prototype whether this idea works and implement it if it does.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
