Where to start with learning how to use Jetty?

[wayner]

I want to start playing around with Jetty and perhaps adding some functionality to the Sage Web pages and perhaps adding other related functionality to the Jetty web server, like a UI for Harmony Hub Based remotes.

Any advice on where to get started, other than the obvious online Jetyy tutorials?

What version of Jetty should I be using? (I believe the latest version(s) require Java 8 which may be problematic)

Any other advice?

p.s. I am not a developer but I have dabbled in programming for over 35 years starting with BASIC (and 6502 assembler) on the Commodore Pet and C64, Apple IIc, using PASCAL and Fortran in university, etc.

[wayner]

Anyone? Buehler?

[Slugger]

So you're sort of talking about two different things here. I think a good starting point is separating the two.

First you talk about Jetty and wanting to play around with it and then adding some functionality to the web ui pages. These two are separate things -- very separate things -- each having nothing to do with the other.

Jetty is a J2EE servlet container. It's the server that hosts and runs Java web apps. You likely aren't going to touch this plugin at all. You certainly won't if all you're trying to do is mod the behaviour of the web ui web pages. Jetty is (sort of) like the Apache web server. You don't play with the Apache settings to modify the content of an html page. Same idea here. You don't mess with the Jetty server when you want to change the content of one of the apps running in it.

One of those apps is the web ui plugin. This is a separate plugin. The source code for this plugin eventually builds itself up into a war file, which is then deployed inside Jetty. When you talk about the contents of the web ui web pages, this is the plugin you want to be modifying.

When you load the source code for the web ui plugin, you're going to be dealing with a lot of Java code. All of the legacy (original) web pages in this plugin (home page, recordings page, recording schedule page, favs manager, etc.) are all produced by pure Java code via J2EE servlets. So if you want to change the output of one of those pages, you have to jump into the Java code and make the servlet you're trying to change output different html to the servlet response's output stream. Not fun, but, of course, all very doable depending how motivated you are to accomplish whatever it is you're after.

Then when you get the code modified, you need to build a new war. This is where the real fun begins. First you need a build environment. It's been quite some time since I've done a build of this plugin (at least 2.5 years because I never rebuilt any env for this plugin after I moved and that was summer 2013), but I spent a long time making it less painful than it was when I inherited the project way back when. It's still hardly what I'd call developer friendly, but the ant script that's there shouldn't be too bad. Thing is, you have to be careful that when you build the war that it includes all the legacy features. I caused many regression bugs just via build errors during my time with it. It got to the point where I stopped touching any of the legacy code and just crossed my fingers and hoped for the best when I did build up the courage to do a new build to the repo. That's why I spent a lot of time introducing the groovy server pages into the web ui. It allowed me to isolate the ability to add new pages from the legacy code such that I never touched the legacy stuff and only focused on the groovy stuff -- not to mention adding new pages via groovy is much quicker.

Then when you get your war built, deploy locally to your own server by simply replacing the existing war in SageTV/jetty/webapps. If you built it right, it'll redeploy the new version.

If you're doing this to eventually update the version of the plugin in the repo then you need to heavily test all your changes, especially if you modify any of the existing legacy servlets. I usually always ran a new war locally for a couple weeks before releasing if I did touch anything outside of the new code I introduced over the years. But even if you do that, it's still not perfect because like one time I completely broke the online remote control thing -- a build error -- but I just never use that so never thought of testing it. Another time it was all the xml views that I broke. This one is especially bad because a lot of other plugins make use of those xml views. And I could keep going, but you get the idea.

If you're just making these changes for yourself then you can just have at it. Just be sure to keep a copy of the existing war file before you replace it with any build you do so you can always just revert back to the last official version as needed.

Good luck!

[wayner]

Thanks Slugger - I totally forgot that you added the capability to be able to build pages in Groovy. That will likely be the way to go. One of the things that I want to do is add in info from my Harmony Hubs as there is an (unofficial) API for these. This way I can see if any TVs around the house have been left on and I can effectively extend the SageTV remote type of functionality to control all AV components.