Re: Jetty context parameters

Mika,

You've got a couple of options with Jetty (other than the standard
web.xml route which Evgeny already mentioned).

Option 1: Use a jetty-web.xml file to define the init params. This is
a file that you put in your WEB-INF directory which contains configuration
for the webapp that Jetty will apply to the webapp AFTER it has applied
web.xml. The syntax and general information on jetty-web.xml is here:
http://docs.codehaus.org/display/JETTY/jetty-web.xml

Here's an example of setting up jetty-web.xml with some context init
params:
<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="initParams">
    <New class="java.util.HashMap">
      <Put name="aaa">123</Put>
    </New>
  </Set>
</Configure>

Option 2: Set up your webapp using the ContextDeployer, which uses a
context.xml file to define the webapp. It's contents is exactly the
same as the jetty-web.xml file, but it doesn't go inside your
webapp. The information on that is here: http://docs.codehaus.org/display/JETTY/ContextDeployer

Good luck
Jan

Re: Is it possible to exclude commons-el as a dependency with the maven-jetty-plugin?

Matt,

I've just discovered some cruft in the jetty maven plugin pom that
included an unneeded dependency on commons-el! I've removed that
and tested the plugin and it seems to be working ok.

However, it would be ideal if you could do acheckout of jetty 
svn head and a build and see if it is working with your 
application now commons-el is out of the picture completely?

thanks
Jan

mraible wrote:
> I'm using JDK 5 on OS X. For Tomcat, I tested it on version 6.0.14.
> 
> Matt
> 
> 
> janb wrote:
>> Matt,
>>
>> You must be using jdk1.4 because for jdk1.5 and up, jasper does not
>> require commons-el.
>>
>> If in fact you are using jdk1.4 and therefore jsp-2.0, then you are
>> actually using 
>> jasper 5.5.15 from apache. I don't know whether those versions of myfaces
>> etc are
>> supposed to work with jsp2.0, but if they are, then you might try and

Re: Jetty and mod_proxy

I believe that there is some jetty configuration required when using
mod_proxy - jetty needs to be configured so that it knows what port httpd is
using - this way when the java webapp does a redirect it won't redirect to
8080.

I know how to do this using Tomcat, it is described here:
http://tomcat.apache.org/tomcat-5.5-doc/proxy-howto.html

I can't find any information about how to tell jetty what the proxy port is
though, so at the moment (with only httpd configured with mod_proxy), the
login redirect screws everything up because it redirects to port 8080
instead of 80.

Greg Wilkins wrote:
> 
> 
> Eric,
> 
> for mod_proxy, the best resource is really the apache pages themselves
> as you don't need any special configuration on jetty.
> 
> for mod_ajp we have some pages on the jetty wiki for jetty 6 that
> are recent
> 
> I think mod_jk2 is deprecated and you can just use mod_jk
> or mod_proxy_ajp (which I prefer)
> 
> The ajp in jetty 6.1 is to be considered beta quality.
> 

Re: Is it possible to exclude commons-el as a dependency with the maven-jetty-plugin?

I checked out from SVN, ran "mvn" from the root directory and then removed
<version>6.1.5</version> from my project. I assume this is what I need to do
in order to get the latest plugin that I installed locally. 

Unfortunately, no dice - the error still occurs.

Caused by: javax.el.PropertyNotFoundException: ELResolver cannot handle a
null base Object with identifier 'errors'
        at com.sun.el.lang.ELSupport.throwUnhandled(ELSupport.java:63)
        at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:88)
        at
com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
        at
org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:67)

Running mvn jetty:run-war -X > mvn.log and it seems that commons-el is still
a dependency of the plugin:

[DEBUG] Adding managed depedendencies for
org.mortbay.jetty:maven-jetty-plugin[DEBUG]  
org.apache.maven:maven-plugin-tools-api:jar:2.0
[DEBUG]   junit:junit:jar:3.8.2[DEBUG]  
org.slf4j:jcl104-over-slf4j:jar:1.3.1
[DEBUG]   org.slf4j:slf4j-simple:jar:1.3.1
[DEBUG]   mx4j:mx4j:jar:3.0.1[DEBUG]   mx4j:mx4j-tools:jar:3.0.1
[DEBUG]   xerces:xercesImpl:jar:${xerces-version}[DEBUG]  
commons-el:commons-el:jar:1.0
[DEBUG]   ant:ant:jar:1.6.5 
[DEBUG]   javax.mail:mail:jar:1.4[DEBUG]  

Re: Is it possible to exclude commons-el as a dependency with the maven-jetty-plugin?

Matt,

Hmmm, well that's definitely not right because the commons-el and ant jars no
longer appear when I run mvn -X jetty:run. Everything is checked in at this
end.

Could you try again, but use <version>6.1-SNAPSHOT</version> as the version
number of the jetty plugin? No idea if that really makes any difference, but 
it will definitely nail the version to the one you've built locally.

cheers
Jan

mraible wrote:
> I checked out from SVN, ran "mvn" from the root directory and then removed
> <version>6.1.5</version> from my project. I assume this is what I need to do
> in order to get the latest plugin that I installed locally. 
> 
> Unfortunately, no dice - the error still occurs.
> 
> Caused by: javax.el.PropertyNotFoundException: ELResolver cannot handle a
> null base Object with identifier 'errors'
>         at com.sun.el.lang.ELSupport.throwUnhandled(ELSupport.java:63)
>         at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:88)
>         at
> com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
>         at
> org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:67)
> 
> Running mvn jetty:run-war -X > mvn.log and it seems that commons-el is still

Re: Is it possible to exclude commons-el as a dependency with the maven-jetty-plugin?

I tried that and I still get the same error. Is it possible that anonymous
svn is time delayed? If you do "mvn jetty:run -X | tee mvn.log" and look at
mvn.log - you have no references to commons-el?

I don't know if having commons-el in my classpath is the cause of the
problem, but that's what the MyFaces mailing list seems to indicate. 

Matt

janb wrote:
> 
> Matt,
> 
> Hmmm, well that's definitely not right because the commons-el and ant jars
> no
> longer appear when I run mvn -X jetty:run. Everything is checked in at
> this
> end.
> 
> Could you try again, but use <version>6.1-SNAPSHOT</version> as the
> version
> number of the jetty plugin? No idea if that really makes any difference,
> but 
> it will definitely nail the version to the one you've built locally.
> 
> cheers
> Jan
> 
> mraible wrote:

Improving Ajax performance and usability by using request based priority

Hi Greg, Jan and the others.

Few weeks ago I noticed an interesting article on JFA blog (grizzly guy)
about using multiple request queues:
http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.h
tml

I think it's a good idea and it can help a lot of scenario, for example,
in my webapp, I have regular http requests, ajax requests and hessian
requests, it would be very nice to be able to treat them a part so one
does not become a bottleneck of others and this way, you can provide
some kind of QoS between your services (http / ajax / hessian). But
anyway Jean Francois explains this better than me ;)

What do you think ? Is it something that could be included in the Jetty
roadmap ?

Cheers
Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jetty-support mailing list
Jetty-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jetty-support

Eclipse Jetty Server Adaptor

It's nice. But -

It would be better if my website wasn't packaged as a WAR, because right now,
it is, and every time I save changes to a file the WAR has to be recreated...
and before I hacked the build.xml that ships with the Eclipse Jetty runtime,
I had to manually restart after republishing.

Tomcat's Eclipse runtime uses the files in my Eclipse project directory. The
only thing it has to do on a republish is ensure that all of the libraries
listed as J2EE dependencies are copied to WEB-INF\lib.

--

-- 
Steve Sobol, Victorville, California     PGP:0xE3AE35ED

"Drench yourself in words unspoken / Live your life with arms wide open
Today is where your book begins / The rest is still unwritten"
     - Natasha Beddingfield

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jetty-support mailing list
Jetty-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jetty-support

Re: Eclipse Jetty Server Adaptor

Hi Steve,

Yes, the adaptor does package it as a war. I followed the example
for the other (generic) type of web server adaptors. It is possible
I guess to not to package as a war, which we could consider as an 
enhancement for the next release.

I'm not sure what you mean by having to hack the build.xml in order
to restart jetty - you should not have to restart jetty at all as
the build.xml file explicitly creates you a context.xml file in order
to be able to hot (re)deploy your webapp. ?

It may be possible to adopt a similar approach to the Tomcat adaptor,
however that has been written making extensive use of the Eclipse APIs,
rather than using the generic adaptor skeleton provided. Writing an
adaptor to the APIs is a much bigger task, and something that we
consider we might do once we get more experience and feedback on
how the generic one is functioning. So, thanks for the feedback!

cheers
Jan

Steve Sobol wrote:
> It's nice. But -
> 
> It would be better if my website wasn't packaged as a WAR, because right now,
> it is, and every time I save changes to a file the WAR has to be recreated...
> and before I hacked the build.xml that ships with the Eclipse Jetty runtime,
> I had to manually restart after republishing.
> 

US $ 59.95 50mg x 10 pills

Columbuses or Gamas, ever pass,
Winds blow sharp, what then?My keyhole blows a gale
Palladio who beckons from the other shore,will be penciled on the coffeeshop menus.
Beneath a pile of corpses, lying massedFor any part of them we can make out
At San Biagio, in the most intense roomAgainst this sky no longer of our world.
Green lilac buds appear that won't surviveThe bees are buzzing,
To reach out into its own vanishingBeneath a pile of corpses, lying massed
But what I am looking at is hardened snow,Away, my songs, must we go
Pierced by the mist that fades away,A matter of getting all that right . . 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Jetty-support mailing list
Jetty-support <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jetty-support