On 14/05/2020 18:41, Christopher Schultz wrote:
> Mark,
> On 5/14/20 12:53, Mark Thomas wrote:
>> On 14/05/2020 17:46, Mark Thomas wrote:
>>> On 14/05/2020 16:48, Christopher Schultz wrote:
>>>> All,
>>>> I'm interested in the history of the
>>>> StandardSession.writeObjectData method. I've been looking at it
>>>> lately because I'm interested in possibly (optionally)
>>>> encrypting the sessions in the backend session store. But this
>>>> isn't about encryption at all.
>>>> The code for StandardSession.doWriteObject(ObjectOutputStream
>>>> stream) looks like this:
>>>> // Write the scalar instance variables (except Manager)
>>>> stream.writeObject(Long.valueOf(creationTime));
>>>> stream.writeObject(Long.valueOf(lastAccessedTime));
>>>> stream.writeObject(Integer.valueOf(maxInactiveInterval));
>>>> stream.writeObject(Boolean.valueOf(isNew));
>>>> stream.writeObject(Boolean.valueOf(isValid));
>>>> stream.writeObject(Long.valueOf(thisAccessedTime));
>>>> Is there any reason we are writing object wrappers for these
>>>> primitive members instead of just writing the primitives
>>>> directly?
>>> That code goes all the way back to at least Tomcat 3.1.x (20+
>>> years ago).
>>>> It turns out that the byte stream is identical whether one
>>>> uses objects or primitives,
>>> That surprises me. Looking at the JRE source code it really
>>> surprises me. So much that I am going to go and try it for
>>> myself.
>> My testing shows the opposite. There is a significant difference
>> between writing primitives and writing objects.
> Hmm. I did a micro-test with just writing a single Long.valueOf()
> value and a (primitive) long alone to an ObjectOutputStream. I didn't
> test the StandardSession itself.

I performed the same micro-test.

>> Given backwards compatibility requirements we can't change this in
>> 9.0.x and earlier.
> Agreed.
>>> One reason we might want to stick with writing objects is to
>>> support sessionAttributeValueClassNameFilter. I'm only going from
>>> reading the source so I could easily have missed something but it
>>> looks like that will only work if we write/read objects.
>> We only care about this for session attributes. We know our
>> internal attributes are safe so we could switch to primitives in
>> 10.0.x.
> I'll have to play-around a bit to see what was wrong with my initial tes
> t.

JRE version? I used a newish Java 8. Long value? I used 1000. I did
something stupid? Source code here:



To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to