Comment 1 Jan Bartel 2014-02-18 20:17:05 EST

Dan,

You seem to be starting jetty and deploying webapps in a custom embedded fashion. Does any of that code change the Server or System classes for WebAppContext? The defaults specifically excludes the package org.eclipse.jetty.servlet.listener - so that means that they are visible to the webapp.



Jan

Comment 2 Dan Connell 2014-02-19 11:35:40 EST

Hi Jan, 

To answer your questions: 

> You seem to be starting jetty and deploying webapps in a custom embedded fashion. 
Yes we are.

> Does any of that code change the Server or System classes for WebAppContext? 
No WebAppContext is not changed or affected nor any related class.

> The defaults specifically excludes the package org.eclipse.jetty.servlet.listener - so that means that they are visible to the webapp.
Not sure what you mean by this. Can you elaborate a bit more ?

Comment 3 Jan Bartel 2014-02-19 16:47:27 EST

In WebAppContext, we set up some default System and Server classes. See https://wiki.eclipse.org/Jetty/Reference/Jetty_Classloading for a discussion of System and Server classes. See https://github.com/eclipse/jetty.project/blob/jetty-8.1.3.v20120416/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebAppContext.java and the comments around lines 89 and 107 for what the System and Server classes are for jetty-8.1.3.

If you can dump out the jars on the webapp's classloader, and then the jars on its parent you can check if those listeners are there.

From the log trace, it also looks like the jsp jars are missing - is that intentional or another symptom?

cheers
Jan


(In reply to Dan Connell from comment #2)
> Hi Jan, 
> 
> To answer your questions: 
> 
> > You seem to be starting jetty and deploying webapps in a custom embedded fashion. 
> Yes we are.
> 
> > Does any of that code change the Server or System classes for WebAppContext? 
> No WebAppContext is not changed or affected nor any related class.
> 
> > The defaults specifically excludes the package org.eclipse.jetty.servlet.listener - so that means that they are visible to the webapp.
> Not sure what you mean by this. Can you elaborate a bit more ?

Comment 4 Dan Connell 2014-02-20 13:37:58 EST

Hi Jan, 

Thanks for that. I think I understand now. I did a search looking for ways to dump the jars that are loaded but I wasn't able to find anything good. Can you provide some pointers please ? 

Also, as far as the JSP's are concerned, our application isn't having any difficulty in this area, so the error message looks to be a red herring and we can ignore it for now - I don't think its related. 

So to make sure I understand where we are going with this....
if I check the Webapp and JVM classloaders for the erring files and find them in one of them, it is then likely that the classloader doesn't have access to them and needs to be added to that particular classloader programmatically ? 

Thanks !

Comment 5 Jan Bartel 2014-02-20 17:56:07 EST

(In reply to Dan Connell from comment #4)
> Hi Jan, 
> 
> Thanks for that. I think I understand now. I did a search looking for ways
> to dump the jars that are loaded but I wasn't able to find anything good.
> Can you provide some pointers please ? 

Difficult with jetty-8.1.3 and difficult in any case because your app's code has not been reached when the problem occurs, so you can't use the standard technique of walking the classloader hierarchy printing out all the urls from the instances of the URLClassloaders.  Have you tried enabling debug? The o.e.j.w.WebAppClassLoader will print out what it is adding to its classpath with debug enabled so that will show you the webapp's classpath. As for the container classpath, you should be able to dump that from the code that starts up jetty (assuming the classloaders used extend URLClassloader, or they're your classloader so you can implement dump). From the code that starts up jetty, also try loading the org.eclipse.jetty.servlet.listener.ELContextCleaner class to double check it can be loaded - might give you some insights.
 
> Also, as far as the JSP's are concerned, our application isn't having any
> difficulty in this area, so the error message looks to be a red herring and
> we can ignore it for now - I don't think its related. 

So you don't have any jsps in your webapp? Has this error message always been there when you run your app? Has this app ever worked in the way that you're trying to run it? In other words, what things have changed - that can help you zero in on the problem.

> So to make sure I understand where we are going with this....
> if I check the Webapp and JVM classloaders for the erring files and find
> them in one of them, it is then likely that the classloader doesn't have
> access to them and needs to be added to that particular classloader
> programmatically ? 

Not necessarily - I asked if your code overrode the defaults for the System and Server classes because that does affect which classes will be visible via the classloaders. If you haven't changed the defaults then this probably isn't the problem. 

In fact, the jar that contains the ELContextCleaner and IntrospectorCleaner is one of the fundamental jars in jetty, so it would be very surprising if it isn't on the classpath, in fact I don't think your app would be getting as far as it does if it wasn't on the container's classpath. 

Looking at your stacktrace, the parent classloader of the WebAppClassLoader is 
org.eclipse.core.runtime.internal.adaptor.ContextFinder.  You might try googling for info on ClassNotFound exceptions using that loader.

BTW I've double checked the manifest headers for jetty-servlet-8.1.3 and I can definitely see an Export statement for org.eclipse.jetty.servlet.listener package, so I don't see how it could be osgi classloading that is the problem.


Jan


> 
> Thanks !

Comment 6 Dan Connell 2014-02-21 11:37:35 EST

Hi Jan, 

Thanks for the suggestion, I'll try the debug option. I can't use the OSGI console at all because our product isn't a full Eclipse tool, but an RCP App. 

We do have JSP in there and I have seen this error before with no effect on the rest of the app. 

I'll try that research as well and see what I can find. Thanks !

Comment 7 Dan Connell 2014-02-25 14:28:27 EST

Hi Jan, 

Unfortunately my research for class not found exceptions for org.eclipse.core.runtime.internal.adaptor.ContextFinder didn't yield any fruit. I ran RPE with -debug -consolelog and I've attached the log file, but it doesn't list the classes from the classloader. Did I misunderstand your instructions ? Also, is there a way to load org.eclipse.jetty.servlet.listener.ELContextCleaner class without having the osgi console ? 

Here is the contents of the DOS window from the debug: 

Start VM: -Xms56m
-Xmx1024m
-Dfile.encoding=UTF-8
-Dcom.ibm.rational.rpe.console.limit=100000
-Dcom.ibm.rational.rpews.url
-Dosgi.configuration.area=@user.home/Application Data/IBM/Rational/RPE_20140210_
1541/Launcher/configuration/
-Dosgi.instance.area=@user.home/Application Data/IBM/Rational/RPE_20140210_1541/
Launcher/workspace/
-Dcom.ibm.rational.rpe.disableDefaultAuthenticator=true
-DRPE_HOME=C:\Program Files (x86)\IBM\Rational\Publishing Engine
-Djava.class.path=C:\Program Files (x86)\IBM\Rational\Publishing Engine\launcher
\\startup.jar
-os win32
-ws win32
-arch x86
-showsplash
-launcher C:\Program Files (x86)\IBM\Rational\Publishing Engine\launcher\rpe-lau
ncher.exe
-name Rpe-launcher
--launcher.library C:\Program Files (x86)\IBM\Rational\Publishing Engine\launche
r\eclipse_1503.dll
-startup C:\Program Files (x86)\IBM\Rational\Publishing Engine\launcher\\startup
.jar
--launcher.overrideVmargs
-debug
-consolelog
-vm C:\Program Files (x86)\IBM\Java60\jre\bin\j9vm\jvm.dll
-vmargs
-Xms56m
-Xmx1024m
-Dfile.encoding=UTF-8
-Dcom.ibm.rational.rpe.console.limit=100000
-Dcom.ibm.rational.rpews.url
-Dosgi.configuration.area=@user.home/Application Data/IBM/Rational/RPE_20140210_
1541/Launcher/configuration/
-Dosgi.instance.area=@user.home/Application Data/IBM/Rational/RPE_20140210_1541/
Launcher/workspace/
-Dcom.ibm.rational.rpe.disableDefaultAuthenticator=true
-DRPE_HOME=C:\Program Files (x86)\IBM\Rational\Publishing Engine
-Djava.class.path=C:\Program Files (x86)\IBM\Rational\Publishing Engine\launcher
\\startup.jar
Configuration location:
    file:/C:/Users/IBM_ADMIN/Application Data/IBM/Rational/RPE_20140210_1541/Lau
ncher/configuration/
Configuration file:
    file:/C:/Users/IBM_ADMIN/Application Data/IBM/Rational/RPE_20140210_1541/Lau
ncher/configuration/config.ini loaded
Install location:
    file:/c:/Program Files (x86)/IBM/Rational/Publishing Engine/launcher/
Configuration file:
    file:/c:/Program Files (x86)/IBM/Rational/Publishing Engine/launcher/configu
ration/config.ini loaded
Shared configuration location:
    file:/c:/Program Files (x86)/IBM/Rational/Publishing Engine/launcher/configu
ration/
Framework located:
    file:/C:/Program Files/IBM/IBMIMShared/plugins/org.eclipse.osgi_3.8.2.v20130
124-134944.jar
Framework classpath:
    file:/C:/Program Files/IBM/IBMIMShared/plugins/org.eclipse.osgi_3.8.2.v20130
124-134944.jar
Splash location:
    C:\Users\IBM_ADMIN\Application Data\IBM\Rational\RPE_20140210_1541\Launcher\
configuration\org.eclipse.equinox.launcher\com.ibm.rational.rpe.launcher_1.2.110
.v20140210_1341\splash.bmp
Debug options:
    file:/C:/Program Files (x86)/IBM/Rational/Publishing Engine/launcher/.option
s not found
Time to load bundles: 67
Starting application: 1788

Comment 8 Dan Connell 2014-03-19 11:27:39 EDT

Hi again, 

Can you please provide me with the steps( or at least clarify my confusion as to what you mean) that you were describing in comment 5, first paragraph ? I'm not sure what you mean by debug and I'm ignorant as to how to dump out the classpath information from either the webapp or classloader. 

Thanks !

Comment 9 Jan Bartel 2014-12-04 09:29:55 EST

Hi Dan,

Sorry for the lack of communication - somehow I became unassigned from this issue, so I hadn't seen your comments.

Where are we at with it? Note that jetty-8 is at release level 8.1.16, so I hope by now you've upgraded to that at least.

regards,
Jan

Comment 10 Jan Bartel 2015-05-07 00:22:50 EDT

Dan,

Is this issue still live, or have you solved it and it can be closed?

thanks
Jan

Comment 11 Dan Connell 2015-05-11 11:33:09 EDT

Hi Jan, 

No, I'm afraid I haven't upgraded yet or resolved the issue. At the moment we are looking at work arounds to it. I tried changing the web.xml and webdefault.xml files and add to the <servlet> tag settings so that the compiler will tolerate 1.8 using the vm settings. No luck there either. I would have thought that one would have worked since many postings online about it. Which upgraded jetty works with 1.8 again ? That may be my last resort.

Comment 12 Jan Bartel 2015-07-08 03:51:06 EDT

Dan,

Jetty is now at 9.3.0 - that actually requires jdk 1.8.


BTW, to enable debug with jetty, you set a system property with the name of the package or class and the level of log output you want. 

Eg, to enable debug level for the whole org.eclipse.jetty.webapp package, do:
  -Dorg.eclipse.jetty.webapp.LEVEL=DEBUG

    to enable debug level for just the WebAppClassLoader class, do:
  -Dorg.eclipse.jetty.webapp.WebAppClassLoader.LEVEL=DEBUG

Jan

Comment 13 Jesse McConnell 2016-02-16 16:37:00 EST

please reopen on github issues if this remains a problem