omniORB 4.0.0 bugs

The following bugs in omniORB 4.0.0 have been fixed. Update from CVS to get the fixes.

Summary: Incorrect threading behaviour with multiple requests (bug number 9)
Date: Tue Jan 28 12:05:54 GMT 2003
Reported by: Michael Sturm, Ulf Stoermer
Description: If a client sent multiple requests in a single transfer (e.g. a collection of oneways), the select loop could fail to notice them, causing them to be serialised, rather than dispatched to separate threads.

Summary: Various problems with recursive TypeCodes (bug number 8)
Date: Thu Dec 5 12:16:33 GMT 2002
Reported by: Clemens Fischer
Description: Some things would fail when using recursive TypeCodes generated with orb->create_recursive_tc().

Summary: Call descriptor clash with oneways (bug number 7)
Date: Thu Nov 21 15:48:26 GMT 2002
Reported by: Ilya Kreyer
Link for this bug:
Description: Functions with identical signatures except for onewayness would incorrectly share call descriptor classes.

Summary: Hang on shutdown (bug number 6)
Date: Fri Nov 8 17:17:14 GMT 2002
Reported by: Norrie Quinn
Link for this bug:
Description: In some circumstances, shutdown could hang if servant locators were in use.

Summary: Log flush bug (bug number 5)
Date: Wed Oct 30 16:41:56 GMT 2002
Reported by: John Fardo
Description: The omniORB logger's flush function did not use the application supplied log function.

Summary: Object ids not unique in PERSISTENT SYSTEM_ID POAs (bug number 4)
Date: Mon Oct 14 15:48:35 BST 2002
Reported by: Bjorn Rohde Jensen
Link for this bug:
Description: A POA with the PERSISTENT and SYSTEM_ID policies should generate object ids that are unique across all runs. omniORB failed to do that. See the new poaUniquePersistentSystemIds configuration parameter if you need the old behaviour.

Summary: Deadlock race condition in create_POA / destroy (bug number 3)
Date: Mon Oct 14 15:48:35 BST 2002
Reported by: Teemu Torma
Link for this bug:
Description: If a thread destroying a POA raced with another thread trying to create the same POA, a deadlock could occur.

Summary: Random endpoint errors on Windows (bug number 2)
Date: Fri Oct 4 12:01:31 BST 2002
Reported by: Norrie Quinn
Link for this bug:

Summary: Broken .mak files for Windows (bug number 1)
Date: Wed Oct 2 21:06:51 BST 2002
Reported by: Jonathan Shaw
Description: The .mak files for use with Windows nmake were broken. The Windows binary distribution has been patched.