Konstantin,
On 1/3/16 8:07 PM, Konstantin Kolinko wrote:
> 2016-01-04 2:22 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>:
>> Konstantin,
>>
>> On 12/31/15 12:56 PM, Konstantin Kolinko wrote:
>>> 2015-12-31 12:41 GMT+03:00 Tomasz Macnar <tomasz.mac...@comarch.pl>:
>>>> Thanks for answer.
>>>> I understand that application deploy order is the key to get context to
>>>> deployed applicaitons (when application isn't deployed i can't get it
>>>> context - it is clear).
>>>> But ROOT application is deployed before app1, but i can't get ROOT context
>>>> from app1.
>>>> Is it in tomcat 8 possible to get ROOT context from other
>>>> application (in servlet) ? If yes, coud tou give me an simple example ?
>>>>
>>>> In tomcat 6 when i put this configuration to server.xml
>>>>
>>>> <Context path="" docBase="${catalina.base}/webapps/ROOT"
>>>> crossContext="true"
>>>> />
>>>>
>>>> i have returned ROOT application context. The same code work fine in tomcat
>>>> 6.
>>>>
>>>
>>> Deployment order does not matter. What matters is whether other
>>> context has already been started (registered in Mapper and is
>>> available to serve requests). As you have already noted during your
>>> debugging, "children" field in ContainerBase is a HashMap and the
>>> entries are not ordered.
>>>
>>> Note that
>>> 1) modern JRE uses random seed when evaluating String hash code to
>>> mitigate hash collision attacks, so the order will be different on
>>> different runs
>>
>> [citation needed]
>>
>> Oracle's Java 8 does not do this, nor do I suspect any other JREs out
>> there, otherwise Serialization of things like HashMap would break all
>> over the place.
>>
>> One could argue that modern JREs *should* do this, but backward
>> compatibility is an impediment.
>
> Apparently this one:
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/43bd5ee0205e
> May 2012, so 3,5 years ago. Times flies fast..
>
> String.java in JDK 7u80 has that code (HASHING_SEED field, hash32()
> method etc.).
>
> Implementation of String.hashCode() is immutable, because its
> algorithm is documented in official Javadoc for the method, but they
> went with a package-visible method "hash32()". The hg commit creates
> "hash32()" as a public method. It is package-visible in actual 7u80.
In my Oracle JDK 1.8.0_60 (x86-64 Mac) src.zip, java/lang/String.java
has no such field, etc.
A little research shows that JDK 1.7.0u8 and higher had this seed and
modified hashing, but that Java 8 threw out all that stuff and just
started using tree-based maps with no fudge-factor on the String hash.
That makes for a cleaner separation between the String and HashMap (and
related) classes.
That's why I can't find it in a recent JDK release.
> There is no such method in 8u66, but the structure of a hashmap has
> evolved. There is no guarantee of an iteration order.
There was never a guarantee of an iteration order from HashMap.
> Implementation of hashCode() does not matter for serialization,
> because HashMap serializes only the values (the key-value pairs), not
> the internal structure.
I hadn't read HashMap.writeObject; thanks for pointing that out. If each
HashMap decided to mutate the hashes of its String keys, they would in
fact still be compatible with JREs that did not perform such mutations.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
