#729 Starting fan with JPDA debugger activated

tcolar Fri 21 Aug 2009

I'm working on adding debugger support on my NB plugin.

Need to start Fan(java) with JPDA args: ex: -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y

Now I can easily add that to fanlaunch, but not sure that is called for windows (is windows a plain exe?)

Could you maybe add an option to "fan" executable like -debug or maybe more flexible like -vmoptions or something, or do you have suggestions on best way to do this.

Thanks

andy Fri 21 Aug 2009

Look at lib/sys.props - fan.java.options

tcolar Fri 21 Aug 2009

Do you think maybe there could be a fan option like -props to specify another props file.

So i could do something like: fan -props debug.props myPod

I mean I guess I can try changing sys.props for the user when they request a debug from the IDE and then restore it after debug ... but that feels a little ugly and error-prone.

tcolar Fri 21 Aug 2009

I tried modifying fan.java.options in lib/sys.props (example adding -verbose) but it does not seem to be taken into account.

I can't seem to see where it's being used from in fanlaunch (linux) either, which is where the Java VM is started from.

What am I missing ? does it work only on windows ?

Thanks

brian Sat 22 Aug 2009

Debugger will be sweet (although I must admit, I'm a debug with println kind of guy).

Note "sys.props" is not used by Bash scripts today. Only by Windows launcher.

I think the simplest thing on Unix is to just set FAN_JAVA to the java command line you want to use with your debug options. It is a fairly simple script if you read thru it, or if you have any patches, please sent them my way.

And remember other than dealing with ext directories, launching Fan via JVM in "the raw" is pretty simple (from docTools::Setup):

// via env var
C:\>set fan_home=c:\dev\fan
C:\>java -cp %fan_home%\lib\java\sys.jar fanx.tools.Fan -version

// via system property
C:\>java -cp c:\dev\fan\lib\java\sys.jar -Dfan.home=%fan_home% fanx.tools.Fan -version

tcolar Sat 22 Aug 2009

Debugger will be sweet (although I must admit, I'm a debug with println kind of guy).

I still do it that way most of time with MY code, but when working with propriatery libraries, don't have that luxuary, so learned to love the debugger :)

Note "sys.props" is not used by Bash scripts today. Only by Windows launcher.

Is that of interest, to have sys.props used in the bash script, I could patch it.

From the IDE, I'm thinking now that the best might be to just skip the scripts, and call it straight from java "in the raw", this way I could make the VM options configurable in the IDE itself.

One thing I was wondering is, I remember discussing using an UrlClassloader for the Fanclassloader, if that's the case, maybe the Fan java bootloader(Fan.java) could find the ext jars by itself and add them to the urlclassloader at boot.

That would remove having to mess with that in the shell scripts, the smaller those are, the better, does that make sense ?

brian Sat 22 Aug 2009

Fanclassloader, if that's the case, maybe the Fan java bootloader(Fan.java) could find the ext jars by itself and add them to the urlclassloader at boot.

I think anything we can do to remove complexity from launcher would be nice. Although I don't think you can extend the native lib path once the JVM has started - which is what you need for SWT. But maybe I am wrong, it would be nice to simplify launch to just FAN_HOME, sys.jar, and main.

tcolar Mon 24 Aug 2009

I remember dealing with that library path business (years ago), anyway thet trick is that you can NOT change the LD_LIBRARY_PATH (or java.library.path) after java started BUT you can use System.load(path) instead of System.loadLibrary(libname)

Of course you need to know the lib full path, but in Fan case I think they are all relative to FAN_HOME, so I think you know the path and if you load all those libraries like this, before using swt.jar, it should work.

I can try modifying/testing the script/fan launcher like this later if you want (prob. tomorrow).

brian Mon 24 Aug 2009

I remember dealing with that library path business (years ago), anyway thet trick is that you can NOT change the LD_LIBRARY_PATH (or java.library.path) after java started BUT you can use System.load(path) instead of System.loadLibrary(libname)

Interesting - I will try that (but probably will be a little while). We are cranking on some SkyFoundry code right now, so not doing much Fan work for the next week or two.

tcolar Mon 24 Aug 2009

No problem, I might give it a shot myself sometimes this week, when I have time.

Login or Signup to reply.