All,
We upgraded the version of jsp that we use with jetty-7.5.2 to be
jsp-impl-2.1.3.b10 (from glassfish).
With this release, if you are using 1.6, it will always try and get the java
compiler from the jvm.
Only if you have a jvm < 1.6 will it fall back to the ecj compiler. We are
waiting on the
Make sure you have tools.jar on your classpath.
Pavel
On Wed, Oct 12, 2011 at 9:59 AM, Leonard Smith wrote:
> I put a JDK into place, set JAVA HOME though and I am still seeing
> this error. I put JAVA_HOME into /etc/default/jetty.
>
>
>
> On Wed, Oct 12, 2011 at 11:57 AM, Joakim Erdfelt
> wr
Same baahviour detected here (nojdk error when trying to use JSPs):
win7 x32
JDK 1.7
jetty 7.5.x
though the same server setup works fine on jetty 7.4.x
On Wed, Oct 12, 2011 at 19:59, Evan Ruff wrote:
> Joakmin and Leonard,
>
> I reported a similar issue using Jetty 7.5.1 on Windows. The list men
Joakim, thank you kindly for this.
I will let you know how i get on.
Joakim Erdfelt wrote:
The ./lib/ext folder is also too late in the process to include the
custom java.util.logging handlers.
You have a choice at this point.
1) Do not use LogManager.readConfiguration() but rather use the
To all,
I'm running Jetty 7.5.3, with Solr 1.4, and I have JAAS setup for
ldap-auth. I have it working, but our solr install has multiple cores
so solr talks to itself, on the loop back, but doesn't authenticate.
I'm trying to find some way to disable JAAS for connections on the
loop-back interfac
Hi Thomas--
Thanks for having a look. I guess that somewhere in between V6 and V7
that the UTF8 became more strict? Anyhow, now that I know its invalid,
I see that its a client-side bug and think it may be related to using
escape() instead of encodeURIComponent(). Thanks for your help.
Well I got it to work. 'bin/jetty.sh check' showed that it was picking
up the JRE java binary and not the JDK one. I overrode that and its
running now. What I need to go back and check is that this was running
under Jetty 7.2.2 without the JDK, just the JRE.
Len
On Wed, Oct 12, 2011 at 11:59 AM,
Joakmin and Leonard,
I reported a similar issue using Jetty 7.5.1 on Windows. The list mentioned
that 7.5.2 cleaned up the error, but I haven't gotten a chance to test.
Are you on Windows?
E
On Wed, Oct 12, 2011 at 11:57 AM, Joakim Erdfelt wrote:
> The line ...
> "
> org.apache.jasper.JspCom
I put a JDK into place, set JAVA HOME though and I am still seeing
this error. I put JAVA_HOME into /etc/default/jetty.
On Wed, Oct 12, 2011 at 11:57 AM, Joakim Erdfelt wrote:
> The line ...
> " org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608)
> "
> tells me you h
The line ...
"
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608)
"
tells me you have JSP files.
You are required to use a JDK when you have JSP, a JRE is not sufficient to
work with JSP files.
You will have to configure your environment to have JAVA_HOME point to the
To all,
I am trying to run solr 1.4 on Jetty 7.5.3. I had it working on 7.5.1.
This is on
Centos 5.6
JRE 1.6.0-24
Solr 1.4
Jetty 7.5.3
When I access /solr I get the error below. I've google and I've tried
installing the JDK, but it doesn't work and I'd like to not have the
JDK on anyway.
Thank
Hi,
Thanks for that. The reason I included the foreign library was that it
seemed to simple on the client side to matter. If I recall correctly (not at
the right computer now) it simply writes the frame delimiters and the data
to a buffered output stream and then flushes which seemed simple enough
We are pleased to announce the immediate availability of Jetty
7.5.3.v20111011 and Jetty 8.0.3.v20111011.
All artifacts are present in maven central and are also available from
the normal download locations at eclipse and codehaus.
- http://download.eclipse.org/jetty
- http://dist.codehaus.org/je
Hi,
On Wed, Oct 12, 2011 at 14:24, Thomas Becker wrote:
> Hi Lars,
>
> thanks for providing the test case. However we've some loadtests as well and
> they have a similar setup without using a foreign client library like your
> test and they all work fine. For instance "WebSocketLoadD13Test.java"
Hi Lars,
thanks for providing the test case. However we've some loadtests as well
and they have a similar setup without using a foreign client library
like your test and they all work fine. For instance
"WebSocketLoadD13Test.java" in jetty8.
If you can provide a test without using a foreign
Hi Eric,
sorry, I've been confused because I've not taken care of what you try to
encode there. %e7 is not valid utf8 bytes and that's why it doesn't
work. In utf8 the c with a cedilla is represented by two bytes c3 and
a7. The proper uri would look like:
URL: /?i=e%c3%a7
And that can be su
16 matches
Mail list logo