I would like to find out if it is possible to provide Java classes directly from .class files, reachable using something like 'codebase="https:/<appropriate URL>" and have the security behavior be the same as a signed jar.
We have a secure application we operate across multiple servers in a LAN environment. We have applets that all must come from the same code base because they communicate with each other heavily. In addition, they need to connect to any server on the LAN. Currently we load all our code into a single big jar and sign it to get the security options needed for connecting to the servers. However, our development project is migrating into many sub projects, each producing its own .jar files. In addition, we have dependencies on third party jar files. It is becoming increasingly difficult to manage the "codebase" and "archive" parameters to the applet/object tags.
Since the servlet server for the application has all the classes and then some that the applets need, I was hoping I could write a servlet that could be the destination of the codebase URL and that it could serve the classes directly using the context class loader. Hopefully using https for the codebase would get me the "signed-ness" as far as security goes.
I can always write it as an experiment but I was hoping someone would already know if this will work as far as security goes. Thank you.
Note: I would not actually be reverting to .class files. My server side app has a huge class path built up from many Jars. The idea is to have the applet's "codebase" resolve to a servlet which would use its context class loader to locate the byte code for the applet requested class files. From the point of view of managing what gets filled into the codebase/archive parameters in the applet/object tag, this solution is much simpler to manage at the developer level than having to fill in explicit jar id's for all the arbitrarily loaded jars, especially when they are third party with names like "foo-net-0.1.3-101104.jar" where the numbers change with each new release or build. Further, some of these jars are pretty big even though only a class or two is needed. It would be nice if I have a fixed value for codebase, and no value for archive at all, plus have the performance advantage of only serving up byte code for classes actually used. But for our application this scheme only makes sense if serving a codebase via HTTPS is the security equivalent of a signed jar.