Mike Dahmus

Ranch Hand
+ Follow
since Mar 07, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Dahmus

Campbell Ritchie wrote:You appear to have asked the same question twice, so I have merged your two threads.



I asked again in the JavaFX forum per Tim's suggestion actually.
Hi,

Was suggested to post here - how feasible/easy is it to migrate old Java3D source to JavaFX? (I need to set up a new dev environment from scratch and was worried it would be difficult to nigh-impossible to get Java3D up and running nowadays, and was pointed to JavaFX as the next place to check).

Thanks,
Mike
I'm thinking of the difficulty in setting up Java3D from scratch again, but maybe that's overthinking things? I'd like to be able to show the project off as well.
I have an old project I want to resurrect in something that'll work today - what's the easiest path forward in something Java or Java-adjacent?
followup: I now see the method getLocalAddr() was added in Servlet 2.4. Unfortunately, I'm stuck for now with Servlet 2.3 (can't afford to upgrade our embedded Tomcat to 5 at this point - way too risky). Any hacks which can get me there on 2.3?
17 years ago
I have code running on the server in a login servlet - in the case which is causing concern we're using a clustering solution which results in multiple IP addresses being active (on different interfaces) for the same machine. One is the 'normal' address and one is the 'cluster'. (i.e. one machine at a time 'owns' the cluster address).

For various reasons, I need to know which IP address is being used on a given servlet call. (i.e. the machine's normal eth0 address is 1.1.1.1, and it also has an eth0:0 address of 3.3.3.3 (cluster); the servlet needs to know which one is being used for the current HTTP activity so I can potentially tell them "don't log in here; log in there instead").

getServerName() works somewhat - but provides a hostname if the user had connected that way from the client. That makes me unsure that this is even going to work for the case I'm concerned about. Basically we used to do this on the client side but discovered that the NAT case doesn't work with this (where the servers are behind a NAT and thus the client can't compare what it sees in a well-known spot on the server against its own settings, since the client's versions of the addresses aren't the same).

Any suggestions?

Thanks,
Mike Dahmus
mdahmus@netbotz.com
17 years ago
I have an external app I need to drive by sticking data in its stdin - I create the process and grab the streams accordingly (see below). On unix, this works fine, but on Windows I'm getting

java.lang.IOException: The pipe is being closed

as soon as I try to write a second batch of data to it (I don't close the stream in between writes). Anybody seen this before? I could theoretically write to a local file and change how I call the app, but I'd rather not, since it works quite well done this way in its existing environment on the unix server and I'm trying to maintain common code.

Here's the creation code:




and writing to the process goes like this:

17 years ago
I have a chunk of code which is interacting with a cache (threaded) where cache-notification events attempt to kick off a runnable via SwingUtils.invokeLater as below. In my case, there are eleven cache events occurring (I hit all of them with the debugger and with the print statements) but the runnable only actually runs four times.

protected void notifyPostCacheListeners(final CacheEvent ev) {

System.out.println("notifyPostCacheListeners... outside");

Runnable r = new Runnable() {
public void run() {

System.out.println("notifyPostCacheListeners... runnable.run");

if (_cacheListeners != null) {
for (int i = 0; i < _cacheListeners.size(); i++) {
((CacheListener)_cacheListeners.get(i)).cacheUpdate(ev);
}
}
}
};
SwingUtilities.invokeLater(r);
}

It's ALWAYS four times here. That's what's hard to figure out - if I had a race condition, I might expect a different number of runs. (The cacheUpdate call inside the runnable always successfully completes).

Any ideas?
Another problem which has presented itself:
The path is like this, simplified:
1. Download DLL - this sticks it in the user's desktop on Windows (guh)
2. Execute code which calls DLL
3. Try (and fail) to delete DLL (to clean up user's desktop).
How can I, after 2, relinquish my hold on the DLL so it may be deleted?
17 years ago
Nope. The jar executes, determines local platform, and (if Windows) downloads the JNI DLL. Then and only then does it execute the java code backed by the JNI DLL.
(Obviously my jar is running with all possible privileges at this point).
Packaging the DLL inside the jar - never thought of this. It would add unnecessary download time on unix boxes, but that might not be a deal-breaker... any problems to look for here?
17 years ago
A lead engineer in my new company wants the new DLL (that I use to access the Windows registry - downloaded from an existing applet) to be signed, as is the jar with the applet itself.
I'm flummoxed - after 45 minutes with google, I can't find anybody doing this in any other environment than ActiveX.
Anybody ever dealt with this requirement? We already have all the certificates we need, I think; I just need some mechanical (and tool) help with the signing of the native-code DLL piece of it.
Thanks,
Mike Dahmus
mdahmus@io.com
17 years ago
I'm writing a Swing component which must function similarly on Apple and Windows; and am having trouble with which event to fire off of
(this is effectively a toggle button which would ideally just be interested in mouseClicked). For a variety of other reasons, I don't want to make my code act on the mousePressed event.
Originally, our QA person asserted that it was busted because she was clicking (and moving the mouse > 10 pixels) and it wasn't getting "toggled" (this was on Windows). I won the battle there by saying "don't move it 10 pixels; that's a drag, not a click". (after debugging and figuring out that if you moved the mouse more than approximately that much, the mouseClicked never came in).
However, she now claims that on Apple (OSX) that the button fails to toggle if you move the mouse even one pixel while pressing the button. (i.e. if you are not perfectly still while clicking).
Obviously this would be a different story. I don't have immediate access to an Apple machine, so was wondering if anybody else had seen this behavior. When I worked on the AWT on OS/2 at IBM, it was fairly clear that the mouse events were determined based on native operating system events (i.e. when Windows says it is a click, we'll say it is a click). Don't know if that's true now or not, since I haven't seen the code since Java 1.1.8.
18 years ago

Originally posted by Mark Herschberg:
Today the companies aren't colluding, they're just making the most of a soft labor market.


This is dishonest.
H1-B and L-1 are examples of the companies "colluding" in the sense that they are artifically manipulating the market.
18 years ago

Originally posted by Mark Herschberg:

In the US we have good roads, free public education, safe streets, public transportation systems, opportunities for personal growth, public libraries, FAA (allowing safe, low cost air travel), telephone service available (even if not paid for) in every house, social services, clean water in every town, etc. I'm guessing India doesn't have the same support for it's citizens.
Did you think this was free?!?! It costs money! If you don't like it, tell the politicans to pull the plug on these social services. We can live just like any other country, and even save money to boot!
--Mark


It must save you a lot of time to not bother reading the points of those with whom you argue.
The point is that the "race to the bottom" has begun; and to claim that we're competing "on a level playing field" only makes sense if you enjoy the least-common-denominator approach to economic development.
God lord, you're a smug git.
18 years ago

Originally posted by Mark Herschberg:

Realistically, however, child labor isn't taking software jobs from the US. Neither is environmental constraints. In our industry, India isn't do anything we can't do ourselves, if we so choose.
--Mark


Realistically, our overall tax burden (including that on corporations) and cost structure incorporates all of the above; so, in fact, we _can't_ do what India is doing without losing what makes us a first-world country.
18 years ago