rzo1 commented on PR #211:
URL: https://github.com/apache/openjpa/pull/211#issuecomment-6078588722
@solomax I pushed a test to the branch:
`openjpa-kernel/.../util/TestSerializationClassResolving`.
No `ObjectStreamClass` has to be built. Serializing with a plain
`ObjectOutputStream` and reading back through `Serialization.deserialize(in,
null)` drives `resolveClass` with whatever descriptor the stream carries, and
the interesting descriptors are reachable that way:
- `int.class` serializes to a descriptor whose name is `int`.
`Class.forName("int", true, loader)` throws, so the class is resolvable only
through the fallback to `super.resolveClass`. This one fails on the code before
this branch (`ClassNotFoundException: int`) and passes with it.
- `int[].class`, `String[].class` and an `int[]` instance give the
descriptors `[I` and `[Ljava.lang.String;`, which do resolve by name; they are
regression coverage.
- For the context loader, a loader that redefines the test's own classes
instead of delegating yields a class with the same name reachable from one
loader only. The test serializes an instance of that copy, sets it as the
context loader, deserializes, and asserts the result's class is the loader's
copy. Since both copies come from the same bytes, the serial version matches.
`ObjectStreamClass.lookup(Class)` is indeed unusable for this, since it
resolves against the local loader.
Four tests, all green on the branch; with `Serialization.java` reverted to
the pre-branch version the primitive one errors, so it pins the change rather
than the surroundings.
One small thing on the javadoc in 374edfa4: the comment ends with "A comment
would prevent a later simplification", which was my phrasing in the review
rather than something to keep in the source. Everything above it describes the
constraint correctly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
