This content has been marked as final. Show 2 replies
I don't see how you could make that work.
Have you considered multiple signed JARs? Regressing to .class files is really not a desirable option from any point of view.
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.
Edited by: ptt on Nov 3, 2010 12:36 PM