SQLErrorCodesFactory should use its classloader when loading the default codes [SPR-5118]

[spring-projects-issues]

Costin Leau opened SPR-5118 and commented

SQLErrorCodesFactory uses a ClassPathResource (which in this case relies on the TCCL) to load both custom and default codes. Since the default codes are specified in the Spring jar, the factory could use its classloader to load these resources and then use the client classloader (if available instead of the TCCL) to load the custom codes.
In OSGi this makes a difference as it doesn't require users to import various jdbc packages.
(see http://tinyurl.com/5cle3n).

---

Affects: 2.5.5

1 votes, 1 watchers

[spring-projects-issues]

Dmitry Kirillov commented

The working url to the forum thread is:

http://forum.springframework.org/showthread.php?t=59128

[spring-projects-issues]

Costin Leau commented

Sorry - here's a link with a proper shortcut: http://is.gd/1Xt3 :)

[spring-projects-issues]

Costin Leau commented

And link http://is.gd/1Xt6 to the relevant post in the thread (6)

[spring-projects-issues]

Juergen Hoeller commented

Actually, since SQLErrorCodesFactory is a static singleton here, it needs to always load its "sql-error-codes.xml" files from its class loader (i.e. Spring's class loader). Otherwise the static singleton would only ever contain the custom error codes of the bundle that triggered initialization of the SQLErrorCodesFactory first...

So custom error codes will only be detected if the "sql-error-codes.xml" file is included in the same class loader that defines the Spring JDBC support itself. This might be unpleasant in an OSGi environment, but well - a proper solution would require avoiding the static SQLErrorCodesFactory singleton in the first place...

Juergen