static content in vertx-web

[Klausen Schaefersinho]

Hi,

I just moved to the official release of Vertx3 and now I have an old problem again. When I run Vertx from my IDE to develop some JS files, the static handler somehow returns the old versions of the files, which forces my to restart vertx all the time. I used to fix this behavior in M5 by adding 

-Dvertx.disableFileCaching="disabled"

as an VM parameter.

For some reason this does not work anymore. I debugged into the code, but I could not find the issue. The flag is correctly set in the FileHandler and also I have disbaled caching in the web handler.

Cheers,

Klaus

[Klausen Schaefersinho]

The problem seems to be, that the unpackFromFileURL() method always returns the cached file.

  private synchronized File unpackFromFileURL(URL url, String fileName, ClassLoader cl) {

    File resource;

    try {

      resource = new File(URLDecoder.decode(url.getPath(), "UTF-8"));

    } catch (UnsupportedEncodingException e) {

      throw new VertxException(e);

    }

    boolean isDirectory = resource.isDirectory();

    File cacheFile = new File(cacheDir, fileName);

    if (!isDirectory) {

      cacheFile.getParentFile().mkdirs();

      try {

        Files.copy(resource.toPath(), cacheFile.toPath());

      } catch (FileAlreadyExistsException ignore) {

        // OK - this can happen if this is called multiple times on different threads

      } catch (IOException e) {

        throw new VertxException(e);

      }

    } else {

      cacheFile.mkdirs();

      String[] listing = resource.list();

      for (String file: listing) {

        String subResource = fileName + "/" + file;

        URL url2 = cl.getResource(subResource);

        unpackFromFileURL(url2, subResource, cl);

      }

    }

    return cacheFile;

[Klausen Schaefersinho]

Hi,

it looks like the 

Files.copy(resource.toPath(), cacheFile.toPath(), StandardCopyOption.REPLACE_EXISTING);

was changed in the unpackFromFileURL() and unpackFromJar() changed to

Files.copy(resource.toPath(), cacheFile.toPath());

As a result the cached files are not overwritten anymore and thus the cached file is served. It looks like it was changed in the "Fix concurrency issue with FileResolver" commit.

Also I saw that the setting of the enableChaching Flag was changed to:

private static final boolean ENABLE_CACHING = !Boolean.getBoolean(DISABLE_FILE_CACHING_PROP_NAME);

This will however not read the system property, but parse "vertx.disableFileCaching" to false..

On Monday, July 6, 2015 at 10:24:41 PM UTC+2, Klausen Schaefersinho wrote:

[Ian Andrews]

I'm glad that I wasn't the only one that noticed this.  :-)

[jeo]

Hi all,

On Tuesday, July 7, 2015 at 9:16:31 PM UTC+2, Klausen Schaefersinho wrote:

Also I saw that the setting of the enableChaching Flag was changed to:

private static final boolean ENABLE_CACHING = !Boolean.getBoolean(DISABLE_FILE_CACHING_PROP_NAME);

This will however not read the system property, but parse "vertx.disableFileCaching" to false..

 

Not really:

http://docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html#getBoolean%28java.lang.String%29

Returns true if and only if the system property named by the argument exists and is equal to the string "true". (Beginning with version 1.0.2 of the Java^TM platform, the test of this string is case insensitive.) A system property is accessible through getProperty, a method defined by the System class.  

 

Anyway,

1) With just published 3.1.0

2) Setting VERTX_OPTS="-Dvertx.disableFileCaching=true"

3) (groovy) assert Boolean.getBoolean("vertx.disableFileCaching") == true 

So everything looks right **but** the cache-file still generates.

This effectively forces to restart vertx on every development change.

/jeo

 

[jklingsporn]

Any updates on this? Because I'm still running into this issue.

[Matthew Schrader]

I was banging my head against this for a while as well.  For me it ended up that I was not rebuilding after editing a js file.  When you run the app it gets compiled.  And by doing that the js files are copied to "/target/classes/js/App.js" for example.  That is the file which is on the classpath, which is then copied to .vertx folder unless you disable file caching.

So hopefully this is the same problem you are having and just pushing compile will fix this for you.  Unfortunately, in IntelliJ I do not see an option to auto build on save while the app is running.

[Guy de Pourtalès]

Hi all,

Actually I was also being frustrated by not being able to dynamically update the static assets without restarting the vert.x server. While debugging in IntelliJ, I saw that vert.x behaviour was correct when setting the -Dvertx.disableFileCaching=true. The file was read from the target/classes Maven folder which is correct because this folder is the default classpath for my app running within IntelliJ

In order to have the assets dynamically loaded, I have added the resources folder as Runtime dependency in the IntelliJ module setup within project structure above the Module source. Now I can update any asset in the resources and the changes are immediately available.

Hope it helps. Cheers

Guy