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

try/catch usage of sql classes in serializer static initializer to al… #1073

Closed
wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 7, 2016

…low it to be used in embedded compact1 configurations.

try/catch usage of sql classes in serializer static initializer to allow it to be used in embedded compact1 configurations.

The fix I made is quite simple but maybe you would prefer to have an externally specified factory that only instantiates a subset of the concrete type serializers. But that would require a substantial change since the existing serializers (BeanSerializerFactory/BasicSerializerFactory) do not allow much customization.

…low it to be used in embedded compact1 configurations.
@cowtowncoder
Copy link
Member

Hmmh ok. Do you have specific case in mind where this has been problematic? I don't doubt it can happen, but it would be good to have that as sort of documentation. I assume this is not for Android, as no problem with these types has been reported before.

@cowtowncoder
Copy link
Member

@claudemt Thanks again -- I changed this slightly, to happen within StdJdkSerializers, but the idea is the same. I hope this works; let me if there are any issues.

One thing to note: while it is checked in 2.5 branch, merged forward, there are no plans for more full 2.5 releases. It is possible micro-patches (like 2.5.5-1) may still be released for critical problems. So most likely this will be first available in 2.6.5 and 2.7.0 releases.

@ghost
Copy link
Author

ghost commented Jan 10, 2016

Thanks a lot for this quick merge. Your changes appear to be fine.
We will integrate 2.6.5 when available.
You were asking about the use case. Our embedded systems currently have a compacted embedded JVM without java.sql. While switching to a bigger (compact2) JVM would be possible, deploying it would be a problem and the impact would be important compared to simply changing the code as we just did.

@cowtowncoder
Copy link
Member

@claudemt Ok thank you for the update. For what it is worth, 2.7.0 is being released now. I realize it may not be feasible for you to upgrade at this point, but if it is, that would be the quickest upgrade route.

aryehpro added a commit to aryehpro/jackson-databind that referenced this pull request Jan 25, 2016
# By Tatu Saloranta (113) and others
# Via Tatu Saloranta
* 'master' of https://github.com/FasterXML/jackson-databind: (124 commits)
  Minor addition related to FasterXML#1087: resolve context type, assuming type bindings from that are expected to work.
  Add unit test for FasterXML#999
  minor warnings cleanup
  Add Javadoc badge with automatic version detection
  Fix FasterXML#1083
  Add failing test for FasterXML#1083
  add a unit test to verify that Object Id works via AtomicReference too
  Minor javadoc improvement wrt FasterXML#1076, making `SimpleType.construct(Class)` deprecated (was not yet, for some reason, should have been)
  Fix FasterXML#1078
  Fix FasterXML#1079
  [maven-release-plugin] prepare for next development iteration
  [maven-release-plugin] prepare release jackson-databind-2.7.0
  prepare for 2.7.0 final
  Fix FasterXML#1073
  Try to reproduce FasterXML#1074
  javadoc trimming
  Try to reproduce FasterXML#825 again, still passes.
  minor improvement to ensure base64 encoding uses configured setting
  Undo part of change done for StringDeserializer; caused issues with XML handling
  further minor cleanups to cleanup
  ...
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.

1 participant