msteiger
MPD listeners not registered when mpd is not running while starting
Because of how the initialization is done, the various listeners will never be registered when an exception is thrown at https://github.com/msteiger/play-mpc/blob/master/app/controllers/Application.java#L74
That's right. You cannot use the instance if an exception is thrown in the constructor. Which exception do you get and what' the point in continuing if initialization doesn't work?
Which exception do you get
I'm getting a MPDConnectionException
and what' the point in continuing if initialization doesn't work?
Counter-question: Why do you make the initialization fail if the connection cannot be established at startup?
Ideally, the app would try to connect to an MPD instance continuously, and register the listeners once a connection is established. Repeat after the connection is lost.
[To my (biased) mind this would be a perfect fit for using Akka with play2. But, currently, I'm still withstanding the reflex to re-implement the app myself...]
I see now, what you mean. Would it make sense to plug Akka into the existing Java application? I'm a fan of baby steps - gradual transformation over complete restart.
Honestly, I have no experience with using Akka in Java. I have played a bit with some ideas which lead me to nowhere during the hour of spare time I spent on this (mainly because the interfaces of Java and Scala for Akka as well as for play differ quite a bit).
I tried to separate the Websocket handling into an actor (because there're concurrency issues with the current implementation - I got ConcurrentModificationException's ). Seems in play 2.2 - when using Scala - there's a broadcast Websocket mechanism available which would solve this without much ado.
Babysteps are nice, but sometimes hard to do. I have to think a bit more about this perhaps.
[in the meantime, I have added a display of the currently playing song to the playlist page. Alas, it's still a bit rough around the edges and needs some polishing]
update: after another fiddling last evening, I successfully re-implemented the Websocket handling in Scala using the aforementioned Concurrent.broadcast mechanism. This should solve the concurrency problems and makes the code very concise. I just began learning play, but I'm starting to love it...
I'll keep you informed and upload the patches when I find the time.
I just pushed my code into this branch: https://github.com/avdv/play-mpc/tree/scala-app
Works pretty well.
But there's a glitch. (almost) Every time a "reload" command is send over the websocket, a ClosedChannelException is thrown - it doesn't break the app, but it's not pretty either.
Since the code is quite similar to the original Chat sample of the play framework, I've asked on their mailing list what the problem could be. Now I'm waiting for an answer -- or some bright idea...