GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Issue was reported by a Nippy user, Ref. ptaoussanis/nippy#14 (comment)
Not at all familiar with the Monger code base, so not sure what the best workaround would be.
Well, it's a hack that uses undocumented reader features, I'm not sure if we can do that with, say, Nippy.
For some context, could you explain roughly why you're overwriting the default Date representation? Would the data-readers not be appropriate for your use case?
For security purposes, I generally recommend that most folks disable *read-eval* unless they absolutely know the implications and that the data they're dealing with is sanitary.
It was added in 1.3 days, maybe now there are better options to explore. One way is dropping 1.3 support. I believe
JDK dates can be serialized using 1.4's reader (as tagged literals) and that's sufficient for what monger.joda-time tries to do.
Not sure what your internals look like, but perhaps it'd be possible to do this coercion w/o needing to mod the reader at all? Is this coercion entirely internal, or is the user going to be interacting with the serialized-to-string forms?
It is there to enable dates to be serialized.
Got that much :-) Anyway, yeah - there are a number of possibilities ranging from a thread-local coercion to a namespaced or thread-local data-reader if you're prepared to bump to 1.4. Will leave it to you, but I would suggest the current behavior is dangerous.