[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Avoiding file-locking when developing with embedded Jetty
|
Hi Johannes,
On 5 January 2015 at 09:40, Johannes Brodwall <johannes@xxxxxxxxxxxx> wrote:
> Hi Jan
>
> What I am trying to achieve is to easily start building new applications
> with embedded Jetty without having to use external programs (like
> jetty-runner), XML files (like context XML) or frameworks (like DropWizard).
Sheesh, we already give you so many ways to start jetty, and its still
not enough :) :) :)
> I can copy and paste this main class, but I would rather avoid the magic
> parts so it doesn't require special knowledge (especially the trick with
> setting the init parameter).
The main class is really teensy weensy - you're configuring and
initiating an entire servlet container in just a couple of lines :)
The only "magic" part I can see is the init param to turn off
fileMappedBuffers - and that is only necessary iff you're running on a
windows platform && likely to be replacing the contents of the file.
If you're not going to replace the contents of the file then you can
leave that set to to true.
BTW, useFileMappedBuffers is set to false by default in the
DefaultServlet. We use the webdefault.xml file which defines the
DefaultServlet to set it to true. So your other approaches would be:
* use your own webdefault.xml file (but you don't like using xml files)
* redefine the DefaultServlet in your own web.xml or web-override.xml
with the param set to false (but again, you don't like to use xml
files)
Really, I think the best solution is to use a system property on the
command line for when you're running in dev mode (useFileMappedBuffers
false) vs running in prod mode (maybe useFileMappedBuffers true?).
>
> I am indeed running on Windows (is that the only platform that supports
> fileMappedBuffers)?
Only parameter that DOESN"T support fileMappedBuffers properly.
> Setting the init-parameter like this actually does work
> (I use it every day) and requires less code than what's needed to have a
> custom context XML. But like I said: It's undocumented and a bit magic.
Well, to be fair, its not *entirely* undocumented:
http://www.eclipse.org/jetty/documentation/current/troubleshooting-locked-files-on-windows.html
> I am still trying to figure out what change I would like to see in Jetty for
> this.
Me too ;)
> I agree that in this case, the src/main/resources/webapp path is specific to
> the way this application is packaged and something that makes sense to
> configure.
>
> I guess that ideally for me would be if the default value of
> fileMappedBuffers would depend on whether the value in setWar is a directory
> or a JAR file. Does this distinction make sense to you?
Not exactly. As I said above, the value of useFileMappedBuffers
depends on whether the same file is likely to change when running on
windows. If it changes, then you have to set useFileMappedBuffers
false. Eg, if you're editing the files in dev mode, then files will
change . If you're redeploying an unpacked webapp then the same file
will change.
You can also look at the other solutions listed on that
troubleshooting page, which mostly involves copying parts of the weapp
to a tmp dir so that it is never the same file that will change (not
such a great option when running in dev mode and you want to see the
changes in your file reflected).
cheers
Jan
>
>
> ~Johannes
>
>
> On Fri, Jan 2, 2015 at 6:04 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
>>
>> Hi Johannes,
>>
>> Have you considered using the jetty-runner? Here's the doc:
>>
>> http://www.eclipse.org/jetty/documentation/current/runner.html#jetty-runner
>>
>> You could point it at your src/main/resources/webapp dir as the webapp
>> to deploy. However, as it seems you're running on windows, you'll need
>> to use a context xml file instead to set the context param to turn off
>> fileMappedBuffers, and to point to your webapp and context path.
>>
>> OTOH, your main is a pretty simple class ... it could be made more
>> generic by using system properties to set the context path, webapp to
>> deploy and the fileMappedBuffers property.
>>
>> cheers
>> Jan
>>
>> On 2 January 2015 at 16:15, Johannes Brodwall <johannes@xxxxxxxxxxxx>
>> wrote:
>> > Hi
>> >
>> > I would like to hear if someone could suggest how to scratch this itch I
>> > often have when using Jetty embedded in applications.
>> >
>> > I am often using Jetty during development. I'd like for static files
>> > that
>> > are normally packaged into a war or jar file to be easy to edit when I
>> > am
>> > developing (that is, when the files are not packaged). At the same time,
>> > I
>> > want my code to be as similar as possible during development and in
>> > production.
>> >
>> > My best attempt so far has been to place the static content under
>> > src/main/resources/webapp and package it into the Jar-file.
>> >
>> > In order to avoid locking the files when I'm running the server in the
>> > debugger, I've implemented the following:
>> >
>> > public static WebAppContext createApplicationContext() {
>> > WebAppContext webapp = new WebAppContext("/webapp", "/app");
>> >
>> > if
>> >
>> > (SimpleServer.class.getResource(webapp.getWar()).getProtocol().equals("file"))
>> > {
>> > // Avoid locking static content when running exploded
>> > webapp.setWar("src/main/resources/webapp");
>> >
>> >
>> > webapp.setInitParameter("org.eclipse.jetty.servlet.Default.useFileMappedBuffer",
>> > "false");
>> > }
>> > return webapp;
>> > }
>> >
>> > This runs in a main method like so:
>> >
>> > public class SimpleServer {
>> >
>> > public static void main(String[] args) throws Exception {
>> > HandlerList handlers = new HandlerList();
>> > handlers.addHandler(new ShutdownHandler("randomtoken", false,
>> > true));
>> > handlers.addHandler(createApplicationContext());
>> >
>> > Server server = new Server(5000);
>> > server.setHandler(handlers);
>> > server.start();
>> >
>> > System.out.println("Started " + server.getURI());
>> > }
>> > }
>> >
>> > As the rest of the code is extremely simple, the magic replacement of
>> > the
>> > target file with the source file and the setting of the very poorly
>> > documented "org.eclipse.jetty.servlet.Default.useFileMappedBuffer"
>> > parameter
>> > both feel really frustrating. The code is magic enough that I've ended
>> > up
>> > creating a "framework" to run it which is clearly not what I want.
>> >
>> >
>> > 1. Are there currently better ways of doing this?
>> > 2. Is there any way something that accomplishes the same could be added
>> > to
>> > Jetty itself?
>> >
>> >
>> > ~Johannes
>> >
>> >
>> >
>> > _______________________________________________
>> > jetty-users mailing list
>> > jetty-users@xxxxxxxxxxx
>> > To change your delivery options, retrieve your password, or unsubscribe
>> > from
>> > this list, visit
>> > https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>>
>> --
>> Jan Bartel <janb@xxxxxxxxxxx>
>> www.webtide.com
>> 'Expert Jetty/CometD developer,production,operations advice'
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
--
Jan Bartel <janb@xxxxxxxxxxx>
www.webtide.com
'Expert Jetty/CometD developer,production,operations advice'
