Dennis Zandvliet

Ranch Hand
+ Follow
since Jun 19, 2008
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dennis Zandvliet

Thanks for your example code, I will give it a try.

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.

I guess this can be fixed by changing focus traversal keys from CTRL+TAB to Tab?

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.

In hindsight I didn't specify my problem correctly.
All i want is that some readonly (not editable?) fields textfields are textareafields are not part of the normal tab focus cycle, but that users are still able to click on such readonly fields to select and copy text. So probably in this context the terms/properties ' enabled or disabled' are not correct.
8 years ago
I've already read 'How to Use the Focus Subsystem' and those API's. I've also tried a Custom FocusTraversalPolicy, but it didn't work.

I'm thinking of combining a Custom FocusTraversalPolicy with a MouseListener. But since their are already other listeners defined for these components I'm afraid that you might get unexpected/undesired behaviour.
8 years ago
The behaviour I want is, that a specific disabled JTextArea is not part of the focus cycle, but when I click on it with a mouse the JTextArea:

-becomes enabled
-gets focus
-and the text inside becomes selectable for copying

Then As soon as I tab inside the JTextArea or click on another component, the the JTextArea loses focus and is *not* part of the focus cycle anymore.

In other words, even though the JTextArea is not part of focus cycle root, i want to be able to click on for the sake of selecting and copying the text inside this component

For an example of this behaviour see the preferences panel of the Eclipse editor. (Version 3.7.0)

menu-> window-> preferences
and inside the preferences window select:

in the tree -> general -> Appearance -> Colors and Fonts.

And check the behaviour of the 'Description' JTextArea field.
8 years ago
What i do now is loop through the array and do an indexof on all Strings, which i I think isn't very efficient. So I wonder if their is a smarter/faster algorithm.
11 years ago
An existing application in which i want to add some LDAP caching. First I only wanted to load all the ldap entries periodically in a separate thread for read only access for periodically generating some javascript. But than i thought he if all the data is cached why not use it for other part of the program which need this. And than I thought well instead of periodically do a complete refresh, why not use the JNDI LDAP notification system to keep the cache up to date, but still periodically, may be once per day do a complete refresh of the cache to be sure that we due to unknown errors some records hasn't been synchronized properly.

For now i have off course the application itself :-), and a simple cache which consist of a class which holds a reference to a map which is periodically being replaced by a new instance of a map which has been populated by the same task. Why ever time creating a new map and replacing the old one?
Because at the moment this seems the easiest way for me to avoid the dreaded race conditions without locking the whole current map in use because updating from ldap takes a long time about 15 seconds.

I guess this can be done better without using every time a new map. If this works fine I also want to add, updating individual records/objects by adding the ldap notification support, which off course adds more complexity.

I'm not afraid that their will be memory leakage due to the fact that their are still references to the old map, because all references exist only for the duration of a request.

So writes should only come from the ldap notification event handlers and from the task which updates the whole map. And reads from the rest of the application. Reads can come from individual look up of entries are from looping through all map entries.

I all ready know that you have all kind of map implementations which have been optimized for concurrent use, but I also know that you have to be very careful and know exactly what you are doing, otherwise things can go terribly wrong.

Ulf Dittmer wrote:I'd advise to look into one of the available cache libraries (see 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.

Thanks, but I don't want to use a cache library (yet), because I want to get my own hands dirty.

I want to create a simple cache, for holding lots of user data objects.

From time to time all data is being discarded and again being populated by a single update thread.
Also single entries can be update, modified, inserted by (LDAP) notification events.

The map is being read by many threads.

Some threads only look up single entries while others loop through the whole map.

I've read many articles about this, but you've to take so many thinks into account, that I'm kind of lost.

Also should you store this map into the context, which can be awkward because you have to pass the context around, or use static methods to access the map?
When receiving a java naming event, you can get the binding from this event, which contains an object


My question is, how do i get the attributes from this object?
Thanks. I was only focusing on the synchronized keyword.

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.

You're competely right! :-)

Well, if the getConnection() method holds a lock on the connection object, how can the returnConnection() method enter the synchronize block to send a notify, because it's also locked on the same object?
I was looking at this example How to use wait() and notify()

Now I'm wondering if this code isn't causing a deadlock, because both methods synchronize on the same object 'connections'?

If not, why?
After implementing the simple solution I know decided to go for the Threaded solution, so I've some more questions. :)

-Why not use a timer instead of a scheduler since we only create one thread?
-How do you do a retry if getting the data from the datasource fails? Do you that inside the thread or recreate the thread?
-I'm storing all the retrieved data in a map, what's the best strategy for repopulating?
a) Reuse the map: before repopulating the map, first clear all the entries. Effectively I think this means blocking the app again
b) Or creating a new instance of a map, populate this and at the end of the population update the global reference to this map. cons: need twice as much memory. (and the map is pretty large about 5000 user profiles)

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.

Retrieving the data takes about 10 seconds, how will i be sure that the data is ready when the first request arrives at the filter?

Steve Luke wrote:

One more question how do you properly declare js_new and js_old with respect to, scope, synchronization and type, StringBuilder or StringBuffer, and this similar discussion in mind?

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).

Thank you for your response. I will stick with this. It's not a problem that the data is stale, because it's just a user list, which will be updated outside the app infrequently.

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?

I didn't want to make it to complicated with threading inside a filter etc.

I just wanted to use a simple update scheme: within a request use the old data unless it's time to refresh.

something similiar like this:

final long lastModified = file.lastModified();

if (xmlLastModified >= lastModified) {
dosomething ;