Tony Docherty wrote:Here's a simple test class that disables the the JTextArea which effectively removes it from the focus cycle but stills allows you to click in it to select it. Once you move out of the JTextArea it is disabled again.
Note: to tab out of the JTextArea you will need to use CTRL+TAB as TAB is handled by JTextArea to insert a tab into the text area.
Tony Docherty wrote:
This does what you requested but I'm not convinced being able to click into a disabled field to edit it is particularly intuitive.
Ulf Dittmer wrote:I'd advise to look into one of the available cache libraries (see http://faq.javaranch.com/java/CachingStrategies for which ones are still actively developed). If the library in question doesn't handle concurrency issues, I'd look into using a java.util.concurrent.locks.ReadWriteLock to guard the operations that alter the cache while it might be read by another thread.
Henry Wong wrote:
Well, can you explain to us, why you think it is so? Synchronizing on the same lock is common when two methods need to work on the same thing, and isn't enough to say that something is a deadlock.
Steve Luke wrote: If I did this I would probably start/stop the thread/executor from a ServletContextListener rather than the Filter to be sure it started up as soon as the web app does, and stops when the web app does.
Steve Luke wrote:
Steve Luke wrote:
You will have to way the ups and the downs yourself (for example if it takes a real long time to update the data and you have a small thread pool to run requests in and/or have a high load on the server then this might not be best).
Steve Luke wrote:
If you have a task you want to do every x period of time, why not setup a scheduled task to do it at its own pace?