CoreContextListener erroneously assumes /WEB-INF/classes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure ZK + ZK Spring with embedded Jetty

What is the expected output? What do you see instead?

I expect to see ZKComponentBeanMethods.class to be generated in the correct 
location, eg:

<output-path>/org/zkoss/spring/beans/zkcomponents/ZKComponentBeanMethods.class

What I do see is the class file generated in a location dependent upon the 
configuration of ServletContextHandler#baseResource. Two examples I've seen are 
outlined below:

ServletContextHandler contextHandler = new ServletContextHandler();

// using the default for SCH above, the final path of the class is

<output-path>/null/org/zkoss/spring/beans/zkcomponents/ZKComponentBeanMethods.cl
ass

contextHandler.setBaseResource(Resources.newClassPathResource("/org/example/zk")
;

// using the above classpath based resource base

<output-path>/org/example/zk/WEB-INF/org/zkoss/spring/beans/zkcomponents/ZKCompo
nentBeanMethods.class

The problem is exacerbated by three factors:

1. CtClass#writeFile(String) seems to use the literal string "null" as the 
prefix when passed a null directory. The JavaDoc for that method doesn't 
mention null handling, but a quick test shows their code (3.8.0.GA) does indeed 
do this.

    @Test
    public void testNullConcat() {
        String path = null + "/foo";
        assertEquals("null/foo", path);
    }

2. CoreContextListener#preprocessSpringBeansForZKComponentinjection does not 
check the return value of 
ServletContextEvent#getServletContext()#getRealPath("/WEB-INF/classes"). As a 
result, webInf remains null and is passed to CtClass#writeFile. Obvious 
solution is to check for null and use an empty string instead.

3. CoreContextListener#preprocessSpringBeansForZKComponentinjection is private 
so cannot be overridden in a subclass.

What version of the product are you using? On what operating system?

ZK 5.0.7, ZK Spring 3.0

Please provide any additional information below.

Not sure how you would resolve the case, if at all, of the context having a 
base resource partially down the hierarchy.

Original issue reported on code.google.com by pto...@gmail.com on 14 Jul 2011 at 12:38