Securing Context Config

[mkochco]

I'm interested in preventing a customer from overriding the wiring declared in the spring context config file ( bean definitions ).

How do you typically deliver a spring based application and still provide the flexibility to change some config while limiting access to other config elements? For example, allowing a customer to change a DAO implementation but preventing a customer from cleverly injecting their own Licensing Manager implementation.

Any/All suggestions welcome.

Thanks,
Mark

[jbetancourt]

One idea is to modularize the bean files. Some can be inaccessible (in a sealed secure jar), loaded via classpath, whereas other bean definitions can be loaded from the host file system or other resource and is intended for "user" modification. But, how does one create a sealed secure jar file? I don't think there is a such a thing since the classloader must eventually have access to the byte code, and beyond that the JVM must too (ruling out encrypted classloaders).

Of course, there are even more issues. The book "Covert Java" has some relevent info on this stuff.

J. Betancourt