headers
Jan Bartel | 1 Jun 2008 02:29

Re: [jetty-user] Setting the classpath when using WebappDeployer

mantis666,

You can put the jars you want to access in multiple webapps
in $JETTY-HOME/lib/ext and leave parentLoaderPriority as false.
Each webapp's classloader will then delegate to the jetty container
classloader to load the classes from the common directory.

cheers
Jan

mantis666 wrote:
> Hi,
>    I'm using the following code to deploy a webappdeployer in an embedded
> jetty server.
> 
> Server jettyWebServer = new Server(8080);
> WebAppDeployer webAppDeployer = new WebAppDeployer();
> webAppDeployer.setContexts( jettyWebServer );
> webAppDeployer.setWebAppDir( "webapp" );
> webAppDeployer.setExtract( true );
> webAppDeployer.setParentLoaderPriority( false );
> webAppDeployer.start();
> 		
> 		       
> jettyWebServer.setStopAtShutdown( true );
>  jettyWebServer.setSendServerVersion( true );
> 		                               
> jettyWebServer.start();
> jettyWebServer.join(); 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jan Bartel | 1 Jun 2008 02:49

Re: [jetty-user] Hot redeployment of WebApp in embedded mode problem with Jetty 6..10

Dmitri,

On a redeploy, after you call server.setHandler(newapp), also call
newapp.start().

cheers
Jan

Dmitri Livotov wrote:
> Hi,
> 
> I stuck with a weird problem with Jetty 6.1.10 in embedded  mode. In
> short terms, in my application, I do deploy a .war file, then monitor
> for changes and redeploy it when necessary. The problem is as follows:
> 
> - when .war file is deployed for the first time after jetty startup
> everything is fine.
> 
> - after when I redeploy the .war file or even undeploy first one and
> deploy another .war - I got a problem - the .war file seemsto be
> deployed as I see servlets are starting up and doing some background
> job, however, I do not see anymore deployed web application context
> files in a web browser, getting Jetty's 404 page. This happens only
> after undeploy and redeploy of a web applicaiton, so, probably Im doing
> something not correct, would you please point me if I'm wrong in the any
> of the following code:
> 
> 1) The jetty is started from my application as follows:
> 
> Server jetty = new Server();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Brown | 2 Jun 2008 06:40
Picon

Re: [jetty-user] odd issue with continuations and select/NIO


Hi, David --

I just tried with Java5 on my Mac, and the issue occurs after a few  
repetitions of

	mvn -Dtest=C* test

The trace in this case is the same as some of them on Java6:

2008-05-29 21:28:40.635::WARN:  handle failed
java.lang.IndexOutOfBoundsException: -6630
	at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:209)
	at org.mortbay.io.nio.NIOBuffer.peek(NIOBuffer.java:86)
	at org.mortbay.io.AbstractBuffer.peek(AbstractBuffer.java:306)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:656)

FWIW, I'm not able to provoke the issue by running the tests in  
sequence (mvn test), so try repeated runs of either test with a single  
client implementation.

-- Paul

On May 29, 2008, at 8:59 PM, David Yu wrote:

> Hi Paul,
>
> I'm beginning to think this is an java1.6 related issue.  Tried this  
> many times on windows xp and fc7(java 1.5), and the test completed  
> without errors.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Igor E. Poteryaev | 2 Jun 2008 12:32
Picon
Favicon

[jetty-user] possible bug in jetty 6.x request logging

Hi, all

Before creating jira issue I just want to ask list for help.

Problem:
Sometimes in request log instead of remote IP address I see null.

>From my ${jetty.home}/logs/request.log:
.......
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
null -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0" 200 
1491 "-" "ApacheBench/2.0.40-dev"
^^^^^
oops!
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
127.0.0.1 -  -  [01/jun/2008:08:08:37 +0000] "GET /javadoc/ HTTP/1.0"
200 1491 "-" "ApacheBench/2.0.40-dev"
.......

I tried to isolate this issue and finally can reproduce it with
such simple context configuraion file:
(Continue reading)

Permalink | Reply | 0 comments |
headers
mantis666 | 2 Jun 2008 13:02

Re: [jetty-user] Setting the classpath when using WebappDeployer


Thanks. I later discovered the problem was that I was trying to share SLF4J
in this manner, and Jetty classifies org.slf4j.* as server classes so it
blocks the webapps access to them. The only solution is to put the slf4j jar
in the WEB-INF/lib directory. Now that I understand what is going on, I
don't have a problem with it, but it would be nice to understand why Jetty
does this specifically with SLF4J.

 My guess is that doing this allows the webapp's SLF4J to use a different
static binding to an underlying logging system then the one Jetty uses. eg)
Jetty SLF4J bridged to JDK 1.4 and SLF4J in my web-app bridged to log4j or
logback. Don't think that would be possible if the web-app shared the SLF4J
loaded by the parent classloader.

janb wrote:
> 
> mantis666,
> 
> You can put the jars you want to access in multiple webapps
> in $JETTY-HOME/lib/ext and leave parentLoaderPriority as false.
> Each webapp's classloader will then delegate to the jetty container
> classloader to load the classes from the common directory.
> 
> cheers
> Jan
> 
> 
> 
> mantis666 wrote:
>> Hi,
(Continue reading)

Permalink | Reply | 1 comment |
headers
gaurav_abbi | 3 Jun 2008 08:58
Picon
Favicon

[jetty-user] jetty unable to parse IPV6 addressing


hi,
when we send a http request to a jetty server through a proxy with SSL
enabled, it sends the full address in the Http command like this.
GET https://[2001:db8:10:110::a75:2a3]:28188/hello HTTP/1.1

Jetty fails to parse this IPV6 address format and throws an exception when
we try to get different parts of the command like URI, server port etc.

[2008-05-22 03:31:10.657] ERROR 000000000000 GLOBAL_SCOPE The servlet caught
a throwable (of type class java.lang.NumberFormatException) and is erroring
out: db8:10:110::a75:2a3]:28188
[2008-05-22 03:31:10.657] ERROR 000000000000 GLOBAL_SCOPE [1211441470657]
db8:10:110::a75:2a3]:28188
[2008-05-22 03:31:10.66] ERRORDTL 000000000000 GLOBAL_SCOPE
[1211441470657]java.lang.NumberFormatException: db8:10:110::a75:2a3]:28188
at org.mortbay.util.TypeUtil.parseInt(TypeUtil.java:380)
at org.mortbay.jetty.HttpURI.getPort(HttpURI.java:381)
at org.mortbay.jetty.Request.getServerName(Request.java:986)
at org.mortbay.jetty.Request.getServerPort(Request.java:1042)

this is clearly an issue with jetty not handling IPV6 address format.

can it be fixed.

--

-- 
View this message in context: http://www.nabble.com/jetty-unable-to-parse-IPV6-addressing-tp17617199p17617199.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thorbjørn Ravn Andersen | 3 Jun 2008 18:37
Picon

Re: [jetty-user] Setting the classpath when using WebappDeployer

mantis666 skrev  den 02-06-2008 13:02:
> Thanks. I later discovered the problem was that I was trying to share SLF4J
> in this manner, and Jetty classifies org.slf4j.* as server classes so it
> blocks the webapps access to them. The only solution is to put the slf4j jar
> in the WEB-INF/lib directory. Now that I understand what is going on, I
> don't have a problem with it, but it would be nice to understand why Jetty
> does this specifically with SLF4J.
>
>  My guess is that doing this allows the webapp's SLF4J to use a different
> static binding to an underlying logging system then the one Jetty uses. eg)
> Jetty SLF4J bridged to JDK 1.4 and SLF4J in my web-app bridged to log4j or
> logback. Don't think that would be possible if the web-app shared the SLF4J
> loaded by the parent classloader.
>   
Right now I have the opposite problem, where I have explicitly allowed 
the slf4j classes to be loaded from the container (have an embedded 
jetty), but the web application includes an older version of slf4j with 
a simple logger so the logs just goes straight to standard out instead 
of the container slf4j implementation.  Sigh.

Would be nice to be able to override.

--

-- 
  THobjrøn

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Wringe | 3 Jun 2008 23:00
Picon
Favicon

Re: [jetty-user] Webapp unavailable after start/stop actions


On Sat, 2008-05-03 at 12:19 +0200, Martin Novak wrote:
> Hello everyone!
>   I have a simple webapp in JettyTest.war placed in /webapps. When I
> start the server, it is properly started. I am starting the server
> with /etc/jetty-jmx.xml to be able to manage it via JMX. When I
> connect to the server mbean via jconsole I see al the webapps, so far
> so good. The problem is that when I select my JettyTest webapp and
> invoke stop() and then start() actions, the webapp is not working
> anymore. I get 404 on its contextPath. According to the webapp MBean,
> it is running, but I am not able to reach it in the browser. Anyone
> knows what is wrong and how can I fix it? Maybe I am missing something
> obvious, please point me in the right direction.

I am having the same problem (except doing this through java code itself
and not mbeans).

If I do something like:

WebAppContext webappcontext = new WebAppContext();
webappcontext.setContextPath(contextPath);
webappcontext.setWar(warURL);

chc.addHandler(webappcontext);
webappcontext.start();
//webappcontext.stop();
//webappcontext.start();

Everything works fine, but if I uncomment the stop and then start then I
can't access the webapp anymore (although it says that it is running).
(Continue reading)

Permalink | Reply | 6 comments |
headers
b_rahul | 4 Jun 2008 06:24

[jetty-user] JSP do not work in Embedded Jetty


Hello -

Encountering a strange issue with Embedded Jetty. I have setup a webapp
context as following:

    System.setProperty("DEBUG", "true");
    Server server = new Server(port);

    WebAppContext webappcontext = new WebAppContext();
    webappcontext.setContextPath("/mywebapp");
    File rd = MyEnv.getRootDir();
    File warPath = new File(rd,"web/app/mywebapp/");
    webappcontext.setWar(warPath.getAbsolutePath());
    HandlerList handlers = new HandlerList();

    handlers.setHandlers(new Handler[]{ webappcontext,new
DefaultHandler()});
    server.setHandler(handlers);
    server.start(); 
    ....

Servlets defined in web/app/mywebapp/WEB-INF/web.xml work just fine. However
any jsp or html files
under WEB-INF are not found when accessed from the browser. For example I
have a hello.jsp under 
web/app/mywebapp/WEB-INF, when invoked via
http://host:port/mywebapp/hello.jsp, the jsp file
is not found by Jetty.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dmitri Livotov | 4 Jun 2008 07:16
Picon

Re: [jetty-user] JSP do not work in Embedded Jetty

Hi,
Why you expect to have html/jsp under WEB-INF ? This should be in the  
webapp root folder, not in web-inf, the last contains only deployment  
descriptor, classes and jar libraries and resources for your app.

Wbr,
Dmitry

На 04.06.2008, в 8:24, b_rahul <me <at> rahulbhargava.org>  
написано:

>
> Hello -
>
> Encountering a strange issue with Embedded Jetty. I have setup a  
> webapp
> context as following:
>
>    System.setProperty("DEBUG", "true");
>    Server server = new Server(port);
>
>    WebAppContext webappcontext = new WebAppContext();
>    webappcontext.setContextPath("/mywebapp");
>    File rd = MyEnv.getRootDir();
>    File warPath = new File(rd,"web/app/mywebapp/");
>    webappcontext.setWar(warPath.getAbsolutePath());
>    HandlerList handlers = new HandlerList();
>
>    handlers.setHandlers(new Handler[]{ webappcontext,new
> DefaultHandler()});
(Continue reading)

Permalink | Reply | 1 comment |

Gmane