Jetty

extraClasspath set from jetty-web.xml is ignored

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 6.1.22
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

Documentation states (http://docs.codehaus.org/display/JETTY/Classloading) that I can add classpath to my application by setting it in jetty-web.xml.

I have attached a simple web application that proves that either documentation is wrong or there is a bug in Jetty.

The application has one primitive servlet that is loaded on startup.
In its init method it tries to load class A that is located in c:/tmp
Application comes with jetty-web.xml that does exactly what documentation says:
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="extraClasspath">c:/tmp</Set>
</Configure>

Then I run Jetty-Service.exe

EXPECTED: application is started
OBSERVED: application cannot be started b/c of exception
jvm 1 | 2010-03-24 12:53:08.311:WARN::failed HandlerCollection@a31e1b: java.l
ang.NoClassDefFoundError: A
jvm 1 | 2010-03-24 12:53:08.311:WARN::Error starting handlers
jvm 1 | java.lang.NoClassDefFoundError: A
jvm 1 | at TestServlet.init(TestServlet.java:8)

At the same time application is started successfully when I supply the additional classpath on command line:
java -Djetty.class.path="c:/tmp" -jar start.jar

If I try to start with no additional classpath
java -jar start.jar
I get the same exception as with Jetty-Service.exe

In other words additional classpath set from jetty-web.xml is simply ignored.

This can be resolved by either fixing the bug or changing the documentation.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Michael Gorovoy added a comment -

Oleg,

I am trying to reproduce the issue and getting an exception "java.lang.UnsupportedClassVersionError: bad version number in .class file" for some reason. Could you please provide the source code so that I can build it here?

Thanks,
Michael

Show
Michael Gorovoy added a comment - Oleg, I am trying to reproduce the issue and getting an exception "java.lang.UnsupportedClassVersionError: bad version number in .class file" for some reason. Could you please provide the source code so that I can build it here? Thanks, Michael
Hide
Permalink
Oleg Mikheev added a comment -

Michael,
Source code files are in the war file (in classes folder).

The source code for class A is:
public class A {
}

The source code for class TestServlet is:
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

public class TestServlet extends HttpServlet {

@Override
public void init() throws ServletException

{ A a = new A(); super.init(); }

}

Show
Oleg Mikheev added a comment - Michael, Source code files are in the war file (in classes folder). The source code for class A is: public class A { } The source code for class TestServlet is: import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; public class TestServlet extends HttpServlet { @Override public void init() throws ServletException { A a = new A(); super.init(); } }
Hide
Permalink
Michael Gorovoy added a comment -

Oleg,

I have rebuilt your web application and was able to start it successfully using the extraClasspath setting of WebAppContext.

The context configuration file should have the following minimum configuration, because war property is mandatory.

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
   <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/qwe.war</Set>
  <Set name="extraClasspath">c:/tmp/</Set>
</Configure>

Please note that Jetty 6.1.x is compiled to be compatible with Java 1.4 with some modules targeted for Java 1.5. For this reason, while you can use Java 1.6 to run Jetty 6, you should compile web applications that will run in Jetty 6 using the following java compiler compatibility options.

javac -source 1.5 -target 1.5 A.java

Thanks,
Michael

Show
Michael Gorovoy added a comment - Oleg, I have rebuilt your web application and was able to start it successfully using the extraClasspath setting of WebAppContext. The context configuration file should have the following minimum configuration, because war property is mandatory. <Configure class= "org.mortbay.jetty.webapp.WebAppContext" > <Set name= "war" > <SystemProperty name= "jetty.home" default= "." /> /webapps/qwe.war </Set> <Set name= "extraClasspath" > c:/tmp/ </Set> </Configure> Please note that Jetty 6.1.x is compiled to be compatible with Java 1.4 with some modules targeted for Java 1.5. For this reason, while you can use Java 1.6 to run Jetty 6, you should compile web applications that will run in Jetty 6 using the following java compiler compatibility options. javac -source 1.5 -target 1.5 A.java Thanks, Michael
Hide
Permalink
Jan Bartel added a comment -

Oleg,

The problem is that the jetty-web.xml file is read and parsed as the last step before the webapp goes into service. By that time, the classpath of the WebAppClassLoader has already been established. So you are right, in that the extraClasspath in a jetty-web.xml file is ignored. As Michael says, if you put it in a context file for the webapp instead, it will be used. We'll make a note to improve the documentation.

cheers
Jan

Show
Jan Bartel added a comment - Oleg, The problem is that the jetty-web.xml file is read and parsed as the last step before the webapp goes into service. By that time, the classpath of the WebAppClassLoader has already been established. So you are right, in that the extraClasspath in a jetty-web.xml file is ignored. As Michael says, if you put it in a context file for the webapp instead, it will be used. We'll make a note to improve the documentation. cheers Jan
Hide
Permalink
Oleg Mikheev added a comment - - edited

Guys,

Do you really think that this issue is resolved?
I don't see any documentation changes.
And what is more important, I don't see any way for a Jetty user who needs an additional classpath to accomplish this task by following your documentation in its current state.
Neither http://docs.codehaus.org/display/JETTY/jetty-web.xml nor http://docs.codehaus.org/display/JETTY/Classloading mention that the war property is mandatory.

BTW, do you think it is a clever approach to configure the war file name from within a war file?

Show
Oleg Mikheev added a comment - - edited Guys, Do you really think that this issue is resolved? I don't see any documentation changes. And what is more important, I don't see any way for a Jetty user who needs an additional classpath to accomplish this task by following your documentation in its current state. Neither http://docs.codehaus.org/display/JETTY/jetty-web.xml nor http://docs.codehaus.org/display/JETTY/Classloading mention that the war property is mandatory. BTW, do you think it is a clever approach to configure the war file name from within a war file?
Hide
Permalink
Michael Gorovoy added a comment -

Oleg,

As Jan pointed out, you cannot configure the extraClasspath attribute from jetty-web.xml because by the time it is processed web application classloader has already been configured.

When I was able to successfully configure the extraClasspath, I did it using qwe.xml file located in

{jetty.home}

/contexts/ directory, that does require the war property to be set in order to configure the context correctly.

We are going to make changes to the documentation to reflect that.

-Michael

Show
Michael Gorovoy added a comment - Oleg, As Jan pointed out, you cannot configure the extraClasspath attribute from jetty-web.xml because by the time it is processed web application classloader has already been configured. When I was able to successfully configure the extraClasspath, I did it using qwe.xml file located in {jetty.home} /contexts/ directory, that does require the war property to be set in order to configure the context correctly. We are going to make changes to the documentation to reflect that. -Michael
Hide
Permalink
Oleg Mikheev added a comment -

Sorry, I'm really lost in jetty terminology.
I think that it must be documented that jetty-web.xml is NOT a context configuration file despite the fact that it configures WebAppContext

Show
Oleg Mikheev added a comment - Sorry, I'm really lost in jetty terminology. I think that it must be documented that jetty-web.xml is NOT a context configuration file despite the fact that it configures WebAppContext
Hide
Permalink
Greg Wilkins added a comment -

Oleg,

that's a really good comment! We (the developers) know what we mean by context configuration file... but it takes fresh eyes to point out that it is not obvious as many things contribute to the configuration of a context.

What we really mean when we say "context configuration file" is the file that is scanned for by the context deployer (or now the context app provider of the deployment
manager).

We really do need to make that clearer. We also do need to point out when each type of file get's evaluated during the deployment lifecycle.

thanks for the insight!

Show
Greg Wilkins added a comment - Oleg, that's a really good comment! We (the developers) know what we mean by context configuration file... but it takes fresh eyes to point out that it is not obvious as many things contribute to the configuration of a context. What we really mean when we say "context configuration file" is the file that is scanned for by the context deployer (or now the context app provider of the deployment manager). We really do need to make that clearer. We also do need to point out when each type of file get's evaluated during the deployment lifecycle. thanks for the insight!
Hide
Permalink
Oleg Mikheev added a comment -

So, almost one year has passed since the changes to documentation were to be made.
As of now the documentation (http://docs.codehaus.org/display/JETTY/Classloading) states:

========
If you need to add some jars or classes that for some reason are not in $jetty.home/lib nor inside your webapp's WEB-INF/lib or WEB-INF/classes, you can add them directly to your webapp:

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
...
<Set name="extraClasspath">../my/classes:../my/jars/special.jar:../my/jars/other.jar</Set>
...
========

Is that excerpt still being totally wrong and misleading?
If yes - why can't it just be deleted not to deceive Jetty users?

Show
Oleg Mikheev added a comment - So, almost one year has passed since the changes to documentation were to be made. As of now the documentation ( http://docs.codehaus.org/display/JETTY/Classloading ) states: ======== If you need to add some jars or classes that for some reason are not in $jetty.home/lib nor inside your webapp's WEB-INF/lib or WEB-INF/classes, you can add them directly to your webapp: <Configure class="org.mortbay.jetty.webapp.WebAppContext"> ... <Set name="extraClasspath">../my/classes:../my/jars/special.jar:../my/jars/other.jar</Set> ... ======== Is that excerpt still being totally wrong and misleading? If yes - why can't it just be deleted not to deceive Jetty users?
Hide
Permalink
Greg Wilkins added a comment -

That documentation is correct, it just applies to a context/mycontext.xml file not to a jetty-web.xml file.
I have updated the doco to clarify that.

thanks for your reminder.

Show
Greg Wilkins added a comment - That documentation is correct, it just applies to a context/mycontext.xml file not to a jetty-web.xml file. I have updated the doco to clarify that. thanks for your reminder.
Hide
Permalink
Jesse McConnell added a comment -

closing resolved issues

Show
Jesse McConnell added a comment - closing resolved issues

People

  • Assignee:
    Michael Gorovoy
    Reporter:
    Oleg Mikheev
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: