Comments (15)
Assumption is that users like the simplicity of simply dropping provider jar, without explicit registration. This is why the default jar contains SPI metadata.
One possible way to offer choice here would be to use Maven qualifiers and essentially build 2 variants of jars; ones with SPI registration, and others without it. I don't know how to do it, but think it can be done.
from jackson-jaxrs-providers.
Nice idea, google did that with guava because of how CDI works in JavaEE 6 and Java EE 7 server (link)
I think all you need to do is create two build artifacts one with the usual scheme:
<major version>.<minor version>.<incremental version>
and another with the qualifier
<major version>.<minor version>.<incremental version>-<qualifier>
(where the latter is built without the META-INF/services) and then publish them.
from jackson-jaxrs-providers.
I have a patch ready for JSON provider, going to write a simple test and will submit a pull request.
Tatu, will that be fine with you? What about the classifier? no-metainf-services, i.e. jackson-jaxrs-json-provider-2.3.2-SNAPSHOT-no-metainf-services.jar ? Some other idea?
from jackson-jaxrs-providers.
@japod Yeah I think classifier is the way to go. My only concern is that I wouldn't want to double number of sub-modules if possible (since we have 3 data formats supported, and will most likely get more over time). But as long as release process is automated, I am open to any solutions.
I hope that the fact that this is only about inclusion (or not) of meta-inf, it's easier than cases where different compilation would be needed (like for debug info).
And just to make sure: I do not want to have a single artifact without SPI information without full discussion on mailing list. Problem there would be that a simple upgrade (2.3 -> 2.4) would basically change registration and then users would wonder why their deployments broke.
from jackson-jaxrs-providers.
My suggestion is simple. Move the provider classes over to jackson-jaxrs-base. Then have jaxrs-providers depend on that and have the META-INF.services entries. For someone like me I will just depend on base and register the provider I want myself.
This issue is HUGE and will make many of our lives easier who are using Jersey 2.x
from jackson-jaxrs-providers.
I don't think that would work, if I understand the idea correctly -- the
key to modularity is that XML provider's dependencies are not forced on
JSON provider. So pushing functionality to base is not something I would
want to do.
But if necessary, we can just double up on sub-modules, and create set of
additional sub-modules which only contain META-INF entries, and depend on
concrete implementations. So instead of using qualifiers, we'd just create
new artifacts
The main open question would then be that of naming: would the existing
artifact ids refer to implementation-only (backwards incompatible), and new
ids to registration; or to registration. That is: whether to have
- jackson-jaxrs-json-provider-impl (code) and jackson-jaxrs-json-provider
(registration)
or
- jackson-jaxrs-json-provider (impl) and
jackson-jaxrs-json-provider-metainf (registration)
For backwards compatibility first choice would work better via Maven but
could confuse anyone who directly downloads providers.
-+ Tatu +-
On Fri, Feb 7, 2014 at 1:25 PM, Robert DiFalco [email protected]:
My suggestion is simple. Move the provider classes over to
jackson-jaxrs-base. Then have jaxrs-providers depend on that and have the
META-INF.services entries. For someone like me I will just depend on base
and register the provider I want myself.This issue is HUGE and will make many of our lives easier who are using
Jersey 2.xReply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-34505277
.
from jackson-jaxrs-providers.
Maybe I don't understand but I think this solution prevents anyone from being impacted. JacksonJsonProvider and JacksonJaxbJsonProvider classes are simply moved over to base. But they are inert and do not impact anyone using the base jar. But the provider jar includes the META-INF.services file so people who have come to expect the auto-registration behavior are ALSO not impacted and continue to have the behavior they had before. But again, I could be missing something.
The provider jar already depends on the jaxrs-base jar so that dependency is not changed.
But really, any way it is solved is great for me as long as it is solved. Thanks!
from jackson-jaxrs-providers.
On Fri, Feb 7, 2014 at 2:38 PM, Robert DiFalco [email protected]:
Maybe I don't understand but I think this solution prevents anyone from
being impacted. JacksonJsonProvider and JacksonJaxbJsonProvider classes are
simply moved over to base. But they are inert and do not impact anyone
using the base jar. But the provider jar includes the services so people
who have come to expect the auto-registration behavior are ALSO not
impacted and continue to have the behavior they had before. But again, I
could be missing something.There are 3 different providers: beyond JSON provider, XML- and Smile-
providers exist. And soon I'll add fourth one for CBOR. They are all share
the base package (that is, base contains things that all of them need).
I agree in that if we only had JSON provider, this would be doable.
-+ Tatu +-
from jackson-jaxrs-providers.
Oh yeah, that was myopic of me! Sorry.
from jackson-jaxrs-providers.
On Fri, Feb 7, 2014 at 2:53 PM, Robert DiFalco [email protected]:
Oh yeah, that was myopic of me! Sorry.
No prob. Other providers are not that widely used yet, formerly they
existed as separate projects.
But I think we can make this work with a variation, and that should resolve
issues with 2.4, which should not take nearly as long as 2.3 to be
completed.
-+ Tatu +-
from jackson-jaxrs-providers.
+1 just a quick note that I'm also very much looking forward to a resolution of this: the documentation on the Jersey pages mentions the approach
public class MyObjectMapperProvider implements ContextResolver<ObjectMapper> {
...
}
and as @pnsantos mentioned, that doesn't work. So I'm guessing everybody who uses Jackson 2.x with Jersey is affected and will stumble over this sooner or later.
from jackson-jaxrs-providers.
There hasn't been any progress here, alas, much due to plenty of other Jackson work, but I am still looking forward to potential contributions for 2.5, if anyone has time & interest.
from jackson-jaxrs-providers.
As per PR just merged, second set of jars with classifier of no-metainf-services
will be built, deployed.
Will be included in 2.6.0 (not yet included in rc1 that went out few days ago, but will be in rc2 and final).
from jackson-jaxrs-providers.
If possible I would strongly, strongly recommend not using a qualifier but instead modifying the version number, something to the effect of 2.6.0-no-metainf-services. The issue with using a qualifier is that it changes the maven coordinates, meaning that you could get both jackson-jaxrs-json-provider:2.6.0 and jackson-jaxrs-json-provider:2.6.0:no-metainf-services in your dependency tree. By modifying the version instead of using a qualifier, they will still have the same maven coordinates so you can only end up with one in your dependency tree. This allows users to easily pick which one they want to use and not have to worry about adding exclusions all over the place to prevent the undesirable one from sneaking in as well.
from jackson-jaxrs-providers.
@jhaber Do you know of a way to automatically release concurrent versions, similar to how qualifier approach works?
from jackson-jaxrs-providers.
Related Issues (20)
- Invalid signatures for jackson-jaxrs-base and jackson-jaxrs-json-provider 2.12.2 POM on Maven Central HOT 2
- Module not found: com.fasterxml.jackson.jaxrs.json 2.12.3 issue HOT 6
- Cannot compile class extending JacksonJaxbJsonProvider HOT 2
- Create new alternate `jackson-jakarta-rs-providers` repo for Jakarta (not Javax) RS implementation HOT 2
- Enhance Request : Allow interception during JaxRS serialization and deserialization HOT 1
- com.sun.jersey.api.MessageException: A message body writer for Java class, Error with v2.13.0 HOT 7
- Rename "com.fasterxml.jackson" -> "tools.jackson"
- Missing `MANIFEST.MF` in `jakarta`-classifier artifacts of `JAX-RS providers`, `JAXB annotations` module HOT 8
- Publish 2.13.x version with woodstox:6.4.0 to fix CVEs HOT 4
- Exception class: (Java::JavaLang::NoClassDefFoundError). Exception Message: (com/fasterxml/jackson/jaxrs/json/JacksonJsonProvider) HOT 1
- Is CompletionStage supported? HOT 1
- `ProviderBase` class shows contention on synchronized block using `LRUMap` _writers instance HOT 11
- Reading com.fasterxml.jackson.core based Json from resteasy-jackson-provider 3.9.0 #3566 HOT 5
- Add Ion provider HOT 1
- Convert `ObjectReaderInjector`/`ObjectWriterInjector` to use new (2.16) pluggable `RecyclerPool` instead of hard-coded one HOT 1
- Backport Snakeyaml update to branch 2.12 HOT 25
- Deprecate local `LRUMap`, use `jackson-databind` provided one instead
- Which release is compatible with java17 HOT 1
- How to disable JaxRSFeature.READ_FULL_STREAM. HOT 9
- MavenGate (CVE) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jackson-jaxrs-providers.