CODEWITHSUNDEEP
javaeclipseapachejettywicket
firat.temel
firat.temel

Reputation: 115

Jetty Server does not start

I have a problem running jetty server. 

>>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
[main] INFO org.apache.wicket.velocity.Initializer - Initialized Velocity successfully
[main] WARN org.apache.wicket.protocol.http.WicketFilter - initialization failed, destroying now
[main] INFO org.apache.wicket.Application - [wicket.project] destroy: Wicket core library initializer
[main] INFO org.apache.wicket.Application - [wicket.project] destroy: DevUtils DebugBar Initializer
[main] INFO org.apache.wicket.Application - [wicket.project] destroy: Wicket extensions initializer
[main] INFO org.apache.wicket.Application - [wicket.project] destroy: Wicket JMX initializer
[main] INFO org.apache.wicket.Application - [wicket.project] destroy: org.apache.wicket.velocity.Initializer@1453a1c7
[main] WARN org.eclipse.jetty.util.component.AbstractLifeCycle - FAILED wicket.project: javax.servlet.ServletException: java.lang.UnsupportedOperationException: path to '/C:/Users/F%c4%b1rat/Desktop/2/src/itudb1323.db': 'C:\Users\F%c4%b1rat' does not exist
javax.servlet.ServletException: java.lang.UnsupportedOperationException: path to '/C:/Users/F%c4%b1rat/Desktop/2/src/itudb1323.db': 'C:\Users\F%c4%b1rat' does not exist
    at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:449)

The problem seems like this C:/Users/F%c4%b1rat/Desktop/2/src/itudb1323.db': 'C:\Users\F%c4%b1rat' does not exist The path should be C:/Users/Fırat/Desktop/2/src/itudb1323.db however it tries to find F%c4%b1rat

Upvotes: 0

Views: 3084

Answers (2)

akyuzg
akyuzg

Reputation: 26

You can try to put your workspace into a directory which does not contain Windows-1254 character set (Example: Under C:/). This is a temporary solution but it can fix your problem.

Upvotes: 1

Joakim Erdfelt
Joakim Erdfelt

Reputation: 49462

The ı is interpreted by Java as ...

U+0131 LATIN SMALL LETTER DOTLESS I character (ı)

Which is UTF-8 translated from the Windows-1252 codepage as Hex 0xC4 0xB1, hence the F%c4%b1rat part of the path. Which is required to be URL encoded for the URLClassLoader.

Sounds like you have hit a JVM bug with unicode and/or windows codepage support in the URLClassloader. Would encourage you to not deploy on these kinds of paths, or upgrade your JVM to see if this is better supported with a later JVM.

Upvotes: 3

Related Questions