Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False alarms about duplicate stylesheet inclusion #27

Open
jkot opened this issue Apr 16, 2012 · 4 comments
Open

False alarms about duplicate stylesheet inclusion #27

jkot opened this issue Apr 16, 2012 · 4 comments

Comments

@jkot
Copy link

jkot commented Apr 16, 2012

Hi,

I'm seeing exceptions about a stylesheet being added to compression twice. I'm sure that I'm including the .css only once. It seems this exception also randomly happens when there really is some other underlying problem such as a missing route or some other exception.

I don't know where to look for the problem. Can you give me a hint? And thanks for the plugin, btw.

Jakub

play.exceptions.JavaExecutionException: Attempt to add the same CSS file to compression twice: 'styleTH.css'
Check that you're not including the same file in two different #{press.stylesheet} tags.
at play.templates.BaseTemplate.throwException(BaseTemplate.java:90)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:257)
at play.templates.GroovyTemplate$ExecutableTemplate.invokeTag(GroovyTemplate.java:379)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:232)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:267)
at play.templates.Template.render(Template.java:26)
at play.templates.GroovyTemplate.render(GroovyTemplate.java:187)
at play.server.PlayHandler.serve404(PlayHandler.java:690)
at play.server.PlayHandler$NettyInvocation.init(PlayHandler.java:197)
at play.Invoker$Invocation.run(Invoker.java:276)
at play.server.PlayHandler$NettyInvocation.run(PlayHandler.java:235)
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: press.DuplicateFileException: Attempt to add the same CSS file to compression twice: 'styleTH.css'
Check that you're not including the same file in two different #{press.stylesheet} tags.
at press.Plugin.checkForDuplicates(Plugin.java:213)
at press.Plugin.checkForCSSDuplicates(Plugin.java:201)
at press.Plugin.addCSS(Plugin.java:111)
at press.Plugin$addCSS.call(Unknown Source)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:232)
... 17 more

@dirkmc
Copy link
Owner

dirkmc commented Apr 16, 2012

Hi Jakub,

If you are receiving this exception when other exceptions are being reported, it could be that there is a stylesheet included by your 500.html template, that is also included by the template for the page where the exception is being thrown.

Unfortunately because of the way play's architecture works it's not recommended to use press for error templates such as 500.html and 404.html, or you may run into these kinds of problems.

Dirk

@jkot
Copy link
Author

jkot commented Apr 16, 2012

Ah, thanks Dirk. This sound likely - I changed the error pages to extend our main template recently. It's been a while since I read the press module documentation..

It still baffles me a bit that this happens only sometimes. By far not with every exception.

If I set press.enabled=true and throw an exception from a controller then the resulting error page still contains uncompressed JavaScript and stylesheets and the duplicate error doesn't show up. Both in DEV and PROD mode. I'm trying to work out a reproducible use case so that I can test my fix.

@jkot
Copy link
Author

jkot commented Apr 16, 2012

It's reproducible by accessing a non-existent route. I think I've fixed the problem now. Thanks for your help!

@dirkmc
Copy link
Owner

dirkmc commented Apr 17, 2012

Yeah it sucks that it's not possible to handle this use case, as I'm sure it's tripped up a few people.
I'm glad you got it working anyway!
Dirk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants