Using custom WebAppClassloader in Jetty

I'm writing a spring based web application for our company and I received orders that I should encrypt classes of our app.

I found a simple implementation of classloader that might do the trick here. It's basically a URLClassLoader that implements its own loadClass and findClass methods.

I followed instructions from Jetty wiki @ eclipse, I created my own classloader by extending WebAppClassLoader. I've implemented findClass() and loadClass() methods as suggested in the first link (almost copy & paste).

Full code of my classloader can be seen here on gist.

I've set the classloader using context in jetty.

<Configure id="clsLdrCtx" class="org.eclipse.jetty.webapp.WebAppContext">
  <Set name="contextPath">/server</Set>
     <Set name="war">
       /home/me/workz/protection/classloading/server/target/server-0.0.0-SNAPSHOT.war</Set>
     <Set name="classLoader">
       <New class="org.eclipse.jetty.webapp.WebAppClassLoaderEncrypted">
         <Arg><Ref id="clsLdrCtx"/></Arg>
       </New>
     </Set>
</Configure>

I started jetty (without any encrypted classes, just to see if the classloader workz) and I got following exception:

2011-10-11 14:59:58.401:WARN::FAILED encodingFilter: java.lang.IllegalStateException: class org.springframework.web.filter.CharacterEncodingFilter is not a javax.servlet.Filter

(Full stack trace also on the same gist link as above)

(If I don't implement findClass() it uses implementation f开发者_JAVA技巧rom URLClassLoader and it runs just fine.)

Can you see what might be the problem? I'll be glad for any answer, thank you

---

Putting aside the (lack of) merits to encrypting classes inside a web-app...

It looks like your classloader isn't working because you have failed to maintain/duplicate the appropriate behaviours from WebAppClassLoader

Have a look at the source to the WebAppClassLoader and you will see that it has special handling for "System" and "Server" classes. You need to include that behaviour.

The result you are getting (probably) is that your filter is implementing your "Filter" interface (i.e. the Filter class loaded by your own classloader), rather than the server's "Filter" interface (the one loaded by Jetty's root classloader)