Wanted: Developer for Web Interface Mobile

[GKusnick]

Originally Posted by wayner

I redownloaded the Jetty 1.4 files and overwrote all of the files in the Sage folders - I believe I may have already had these. Is there anything else I have to do such as delete files so that they re regenerated?

Did you follow the Jetty upgrade instructions in the wiki?

[wayner]

Originally Posted by GKusnick

Did you follow the Jetty upgrade instructions in the wiki?

Yes - but it looks like I aleady had the latest files which is what caused the problem that you helped me with yesterday - changing the package names to sagex.*.

All of the files were 6.1.11 rather than 6.1.7 so I think I did have the latest yesterday in my current install. Perhaps it just won't work with the browser on the Bold - once these get rolled out in the US in the next few weeks perhaps other folks can try as well.

[jreichen]

Can you start by posting your sagetv_0.txt and the latest file from jetty/logs/? If they don't have enough detail we can start turning up log levels.

[wayner]

Here are my logs - I slightly altered my external web URL so as not to make it too easy for hackers to get in.

[jreichen]

Nothing looks wrong in your logs, but then again I don't see anything in the request logs coming from a Blackberry browser. See post #175 for something I would expect to see from a Blackberry browser and #177 for getting more detailed logging. Could you try it with your Blackberry browser and see if it logs anything else?

[jreichen]

Originally Posted by Slugger

WinXP. It seems if I try to unzip a package using the native WinZip GUI or from a Windows command prompt I get the error (unable to overwrite the war), but when using Cygwin and its unzip from a cygwin shell I'm able to overwrite the wars without an issue. Of course, it's unlikely that most users are going to have/use Cygwin when installing/upgrading apps so I fear that the hot deploy capabilities are not going to be very useful (in the case where Jetty is started with war files already in the webapps dir, which will be quite common after the initial deployment of an app).

This behaviour is consistent on two different machines - both XP.

What if you extract the context and war files from the downloaded zip file to a temporary location, then copy the files to the jetty/contexts and jetty/webapps folders. Copy the war first so it's there when Jetty sees the updated context file and attempts to do the hot deploy.

Come to think of it, you could also try copying the context file first. Then maybe Jetty would discard the class loader that was used when SageTV started and that would unlock the war file. Then you'd have to copy the war file followed by the context file to hot deploy the new war.

[wayner]

I figured out the problem with the Blackberry Web Browser - I was using port 8090 and it appears that either my company's BES (Blackberry Enterprise Server) or Blackberry are blocking that port. I switched to port 80 (by forwarding port 80 on my router to port 8090 on my Sage PC using my router's port forwarding) and all is well. Now I have to find a port that will work other than 80 since I am using that for other stuff. Any suggestions on what port to use that is likely to not be blocked yet is not used for other stuff that could cause problems? What about port 70 - that is used by Gopher and I haven't used Gopher since 1993?

[jreichen]

Slugger, the locked war is definitely a Windows-only problem. The good news is it's easy to fix and there are a few ways to do it. Check out Jetty Files Locked on Windows.

Are you having this problem with the mobile web interface, SRE, or both? You shouldn't have the problem with the mobile web server because its context xml is configured with "copyWebDir=true" as discussed at the bottom of the page. Did you change that to false for SRE?

Even if you set that to false, the jetty/etc/webdefault.xml file can be modified so that "useFileMappedBuffer=false" to fix the problem. I could change that for Jetty plugin 1.5 and get rid of the problem. It shouldn't impact performance given the low volume of web pages served on a SageTV server.

[jreichen]

Originally Posted by wayner

I figured out the problem with the Blackberry Web Browser - I was using port 8090 and it appears that either my company's BES (Blackberry Enterprise Server) or Blackberry are blocking that port. I switched to port 80 (by forwarding port 80 on my router to port 8090 on my Sage PC using my router's port forwarding) and all is well. Now I have to find a port that will work other than 80 since I am using that for other stuff. Any suggestions on what port to use that is likely to not be blocked yet is not used for other stuff that could cause problems? What about port 70 - that is used by Gopher and I haven't used Gopher since 1993?

Well I'm glad you got this far. I'm using 81 for the time being since I have something else on 80. I'll let some others chime in on port numbers if they want and you could also search through the thread for nielm's web server and see if there are any suggestions there for choosing a port number.

There's also the option of using a reverse proxy in Apache, but the setup has never been completely verified and documented.

[wayner]

Originally Posted by jreichen

Well I'm glad you got this far. I'm using 81 for the time being since I have something else on 80. I'll let some others chime in on port numbers if they want and you could also search through the thread for nielm's web server and see if there are any suggestions there for choosing a port number.

There's also the option of using a reverse proxy in Apache, but the setup has never been completely verified and documented.

I think the problem may be that the Blackberry browser dows not allow you to enter a port number. It doesn't like it even when I enter :80 after my web address.

[jreichen]

Originally Posted by wayner

I think the problem may be that the Blackberry browser dows not allow you to enter a port number. It doesn't like it even when I enter :80 after my web address.

I had the same problem with my phone's NetFront browser so I installed Opera Mini.

[Slugger]

Originally Posted by jreichen

Slugger, the locked war is definitely a Windows-only problem. The good news is it's easy to fix and there are a few ways to do it. Check out Jetty Files Locked on Windows.

Are you having this problem with the mobile web interface, SRE, or both? You shouldn't have the problem with the mobile web server because its context xml is configured with "copyWebDir=true" as discussed at the bottom of the page. Did you change that to false for SRE?

Even if you set that to false, the jetty/etc/webdefault.xml file can be modified so that "useFileMappedBuffer=false" to fix the problem. I could change that for Jetty plugin 1.5 and get rid of the problem. It shouldn't impact performance given the low volume of web pages served on a SageTV server.

copyWebDir=true is set in the context file, but it continues to happen. This is SRE only, I'm not using the mobile app. It's actually happening in both apps I'm writing and both have copyWebDir=true in the context file. Perhaps you could disable the useFileMappedBuffer setting for the next release of the plugin? My guess is that Jetty buffers any war files it finds at startup, which is why I can avoid the problem by hot deploying my apps after Jetty has started up, which allows me to overwrite the war file without issue as needed.

[jreichen]

Originally Posted by Slugger

Perhaps you could disable the useFileMappedBuffer setting for the next release of the plugin?

I don't have Windows, could you verify it works? Make the change in jetty/etc/webdefault.xml and restart Sage. If it works I'll make the change.

[Slugger]

Originally Posted by jreichen

I don't have Windows, could you verify it works? Make the change in jetty/etc/webdefault.xml and restart Sage. If it works I'll make the change.

Tried it, but didn't work. It is definitely Jetty that is locking the file and preventing overwrites (kind of obvious, but just wanted to make sure it wasn't Sage itself that was perhaps locking the file). But it's only locking the war and not the context file - I can happily overwrite the context file.

[jreichen]

Originally Posted by Slugger

Tried it, but didn't work. It is definitely Jetty that is locking the file and preventing overwrites (kind of obvious, but just wanted to make sure it wasn't Sage itself that was perhaps locking the file). But it's only locking the war and not the context file - I can happily overwrite the context file.

Could you try the attached jetty.xml file (I had to change the extension to .txt to be able to post it here)? I commented out the WebAppDeployer section.

[voorhees]

I am trying to follow the discussion, but wanted to make sure I understood. Is the Slugger/jreichen discussion focused on the hot deploy of SRE (or any other jetty app)?

I installed SRE a week ago or so with Jetty 1.4 and had no problems, however I think I shut down SageTV first.

[gplasky]

Originally Posted by voorhees

I am trying to follow the discussion, but wanted to make sure I understood. Is the Slugger/jreichen discussion focused on the hot deploy of SRE (or any other jetty app)?

I installed SRE a week ago or so with Jetty 1.4 and had no problems, however I think I shut down SageTV first.

I think the issue is with having both the mobile web inerface AND the SRE plugin installed because they both use jetty and I believe one of them is locking a file and preventing the extraction of a war file.


Gerry

[Slugger]

Originally Posted by gplasky

I think the issue is with having both the mobile web inerface AND the SRE plugin installed because they both use jetty and I believe one of them is locking a file and preventing the extraction of a war file.


Gerry

This issue shouldn't be with using both SRE and the mobile web app at the same time, since I'm not using the mobile app on my Jetty installation. The issue is that, as far as I can tell, any war file that is in the webapps directory of jetty when SageTV is started is being locked by Jetty (on Windows). When this happens you cannot overwrite the war file, which means that hot deploy capabilities of Jetty are lost, which means any upgrade/downgrade/removal of an application (be it SRE, mobile web, etc.) is not possible. The current work around I've been using is to delete all the wars before starting Sage then hot deploying them after Jetty has started up. This works fine, but isn't very useful for most users.

I see jreichen has another fix for me to test so hopefully we'll have this solved soon enough anyway.

[gplasky]

Originally Posted by Slugger

This issue shouldn't be with using both SRE and the mobile web app at the same time, since I'm not using the mobile app on my Jetty installation. The issue is that, as far as I can tell, any war file that is in the webapps directory of jetty when SageTV is started is being locked by Jetty (on Windows). When this happens you cannot overwrite the war file, which means that hot deploy capabilities of Jetty are lost, which means any upgrade/downgrade/removal of an application (be it SRE, mobile web, etc.) is not possible. The current work around I've been using is to delete all the wars before starting Sage then hot deploying them after Jetty has started up. This works fine, but isn't very useful for most users.

I see jreichen has another fix for me to test so hopefully we'll have this solved soon enough anyway.

OK-thanks for the explaination. Obviously I didn't quite understand the issue.

Gerry

[Slugger]

Originally Posted by jreichen

Could you try the attached jetty.xml file (I had to change the extension to .txt to be able to post it here)? I commented out the WebAppDeployer section.

Tried the new jetty.xml and no dice... same issue - the war is locked if it exists at jetty start up.

I've attached the context file I'm using, looks pretty standard (comes from your skeleton on the wiki), but just in case.