LessException recompiling a resource that has changed #16

Closed
longwa opened this Issue Apr 13, 2012 · 13 comments

Projects

None yet

10 participants

@longwa
longwa commented Apr 13, 2012

In 1.3.0, if you change a .less resource while the server is running in development mode, you get:

org.lesscss.LessException: java.lang.RuntimeException: No Context associated with current Thread
at org.lesscss.LessCompiler.compile(LessCompiler.java:255)
at org.lesscss.LessCompiler.compile(LessCompiler.java:302)
at org.lesscss.LessCompiler.compile(LessCompiler.java:326)
at org.lesscss.LessCompiler.compile(LessCompiler.java:292)
at org.lesscss.LessCompiler.compile(LessCompiler.java:279)
at LesscssResourceMapper.map(LesscssResourceMapper.groovy:31)
at org.grails.plugin.resource.mapper.ResourceMapper.invoke(ResourceMapper.groovy:139)
at org.grails.plugin.resource.mapper.ResourceMapper.invokeIfNotExcluded(ResourceMapper.groovy:128)
at org.grails.plugin.resource.ResourceProcessor.applyMappers(ResourceProcessor.groovy:587)
at org.grails.plugin.resource.ResourceProcessor.prepareResource(ResourceProcessor.groovy:533)
at org.grails.plugin.resource.ResourceProcessor$_prepareSingleDeclaredResource_closure12.doCall(ResourceProcessor.groovy:602)
at org.grails.plugin.resource.util.ResourceMetaStore.addDeclaredResource(ResourceMetaStore.groovy:29)
at org.grails.plugin.resource.ResourceProcessor.prepareSingleDeclaredResource(ResourceProcessor.groovy:600)
at org.grails.plugin.resource.ResourceProcessor$_prepareResourceBatch_closure14.doCall(ResourceProcessor.groovy:625)
at org.grails.plugin.resource.ResourceProcessorBatch.each(ResourceProcessorBatch.groovy:8)
at org.grails.plugin.resource.ResourceProcessor.prepareResourceBatch(ResourceProcessor.groovy:621)
at org.grails.plugin.resource.ResourceProcessor.resourcesChanged(ResourceProcessor.groovy:804)
at org.grails.plugin.resource.ResourceProcessor.loadResources(ResourceProcessor.groovy:839)
at org.grails.plugin.resource.ResourceProcessor.reloadChangedFiles(ResourceProcessor.groovy:1037)
at ResourcesGrailsPlugin$_closure4_closure20.doCall(ResourcesGrailsPlugin.groovy:212)
at ResourcesGrailsPlugin$_triggerReload_closure7.doCall(ResourcesGrailsPlugin.groovy:199)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: No Context associated with current Thread
at org.mozilla.javascript.Context.getContext(Context.java:2355)
at org.mozilla.javascript.InterpretedFunction.(InterpretedFunction.java:62)
at org.mozilla.javascript.InterpretedFunction.createScript(InterpretedFunction.java:92)
at org.mozilla.javascript.Interpreter.createScriptObject(Interpreter.java:243)
at org.mozilla.javascript.Context.compileImpl(Context.java:2447)
at org.mozilla.javascript.Context.compileString(Context.java:1367)
at org.mozilla.javascript.Context.compileString(Context.java:1356)
at org.mozilla.javascript.Context.evaluateString(Context.java:1108)
at org.lesscss.LessCompiler.compile(LessCompiler.java:238)

@longwa
longwa commented Apr 13, 2012

I should say, this is using Grails 2.0.3 on Windows 7, 64-bit.

@msgilligan

I'm seeing the same thing on Mac OS 10.6.8, Grails 2.0.3, Java 1.6.0_31.

@msgilligan

The 1.3.0.1 code in the tip of master seemed to fix the problem for me.

@halfbaked

I'm seeing the same on Mac Lion

@elm4ward
elm4ward commented May 7, 2012

Same here - osx 10.7.3 / resources plugin 1.3.0.

@aurelienmaury

Could you please make a plugin release with this fix ? We're really interested in this 1.3.0.1.

@nvinet
nvinet commented May 10, 2012

Please release as having the fix on a local version of the plugin is quite annoying especially at the CI level.

@elm4ward

Version 1.3.0.3 is running perfectly again.

You can close this issue - thank you paul!

@halfbaked

whoot!

@anti43
anti43 commented Sep 6, 2012

No, its not. having the same Exception while calling new LessCompiler().compile(css) in a grails service during runtime :_/ what can I do to get around this?

@MaximumDamage

Well this issue is still not fixed. I face the same issue with grails 1.3.7 and resources 1.1.6 and all lesscss version. I tried a few different resources plugins, but could not find a fix. What versions do work together ?

@cweekly
cweekly commented Nov 16, 2012

FWIW, if you're frustrated or blocked w/ grails plugin issues relating to LESS, you might want to try an alternate approach of compiling less->css offline, and deploying the generated .css in your grails apps. This sidesteps issues like resources plugins not being able to find .less files provided by binary plugins, or lessc not being triggered in debug mode, etc, and also reduces your production server's footprint and workload. I think the use cases for actually needing the server to do lessc for you (vs serving up generated .css asset bundles) are few and far between.

If you go this "offline lessc" route, LiveReload.app is great for OSX devs. For Windows, SimpLESS seems decent. If you want a command-line tool that supports centrally-managed configuration and works across OSX and Windows, I wrote a node module called "lesswatcher" for exactly this purpose: https://npmjs.org/package/lesswatcher
It's a simple little tool, and strictly beta, but we've been using it for a while at Care.com and it gets the job done.

@paulfairless
Owner

1.3.1 includes some multi-threading fixes in the compiler. Hopefully this has finally addressed this issue.

I would say, after getting to know the resources platform better, offilne compilation of .less files is going to perform much better and be more stable. This was the exact mechanism used in the grails re-write, there was a blog post but I can't seem to find it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment