Jetty vs Tomcat

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Jetty vs Tomcat

James-Vincent Brady




Hello,
   We are reworking out security here, and the best option available uses Tomcat valves. If I want to stay with Jetty is there a substitute/work alike?
Jim Brady

--

Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

Eric Rizzo
On 11/16/05, James-Vincent Brady <[hidden email]> wrote:
>
> Hello,
>    We are reworking out security here, and the best option available uses Tomcat valves. If I want to stay with Jetty is there a substitute/work alike?
> Jim Brady

My understanding is that Tomcat Valves are like Servlet filters but
apply at the server level instead of at the web-app level.
Do you really need to implement security at the server level? If you
can live with it at the web-app level, you can use servlet filters
which are J2EE spec compliant.

If you really want to go the server-level route, you might consider
implementing a custom Handler and adding that to the Listener that is
configured for your instance of Jetty Server.

HTH,
Eric


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
<a href="http://ads.osdn.com/?ad_idv28&alloc_id845&op=click">http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

Martin Roos
  Security starts in the developers head and not in writing any valves
anywhere.

  If you need something else than normal server filters then there's
something wrong with your application. This is ofcourse just my personal
opinion but if you have to rely on non-standard extensions to keep your
code safe, you should hire new developers who can do the same and stick
to the standards. And if you are really paranoid and dont trust your
usual container code then jetty let's you write your own very specific
handlers/socketservers, where you can do pretty much whatever you want.

Martin

Eric Rizzo wrote:

> On 11/16/05, James-Vincent Brady <[hidden email]> wrote:
>
>>Hello,
>>   We are reworking out security here, and the best option available uses Tomcat valves. If I want to stay with Jetty is there a substitute/work alike?
>>Jim Brady
>
>
> My understanding is that Tomcat Valves are like Servlet filters but
> apply at the server level instead of at the web-app level.
> Do you really need to implement security at the server level? If you
> can live with it at the web-app level, you can use servlet filters
> which are J2EE spec compliant.
>
> If you really want to go the server-level route, you might consider
> implementing a custom Handler and adding that to the Listener that is
> configured for your instance of Jetty Server.
>
> HTH,
> Eric
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> <a href="http://ads.osdn.com/?ad_idv28&alloc_id845&op=click">http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

Greg Wilkins-5
In reply to this post by James-Vincent Brady

James,

as other have said, a filter should be enough.

But Jetty has handlers that are roughly the same as valves.
They can be used for security and I'm sure any open source valve
could be easily ported to a handler (although it would be better
to port to a filter and thus to be portable!)

cheers


James-Vincent Brady wrote:

>
>
>
> Hello,
>    We are reworking out security here, and the best option available uses Tomcat valves. If I want to stay with Jetty is there a substitute/work alike?
> Jim Brady
>
> --
>
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

Warren Crossing
In reply to this post by James-Vincent Brady
IMHO valves are a bit of a waste of time, but so are filters, servlets
are not designed to be chained easily but the can be.

<Call name="addHandler">
         <Arg>
           <New class="com.opencloud.slee.mlet.web.SecurityContextHandler">
           </New>
         </Arg>
       </Call>
     <!--order dependent-->
       <Call name="addHandler">
         <Arg>
           <New class="org.mortbay.http.handler.ResourceHandler">
             <Set name="redirectWelcome">true</Set>
             <Set name="dirAllowed">false</Set>
           </New>
         </Arg>
      </Call>

Then I do this in my SecurityContextHandler (switch the subject) not to
self, some code here is overwritten =)


import org.mortbay.jaas.JAASUserPrincipal;

import org.mortbay.jetty.servlet.ServletHolder;
import org.mortbay.jetty.servlet.WebApplicationHandler;

import java.io.IOException;

import java.security.*;

import javax.security.auth.Subject;

import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpSession;
import javax.servlet.UnavailableException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class SecurityContextHandler extends WebApplicationHandler{
     //~ Constructors
------------------------------------------------------------------------------------------
     public SecurityContextHandler(){
     }


     public void dispatch(final String pathInContext,final
HttpServletRequest httpRequest,
         final HttpServletResponse httpResponse,final ServletHolder
servletHolder)
         throws IOException, ServletException, UnavailableException {

         final HttpServletRequest jrequest;
         final HttpServletResponse jresponse;

         if(httpRequest instanceof javax.servlet.ServletRequestWrapper){
 
jrequest=(javax.servlet.http.HttpServletRequest)((javax.servlet.ServletRequestWrapper)httpRequest).getRequest();
 
jresponse=(javax.servlet.http.HttpServletResponse)((javax.servlet.ServletResponseWrapper)httpResponse).getResponse();
         }else{
             jrequest=httpRequest;
             jresponse=httpResponse;
         }
             try{
             //dispatch and let the request be initialized
             super.dispatch(pathInContext,jrequest,jresponse,
                 //intercept the servlet holder handle invocation
                 new ServletHolder(){
                     //override with our access context switcher
                     public void handle(final ServletRequest
request,final ServletResponse response)
                         throws
ServletException,UnavailableException,IOException{
                         try{
                             //dont go back past here with check
permissions
                             AccessController.doPrivileged(new
PrivilegedExceptionAction(){
                                     public final Object run()
                                         throws PrivilegedActionException{
                                         final Principal principal;
                                         final Subject subject;
 
principal=httpRequest.getUserPrincipal();
                                         //do jetty specific stuff
                                         if(principal!=null)
 
subject=((JAASUserPrincipal)principal).getSubject();
                                         else
                                             subject=null;
                                             //do the switch
                                             Subject.doAsPrivileged(subject,
                                                 new
PrivilegedExceptionAction(){
                                                     public final Object
run()
                                                         throws
PrivilegedActionException{
                                                         try{
                                                             //call
original handler
 
SecurityContextHandler.super.dispatch(pathInContext,
 
(javax.servlet.http.HttpServletRequest)request,
 
(javax.servlet.http.HttpServletResponse)response,
 
servletHolder);
                                                         } catch
(IOException xIO){
                                                             throw new
PrivilegedActionException(xIO);
                                                         }
                                                          catch
(ServletException xS){
                                                             throw new
PrivilegedActionException(xS);
                                                         }
                                                         return null;
                                                     }
                                                 },null);
                                        //always return null
                                         return null;
                                     }
                                 });
                         }
                          catch (Exception exception){
                             throw new IOException(exception.getMessage());
                         }
                     }
                 });
         }
          catch (Exception exception){
             exception.printStackTrace();
             throw new IOException(exception.getMessage());
         }
     }

}

James-Vincent Brady wrote:

>
>
>
> Hello,
>    We are reworking out security here, and the best option available uses Tomcat valves. If I want to stay with Jetty is there a substitute/work alike?
> Jim Brady
>
> --
>
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

James-Vincent Brady
In reply to this post by James-Vincent Brady




Hallo All,
  Thank you for the reply. From some of the comments it is obvious I may have misled some of you as to the requirements.
  I am writing an application to needs to integrate into firm standands - the "we" is not me personally but the whole firm. There are a number of possible ways of doing this, but the option using using Tomcat valves is clearly the best. Tomcat valves allow some functionality that Servlet Filters do not.

  Look at
                                                                                                                     
                                                                                                                     
                                                                                                                     

http://wiki.jboss.org/wiki/Wiki.jsp?page=CustomizingSecurityUsingValves

...
Servlet filters are called after any declarative security checks required by the web.xml settings. This means that a servlet filter cannot participate in FORM based authentication requests. The typical use of a filter in the context of security decisions is to either augment or replace the servlet declarative security model.

This is exactly the requirement here. The authentication is being moved outside the web-application and the authenticated user is then used for authorisation.

I hope the makes it clear.

Jim Brady

--

Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Jetty vs Tomcat

Chris Haynes
Just curious....

You declare below the desire "to integrate into firm standards".

The jboss Wiki you cite and quote from also says:

"[ A valve is]  similar in concept to a standard servlet filter, but it has
access to more internal tomcat information. The drawback to using valves is that
they are specific to the tomcat web container. "

Is there some standard for valves that we (and the wiki authors) have
overlooked?

Chris Haynes




 "James-Vincent Brady" elaborates:

>
>
> Hallo All,
>  Thank you for the reply. From some of the comments it is obvious I may have
> misled some of you as to the requirements.
>  I am writing an application to needs to integrate into firm standands - the
> "we" is not me personally but the whole firm. There are a number of possible
> ways of doing this, but the option using using Tomcat valves is clearly the
> best. Tomcat valves allow some functionality that Servlet Filters do not.
>
>  Look at
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=CustomizingSecurityUsingValves
>
> ...
> Servlet filters are called after any declarative security checks required by
> the web.xml settings. This means that a servlet filter cannot participate in
> FORM based authentication requests. The typical use of a filter in the context
> of security decisions is to either augment or replace the servlet declarative
> security model.
>
> This is exactly the requirement here. The authentication is being moved
> outside the web-application and the authenticated user is then used for
> authorisation.
>
> I hope the makes it clear.
>
> Jim Brady
>





-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Jetty vs Tomcat

Martin Roos
That all seems rather weird to me too.

Anyway, i can only suggest 2 methods to overcome this thing

a) write a quick replacement for valves that you can use in jetty and provides the same
functionality [writing speed = ok, future = dim]

b) create a compatibility api for jetty for tomcat valves so you can use the same code in
jetty and in tomcat. [writing speed = not so ok, future = good]

if you really think you need to use firm standards that disregard the j2ee api standards
(this is really weird aproach ... ehh ... not my problem anyway) then i suggest you go for
b, if direct simulation of valves doesnt work, create a middle layer that will work the
same in jetty and tomcat (and if you are kind enough, share it with the others).

if you create just some quick-hack that enables you to control actions before servlet
filters are bought in, you will run into incompability troubles and code multiplying
later, so for long lasting projects i suggest you avoid this.

martin


Chris Haynes wrote:

> Just curious....
>
> You declare below the desire "to integrate into firm standards".
>
> The jboss Wiki you cite and quote from also says:
>
> "[ A valve is]  similar in concept to a standard servlet filter, but it
> has access to more internal tomcat information. The drawback to using
> valves is that they are specific to the tomcat web container. "
>
> Is there some standard for valves that we (and the wiki authors) have
> overlooked?
>
> Chris Haynes
>
>
>
>
> "James-Vincent Brady" elaborates:
>
>>
>>
>> Hallo All,
>>  Thank you for the reply. From some of the comments it is obvious I
>> may have misled some of you as to the requirements.
>>  I am writing an application to needs to integrate into firm standands
>> - the "we" is not me personally but the whole firm. There are a number
>> of possible ways of doing this, but the option using using Tomcat
>> valves is clearly the best. Tomcat valves allow some functionality
>> that Servlet Filters do not.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Jetty vs Tomcat

James-Vincent Brady
In reply to this post by James-Vincent Brady




Hello Martin,


That all seems rather weird to me too.

Anyway, i can only suggest 2 methods to overcome this thing

a) write a quick replacement for valves that you can use in jetty and provides the same
functionality [writing speed = ok, future = dim]

b) create a compatibility api for jetty for tomcat valves so you can use the same code in
jetty and in tomcat. [writing speed = not so ok, future = good]

if you really think you need to use firm standards that disregard the j2ee api standards
(this is really weird aproach ... ehh ... not my problem anyway) then i suggest you go for
b, if direct simulation of valves doesnt work, create a middle layer that will work the
same in jetty and tomcat (and if you are kind enough, share it with the others).

if you create just some quick-hack that enables you to control actions before servlet
filters are bought in, you will run into incompability troubles and code multiplying
later, so for long lasting projects i suggest you avoid this.

martin

  I think obviously (b) is the route I would like to go. I was kind of hoping somebody already had done it and could help me out. I would have thought this was a plus for Jetty anyway as it eases the way for people who, for whatever reason, want to move to Jetty from Tomcat. My problem is to know how to, and where to, integrate the work-alike into Jetty. I'm willing to do the coding and testing if someone can point me the way (and I'll post the code here when I'm finished).

Jim Brady

--

Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Jetty vs Tomcat

Eric Rizzo
On 11/24/05, James-Vincent Brady <[hidden email]> wrote:
>
> Hello Martin,
>   I think obviously (b) is the route I would like to go. I was kind of hoping somebody already had done it and could help me out. I would have thought this was a plus for Jetty anyway as it eases the way for people who, for whatever reason, want to move to Jetty from Tomcat. My problem is to know how to, and where to, integrate the work-alike into Jetty. I'm willing to do the coding and testing if someone can point me the way (and I'll post the code here when I'm finished).


As I and others have suggested, you should look at Jetty's Handler
class. Here's a quote from an earlier response I wrote:

"If you really want to go the server-level route, you might consider
implementing a custom Handler and adding that to the Listener that is
configured for your instance of Jetty Server."

HTH,
Eric


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: NullPointerException in Jetty's ContextLoader class.

Tim Courtney

> From: Greg Wilkins
> Subject: Re: NullPointerException in Jetty's ContextLoader class.
> Date: 2005-08-24 21:05:12 GMT (13 weeks, 4 days, 3 hours and 7 minutes
ago)

> There was a bug added to the listener that stopped it opening the
socket on
> the second start.

> Fixed in 5.1.5rc1, so give that a try.

> cheers



Hello

I've got some trouble with my Axis 1.3 config. I found the above thread
regarding a problem Artur Zielazny had restarting Axis back in August.

I'm having the same trouble when I use the HTTP Admin tool. (Jetty
5.1.6)

The "stop" works but then when I click the "start", the
"WebApplicationContext" part throws an exception (the
org.mortbay.jetty.servlet.WebApplicationHandler restarts fine).

Do I need to edit my /jetty/etc/admin.xml file when I add a new webapp?

Thanks
Tim


The trace from the exception I get is below:



DEBUG SocketListener1-0 org.mortbay.http.ContextLoader - p0 loaded class
org.apache.axis.transport.http.AdminServlet
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.Holder - Started
holder of class org.apache.axis.transport.http.AdminServlet
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of /WEB-INF in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of / in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.apache.axis.transport.http.AxisServlet - In
AxisServletBase init
DEBUG SocketListener1-0 org.apache.axis.transport.http.AxisServlet -
Enter: getEngine()
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of /WEB-INF in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.mortbay.http.ContextLoader - try getResource
META-INF/services/org.apache.axis.EngineConfigurationFactory from null
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
EXCEPTION
java.lang.NullPointerException
        at
org.mortbay.http.ContextLoader.getResource(ContextLoader.java:257)
        at
org.apache.commons.discovery.jdk.JDK12Hooks.getResources(JDK12Hooks.java
:149)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
es(DiscoverResources.java:153)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
e(DiscoverResources.java:129)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.hasNext(Discov
erResources.java:116)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassNames(DiscoverNamesInFile.java:186)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassName(DiscoverNamesInFile.java:170)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.hasNex
t(DiscoverNamesInFile.java:157)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.getNextIte
rator(NameDiscoverers.java:143)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.hasNext(Na
meDiscoverers.java:126)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.getNextResource(ResourceClassDiscoverImpl.java:159)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.hasNext(ResourceClassDiscoverImpl.java:147)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run(Eng
ineConfigurationFactoryFinder.java:120)
        at java.security.AccessController.doPrivileged(Native Method)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor
y(EngineConfigurationFactoryFinder.java:113)
        at
org.apache.axis.transport.http.AxisServletBase.getEngineEnvironment(Axis
ServletBase.java:273)
        at
org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase
.java:172)
        at
org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase
.java:396)
        at
org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java
:112)
        at javax.servlet.GenericServlet.init(GenericServlet.java:168)
        at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:3
83)
        at
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
        at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandl
er.java:446)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebAp
plicationHandler.java:321)
        at
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationCo
ntext.java:509)
        at
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:
149)
        at org.mortbay.util.Container.start(Container.java:72)
        at
org.mortbay.servlet.AdminServlet.doAction(AdminServlet.java:169)
        at org.mortbay.servlet.AdminServlet.doGet(AdminServlet.java:203)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
        at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:66
6)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
        at org.mortbay.http.HttpServer.service(HttpServer.java:927)
        at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
        at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
        at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
        at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.WebApplicationHandler
- jsr154filter=null
WARN SocketListener1-0 org.mortbay.servlet.AdminServlet - EXCEPTION
java.lang.NullPointerException
        at
org.mortbay.http.ContextLoader.getResource(ContextLoader.java:257)
        at
org.apache.commons.discovery.jdk.JDK12Hooks.getResources(JDK12Hooks.java
:149)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
es(DiscoverResources.java:153)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
e(DiscoverResources.java:129)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.hasNext(Discov
erResources.java:116)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassNames(DiscoverNamesInFile.java:186)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassName(DiscoverNamesInFile.java:170)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.hasNex
t(DiscoverNamesInFile.java:157)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.getNextIte
rator(NameDiscoverers.java:143)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.hasNext(Na
meDiscoverers.java:126)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.getNextResource(ResourceClassDiscoverImpl.java:159)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.hasNext(ResourceClassDiscoverImpl.java:147)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run(Eng
ineConfigurationFactoryFinder.java:120)
        at java.security.AccessController.doPrivileged(Native Method)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor
y(EngineConfigurationFactoryFinder.java:113)
        at
org.apache.axis.transport.http.AxisServletBase.getEngineEnvironment(Axis
ServletBase.java:273)
        at
org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase
.java:172)
        at
org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase
.java:396)
        at
org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java
:112)
        at javax.servlet.GenericServlet.init(GenericServlet.java:168)
        at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:3
83)
        at
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
        at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandl
er.java:446)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebAp
plicationHandler.java:321)
        at
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationCo
ntext.java:509)
        at
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:
149)
        at org.mortbay.util.Container.start(Container.java:72)
        at
org.mortbay.servlet.AdminServlet.doAction(AdminServlet.java:169)
        at org.mortbay.servlet.AdminServlet.doGet(AdminServlet.java:203)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
        at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:66
6)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
        at org.mortbay.http.HttpServer.service(HttpServer.java:927)
        at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
        at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
        at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
        at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

RE: Re: NullPointerException in Jetty's ContextLoader class.

Tim Courtney
Ok, ignore this one.

I did a fresh install of jetty 5.1.6 & axis last night and its all
working fine.

Cheers



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Tim
Courtney
Sent: Monday, 28 November 2005 11:28 AM
To: [hidden email]
Subject: [Jetty-support] Re: NullPointerException in Jetty's
ContextLoader class.



> From: Greg Wilkins
> Subject: Re: NullPointerException in Jetty's ContextLoader class.
> Date: 2005-08-24 21:05:12 GMT (13 weeks, 4 days, 3 hours and 7 minutes
ago)

> There was a bug added to the listener that stopped it opening the
socket on
> the second start.

> Fixed in 5.1.5rc1, so give that a try.

> cheers



Hello

I've got some trouble with my Axis 1.3 config. I found the above thread
regarding a problem Artur Zielazny had restarting Axis back in August.

I'm having the same trouble when I use the HTTP Admin tool. (Jetty
5.1.6)

The "stop" works but then when I click the "start", the
"WebApplicationContext" part throws an exception (the
org.mortbay.jetty.servlet.WebApplicationHandler restarts fine).

Do I need to edit my /jetty/etc/admin.xml file when I add a new webapp?

Thanks
Tim


The trace from the exception I get is below:



DEBUG SocketListener1-0 org.mortbay.http.ContextLoader - p0 loaded class
org.apache.axis.transport.http.AdminServlet
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.Holder - Started
holder of class org.apache.axis.transport.http.AdminServlet
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of /WEB-INF in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of / in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.apache.axis.transport.http.AxisServlet - In
AxisServletBase init
DEBUG SocketListener1-0 org.apache.axis.transport.http.AxisServlet -
Enter: getEngine()
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
getRealPath of /WEB-INF in
org.mortbay.jetty.servlet.WebApplicationHandler@dfcb47
DEBUG SocketListener1-0 org.mortbay.http.ContextLoader - try getResource
META-INF/services/org.apache.axis.EngineConfigurationFactory from null
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.ServletHandler -
EXCEPTION
java.lang.NullPointerException
        at
org.mortbay.http.ContextLoader.getResource(ContextLoader.java:257)
        at
org.apache.commons.discovery.jdk.JDK12Hooks.getResources(JDK12Hooks.java
:149)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
es(DiscoverResources.java:153)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
e(DiscoverResources.java:129)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.hasNext(Discov
erResources.java:116)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassNames(DiscoverNamesInFile.java:186)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassName(DiscoverNamesInFile.java:170)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.hasNex
t(DiscoverNamesInFile.java:157)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.getNextIte
rator(NameDiscoverers.java:143)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.hasNext(Na
meDiscoverers.java:126)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.getNextResource(ResourceClassDiscoverImpl.java:159)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.hasNext(ResourceClassDiscoverImpl.java:147)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run(Eng
ineConfigurationFactoryFinder.java:120)
        at java.security.AccessController.doPrivileged(Native Method)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor
y(EngineConfigurationFactoryFinder.java:113)
        at
org.apache.axis.transport.http.AxisServletBase.getEngineEnvironment(Axis
ServletBase.java:273)
        at
org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase
.java:172)
        at
org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase
.java:396)
        at
org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java
:112)
        at javax.servlet.GenericServlet.init(GenericServlet.java:168)
        at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:3
83)
        at
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
        at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandl
er.java:446)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebAp
plicationHandler.java:321)
        at
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationCo
ntext.java:509)
        at
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:
149)
        at org.mortbay.util.Container.start(Container.java:72)
        at
org.mortbay.servlet.AdminServlet.doAction(AdminServlet.java:169)
        at org.mortbay.servlet.AdminServlet.doGet(AdminServlet.java:203)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
        at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:66
6)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
        at org.mortbay.http.HttpServer.service(HttpServer.java:927)
        at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
        at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
        at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
        at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
DEBUG SocketListener1-0 org.mortbay.jetty.servlet.WebApplicationHandler
- jsr154filter=null
WARN SocketListener1-0 org.mortbay.servlet.AdminServlet - EXCEPTION
java.lang.NullPointerException
        at
org.mortbay.http.ContextLoader.getResource(ContextLoader.java:257)
        at
org.apache.commons.discovery.jdk.JDK12Hooks.getResources(JDK12Hooks.java
:149)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
es(DiscoverResources.java:153)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.getNextResourc
e(DiscoverResources.java:129)
        at
org.apache.commons.discovery.resource.DiscoverResources$1.hasNext(Discov
erResources.java:116)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassNames(DiscoverNamesInFile.java:186)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.getNex
tClassName(DiscoverNamesInFile.java:170)
        at
org.apache.commons.discovery.resource.names.DiscoverNamesInFile$1.hasNex
t(DiscoverNamesInFile.java:157)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.getNextIte
rator(NameDiscoverers.java:143)
        at
org.apache.commons.discovery.resource.names.NameDiscoverers$1.hasNext(Na
meDiscoverers.java:126)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.getNextResource(ResourceClassDiscoverImpl.java:159)
        at
org.apache.commons.discovery.resource.classes.ResourceClassDiscoverImpl$
1.hasNext(ResourceClassDiscoverImpl.java:147)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder$1.run(Eng
ineConfigurationFactoryFinder.java:120)
        at java.security.AccessController.doPrivileged(Native Method)
        at
org.apache.axis.configuration.EngineConfigurationFactoryFinder.newFactor
y(EngineConfigurationFactoryFinder.java:113)
        at
org.apache.axis.transport.http.AxisServletBase.getEngineEnvironment(Axis
ServletBase.java:273)
        at
org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase
.java:172)
        at
org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase
.java:396)
        at
org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java
:112)
        at javax.servlet.GenericServlet.init(GenericServlet.java:168)
        at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:3
83)
        at
org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:243)
        at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandl
er.java:446)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebAp
plicationHandler.java:321)
        at
org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationCo
ntext.java:509)
        at
org.mortbay.jetty.plus.PlusWebAppContext.doStart(PlusWebAppContext.java:
149)
        at org.mortbay.util.Container.start(Container.java:72)
        at
org.mortbay.servlet.AdminServlet.doAction(AdminServlet.java:169)
        at org.mortbay.servlet.AdminServlet.doGet(AdminServlet.java:203)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
        at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:66
6)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
        at org.mortbay.http.HttpServer.service(HttpServer.java:927)
        at
org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
        at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
        at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
)
        at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support