[1.3] [gae 1.6.0] Can't start on GAE : There was a problem parsing .modulesOrder.conf

[Carl]

Hi,

I played with the upcoming play 1.3 from github and started a new project to be
deployed on GAE (using SDK 1.7.3 and 1.8.5)

So, I build play 1.3, create a new project with "play new" updated the dependencies
to include gae, and add the deployment manifest in war/WEB-INF.

You know the usual (as far as I remember).

The app runs fine locally but fails to start on GAE.

Here's the stacktrace :


    2013-08-23 17:50:06.905 / 500 3101ms 0kb Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0

    78.226.13.195 - - [23/Aug/2013:08:50:06 -0700] "GET / HTTP/1.1" 500 0 - "Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0" "rainstudiosmeleo.appspot.com" ms=3102 cpu_ms=1906 loading_request=1 app_engine_release=1.8.3 instance=00c61b117c82d89dc8601733795e24f327d222

    I 2013-08-23 17:50:06.057

    play.Logger info: Play! is running in Google App Engine

    I 2013-08-23 17:50:06.886

    play.Logger info: Starting /base/data/home/apps/s~rainstudiosmeleo/1.369708891446981075/WEB-INF/application

    W 2013-08-23 17:50:06.886

    play.Logger warn: No tmp folder will be used (cannot create the tmp dir)

    W 2013-08-23 17:50:06.899

    Failed startup of context com.google.apphosting.utils.jetty.RuntimeAppEngineWebAppContext@a32d61{/,/base/data/home/apps/s~rainstudiosmeleo/1.369708891446981075}
    play.exceptions.UnexpectedException: There was a problem parsing .modulesOrder.conf
        at play.Play.loadModules(Play.java:725)
        at play.Play.init(Play.java:280)
        at play.server.ServletWrapper.contextInitialized(ServletWrapper.java:78)
        at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
        at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:219)
        at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:194)
        at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
        at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:439)
        at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:435)
        at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:442)
        at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:186)
        at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:306)
        at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:298)
        at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:439)
        at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
        at java.lang.Thread.run(Thread.java:722)

    C 2013-08-23 17:50:06.902

    Uncaught exception from servlet
    javax.servlet.UnavailableException: Initialization failed.
        at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:228)
        at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:194)
        at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
        at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:439)
        at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:435)
        at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:442)
        at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:186)
        at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:306)
        at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:298)
        at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:439)
        at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
        at java.lang.Thread.run(Thread.java:722)

    I 2013-08-23 17:50:06.904

    This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.


It goes without saying that everything is fine with play 1.2.5

Any idea what's wrong ?

[Carl]

In the war generated by the gae module, the file ".modulesOrder.conf"  is missing from the  "WEB-INF/application/modules" folder

It seems that the GAE module must be updated to include that new important file.

Does it means that other deployment oriented play modules must be updated to support play 1.3 ?

[Carl]

Here a more complete stacktrace : 

Failed startup of context com.google.apphosting.utils.jetty.RuntimeAppEngineWebAppContext@1e5980f{/,/base/data/home/apps/s~rainstudiosmeleo/1.369710638163640404}
play.exceptions.UnexpectedException: There was a problem parsing .modulesOrder.conf
	at play.Play.loadModules(Play.java:726)
	at play.Play.init(Play.java:280)
	at play.server.ServletWrapper.contextInitialized(ServletWrapper.java:78)
	at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
	at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
	at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
	at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
	at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
	at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
	at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:219)
	at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:194)
	at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134)
	at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:439)
	at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:435)
	at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:442)
	at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:186)
	at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:306)
	at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:298)
	at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:439)
	at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.FileNotFoundException: /base/data/home/apps/s~rainstudiosmeleo/1.369710638163640404/WEB-INF/application/modules/.modulesOrder.conf (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:140)
	at play.deps.DependenciesManager.retrieveModules(DependenciesManager.java:170)
	at play.Play.loadModules(Play.java:723)
	... 20 more

[Carl]

Ok, I know what went wrong.

GAE does not deploy file starting with '.'.
So, as far as GAE is concerned '.modulesOrder.conf' is poor choice if the file must be deployed.

I manage to come up with a ugly work around.
The gae:deploy task rename .modulesOrder.conf to modulesOrder.conf and
the code in the DependenciesManager look for modulesOrder.conf if .modulesOrder.conf
cannot be found.

It sounds like a big bad hack.
But for the time being, it fixes the issue.

Should I open a ticket ? And if so, where exactly ?
Play 1.3 lighthouse ? Gae plugin ?

Have a nice week end,
Carl.

[notalifeform]

Hi Carl,

I think that the starting dot was chosen because it would be clear it is not a module definition itself. On the other hand the .conf should say enough.

You can open a ticket at lighthouse.

Adding  a pull request renaming the file (remove the leading dot) would be great.

cheers,

Robert

[Carl]

I tried to rename the file (in the code) but it had some weird side effects.
If I understand correctly, play tooling expect that all the regular files in the modules folder to be shortcuts.

Or at least, that's how the GAE module works. Being written by Guillaume Bort, I expect to be standard behavior.
I wonder if renaming the file to a regular name will not create more side effects for others modules.
Is it possible to rename the file and move it to another location ?

[notalifeform]

I would personally not object to move it to the 'conf' folder - even though it would be the only generated file in that folder.

Anybody else has a strong opinion on this?

regards.

Robert

[Carl]

On Friday, August 23, 2013 10:25:29 PM UTC+2, notalifeform wrote:

I would personally not object to move it to the 'conf' folder - even though it would be the only generated file in that folder.

Anybody else has a strong opinion on this?

Well, it sounds strange to have generated file in conf. Especially a file that is a by product of other conf files.

Why not generating the file in the classes folder ?

[notalifeform]

In that case  'play clean' (which removes the 'tmp' folder ) would remove this file too; isn't? Not sure if that's desired behaviour.

regards,

Robert

[Tom Carchrae]

On 13-08-23 01:59 PM, Carl wrote:
>
> Well, it sounds strange to have generated file in conf. Especially a
> file that is a by product of other conf files.
>
> Why not generating the file in the classes folder ?

+1 on this idea.

also, Carl, I don't use GAE + Play anymore, but I used to quite a bit.
When I deployed I would always make play produce a WAR output, run a
script to fix the WAR directory, then use the command line too to deploy
to GAE. That sounds bad, but I found I could remove many of the JAR
files from the Play WEB-INF/lib folder - in part because it sped up
deployment (and I think it may impact spin-up time), but also because I
was hitting a space limit on GAE - and many JARs were not used.

Tom

[Carl]

On Saturday, August 24, 2013 1:05:24 AM UTC+2, Tom Carchrae wrote:

 That sounds bad, but I found I could remove many of the JAR
files from the Play WEB-INF/lib folder

Here's the output of gae:deploy

Beginning interaction for module default...
0% Created staging directory at: 'C:\Users\Evasion\AppData\Local\Temp\appcfg3088812028997055447.tmp'
5% Scanning for jsp files.
20% Scanning files on local disk.
25% Initiating update.
28% Cloning 164 application files.
40% Uploading 32 files.
52% Uploaded 8 files.
61% Uploaded 16 files.
68% Uploaded 24 files.
73% Uploaded 32 files.
77% Sending batch containing 32 file(s) totaling 718KB.
90% Deploying new version.
95% Closing update: new version is ready to start serving.
98% Uploading index definitions.

I was under the impression that the gae deployment
already does some clean up.
718KB seems like a valid size for an empty app.

Do you think that gae:deploy sends also the 67 libs located in
WEB-INF/libs ? (totaling 73 Mo).
Knowing my internet connexion, I would have noticed if such large
amount of jars would be uploaded to google's servers...

[notalifeform]

In that case  'play clean' (which removes the 'tmp' folder ) would remove this file too; isn't? Not sure if that's desired behaviour.

regards,

Robert

On Friday, August 23, 2013 10:59:03 PM UTC+2, Carl wrote:

[notalifeform]

Hi,

Since 'play clean' would remove this file, I think it's not a good location - Any thoughts on this?

I would like 1.3 to be compatible with he GAE plugin...

regards,

Robert

[Carl]

On Tuesday, September 3, 2013 8:46:41 AM UTC+2, notalifeform wrote:

Hi,

Hello,

here are my two cents

Since 'play clean' would remove this file, I think it's not a good location - Any thoughts on this?

What is the problem here ?

Could you describe the lifecycle of  .modulesOrder.conf

What does it do ?
What generates it ? play deps ?
Is the developer supposed to update that file ?

Can a play 1.3 application work without it ?

Here's my reasoning.

If the file is necessary for the application to work and is not
a by product of compilation, it shouldn't be hidden (ie its name
shouldn't start with .)

It is confusing for the developer and may be so for other tools
and/or version control systems. This was the issue with the
GAE module : hidden files are not deployed.

So, my advice would be to to rename (A) it to modulesOrder.conf and
find a location for it that :
  - makes sense
  - doesn't have any side effect for existing tooling and modules

If (A) is accepted, then the gae module proved that application/modules/ is not a good place
as files in that folder are expected to be shortcuts and not description for module order.
I don't know if there are other module that uses the shortcut mechanism
but it seems likely.

If the modulesOrder.conf is supposed to be edited by the developer (which I doubt somehow), then
the conf/ seems appropriate (B).

If the modulesOrder.conf is not supposed to be edited or a conf file why not treating it like the
message file or other templates/resources (C): they are certainly packaged by all the
modules.
 
If the modulesOrder.conf is not generated in the compilation process then
I reckon that application/classes (D) is not suitable. And putting the file
along with .java files so it will copied to application/classes feels not right.

So according to me, the questions are :
   - does (A) make sense for you ?
   - do you confirm that (D) is bad ?
   - is there any other scenario other than (B) and (C) ?

And then makes the final choice, do some testing (and maybe release a beta
for 1.3).

By the way, I think that this discussion should have its own thread.

It will give some visibility on the development process of the much awaited
play 1.3. And also gather more feedback from concerned developers than some
obscure gae bug report.

Cheers,
Carl.

I would like 1.3 to be compatible with he GAE plugin...

I think that minimizing the changes is a great move.

But I would like to add a sidenote.

The gae module doesn't look supported and spawned a fork that seems
current with he evolutions of GAE SDK : https://github.com/Q42/play-gae
(The project is missing a clear changelog, though)

Using the Q42 fork is explained here : http://q42.github.io/play-gae/
 

regards,

Robert

[notalifeform]

Hi Carl,

Thanks for your extensive response - see my comments inline.

Could you describe the lifecycle of  .modulesOrder.conf

 

What does it do ?
What generates it ? play deps ? 
Is the developer supposed to update that file ?

Can a play 1.3 application work without it ?

Let me explain how it works (and why it is currently this way).

in play 1.2.x when play starts, it reads the modules to loaded from the files in the 'modules' directory.

as described in issue #781  this can result in issues, especially when you have multiple modules that provide templates.

the fix accepted for it, did is introduce a nasty side-effect: "play run" would actually resolve the dependencies again

(while it should only look up the order), as described here #1664.  To mitigate this, the quick-fix was introduced to 

write the order to a file, so that could be used to look up the order. The author of this fix  already stated that this is not the

best solution, but is does fix the problem. 

So here we are: the module ordering issue is fixed; but the order file is stored in way that confuses some other systems

 

Here's my reasoning.

If the file is necessary for the application to work and is not 
a by product of compilation, it shouldn't be hidden (ie its name 
shouldn't start with .)
 

It is confusing for the developer and may be so for other tools 
and/or version control systems. This was the issue with the 
GAE module : hidden files are not deployed.

I agree

 

So, my advice would be to to rename (A) it to modulesOrder.conf and 
find a location for it that :
  - makes sense
  - doesn't have any side effect for existing tooling and modules

If (A) is accepted, then the gae module proved that application/modules/ is not a good place 
as files in that folder are expected to be shortcuts and not description for module order.
I don't know if there are other module that uses the shortcut mechanism
but it seems likely.

If the modulesOrder.conf is supposed to be edited by the developer (which I doubt somehow), then 
the conf/ seems appropriate (B).

no, it is not - it should only be touched by 'play deps'

 

If the modulesOrder.conf is not supposed to be edited or a conf file why not treating it like the 
message file or other templates/resources (C): they are certainly packaged by all the 
modules. 

the messages file sits in conf, templates inside app/views - not sure where this option would place modulesOrder.conf

 

 
If the modulesOrder.conf is not generated in the compilation process then 
I reckon that application/classes (D) is not suitable. And putting the file 
along with .java files so it will copied to application/classes feels not right.

So according to me, the questions are : 
   - does (A) make sense for you ?

yes. apparently the modules/ location is not a good place

 

   - do you confirm that (D) is bad ?

 

yes. as stated: a 'play clean' should removed compiled classes,  not dependency info

  

   - is there any other scenario other than (B) and (C) ?

I'm not sure what scenario (C) would mean for the location. I don't see any other obvious

locations for it though...

 

And then makes the final choice, do some testing (and maybe release a beta 
for 1.3).

yes. as stated future releases will have proper RC's

 

By the way, I think that this discussion should have its own thread.

I changed the subject - not sure if that makes it a new thread though.

To continue we can do one of these:

 1) revert all dependency management changes and reopen issue #781

 2) rename .modulesOrder.conf to modulesOrder.conf and move it to /conf/

  we could add some comment-lines stating that is a generated file that should not  be edited 

 3) take a deep dive into the dependency management and try to create a 'proper' fix

I have a strong preference for option 2 - let me know what you think.

regards,

Robert

  

[notalifeform]

Hi,

Just had another though on this; What if we would name our module-references (in the module dir)

0001-secure

0002-mod1

0003-mod2

this would make ordering trivial.

I think it is worth investigating how big the impact of this would be.

I created a ticket for this in lighthouse 

http://play.lighthouseapp.com/projects/57987-play-framework/tickets/1719-dependency-order-management-modulesorderconf-is-not-compatible-with-gae-plugin

I think it would be best to continue the discussion there.

regards,

Robert

[Carl]

On Wednesday, September 4, 2013 10:12:33 PM UTC+2, notalifeform wrote:

Hi Carl,

To continue we can do one of these:

 1) revert all dependency management changes and reopen issue #781

 2) rename .modulesOrder.conf to modulesOrder.conf and move it to /conf/

  we could add some comment-lines stating that is a generated file that should not  be edited 

 3) take a deep dive into the dependency management and try to create a 'proper' fix

I have a strong preference for option 2 - let me know what you think.

 
2) sounds great.

Having a new issue report opened for a "cleaner" fix is indeed a good way
to gauge the interest at a complete rewrite.

regards,

Robert

[Carl]

On Thursday, September 5, 2013 1:30:09 PM UTC+2, Carl wrote:

2) sounds great.

Is there an open ticket for that issue ?

Besides, I tried to run an 1.2.5 with 1.3 and I got an error message complaining
that the order module file can't be found.

 15:51:08,010 ERROR ~ Carl : Error loading modules
Exception in thread "main" play.exceptions.UnexpectedException: There was a problem parsing .modulesOrder.conf

        at play.Play.loadModules(Play.java:726)
        at play.Play.init(Play.java:280)

        at play.server.Server.main(Server.java:166)
Caused by: java.io.FileNotFoundException: C:\Users\Evasion\Dropbox\docs\projects\github\FrameworkBenchmarks\play1\module
s\modulesOrder.conf (Le fichier sp├®cifi├® est introuvable)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:120)

        at play.deps.DependenciesManager.retrieveModules(DependenciesManager.java:170)
        at play.Play.loadModules(Play.java:723)

        ... 2 more

It would be great if the transition to 1.3 could be smoother either :
1) by generating the file if it is missing. That would be the best
2) printing the command to issue to upgrade the project
3) failing gracefully with a warning

What do you think ?

[Carl]

On Saturday, September 28, 2013 3:57:05 PM UTC+2, Carl wrote:

Is there an open ticket for that issue ?

Silly me, there is : http://play.lighthouseapp.com/projects/57987-play-framework/tickets/1719-dependency-order-management-modulesorderconf-is-not-compatible-with-gae-plugin

[notalifeform]

Hi,

The issue has been resolved in 1.3.x/master.

regards,

Robert