STAF seems to expose only its own handle to manage processes launched using the Process service. I need to obtain the OS PID in order to perform some other things. I don't see that exposed in the API anywhere. Does anyone know how to get the PID for a process launched through a Process service call??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently, there is no way to do this. It doesn't seem like it would be too hard to add, so open a feature request (although, I can't guarantee any timeframe for implementation).
If the process you need to interact with can help out, then it could set a STAF variable containing it's PID (e.g., Test/Handle/<Handle>/PID=<pid>).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I downloaded the 3.1.0 source and tried building in cygwin/win32 so I could hack my a local version in the meantime. (At a cursory glance, it seems that the only things that really need to change is STAFProc's implementation of fProcessInfoMapClass, fListProcessMapClass, and fListLongProcessMapClass need an additional key for the PID. )
Unfortunately i can't seem to get things built from staf/makefile, due to a variety of reasons (e.g. cygwin installing stuff to paths that don't match makefile, rexx and tcl are not installed, etc.)
I did manage to get STAFProc compiled by itself in Visual Studio, but I get a "STAFSERVICELOADER1 fails to initialize" message at startup. My project uses the files listed in the makefile.staf and I link against STAF.lib, so I suspect it's something really basic that I'm missing. Any ideas on what's going on?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should be able to get around the service loader initialization failure by commenting out that line in the STAF.cfg (the one with STAFDSLS).
As for building STAF on Windows, let's just say things are a little picky. Given that you have visual studio set up, we should be able to get things working for you.
First things first... read the STAF Developer's Guide (if you haven't already) as it gives you details on what (environment) variables need to be set up (and other details) in order to build STAF. You may also want/need to looking build/makefile.mvc to verfiy you have your compiler path settings defined correctly (there are settings for various versions of the microsoft compilers). Hopefully, you won't need to actually change anything in build/makefile.mvc -- I'm pointing you there just as augmented documentation to what's in the STAF Developer's Guide.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I read the dev guide and I looked through makefile.win32 and makefile.mvc. I am using the source from STAF310-src.zip, to minimize the chance that my custom services linked against the existing binary of STAF.lib have issues.
When building under Visual Studio 2003, I included only c:\staf\bin\STAF.lib, LIBCPMTD.lib, and LIBCMTD.lib; this allowed successful linking. Including only the advapi32, user32, and wsock32 as seen in makefile.win32 resulted in linker errors. I managed to get STAFDSLS to load, but only by replacing references to gAnonymousString with a hard-coded "anonymous". (For some weird reason, gAnonymousString.buffer((void*)0) was returning a bad memory pointer.) Unfortunately getting STAFDSLS to load did not work for any of the other STAF services, like event, stax, etc. So, if any of this somehow sparks any insights as to how I'm screwing this up, I'm all ears. If not, oh well. I'm willing to accept that the attempt failed.
I gave cygwgin another shot, too. I defined the variables as described in the dev guide. In particular, used these settings: OS_NAME="win32", CC_TYPE="MVC7", MSVCDIR="C:/PROGRA~1/MICROS~2.NET", VSCOMMONDIR="C:/PROGRA~1/MICROS~2.NET/Common7", MSSDKDIR="C:/PROGRA~1/MICROS~2.NET/Vc7/PLATFO~1", BUILD_TYPE="retail", PROJECTS="staf connprov*".
The errors that I get are rather odd:
/cygdrive/c/src/staf/codepage/makefile.staf:42: /cygdrive/c/obj/win32/staf/retai
l/codepage/ucm2bin.d: No such file or directory
/cygdrive/c/src/staf/services/defaultsls/makefile.staf:39: /cygdrive/c/obj/win32
/staf/retail/services/defaultsls/STAFDefaultSLS.d: No such file or directory
/cygdrive/c/src/staf/services/log/makefile.staf:39: /cygdrive/c/obj/win32/staf/r
etail/services/log/STAFLogService.d: No such file or directory
-- errors continue, all of similar nature --
Any ideas what I'm doing wrong? I could find the object/win32/staf/retail dir, but the ..retail/codepage part wasn't there. I can find uc2mbin.cpp and a variety of other .cpp files. Is there a reason why the makefile is looking for .d files? Did I miss an environment variable somewhere?
For the heck of it, I tried using Microsoft's nmake, with zero success.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those "errors" are expected. The ".d" files are dependency files. Make reports that they can't be found, and then uses one of our rules to generate them. At the bottom of that list of missing ".d" files, you should see the real error. My current guess would be that you don't have python installed as part of your cygwin setup. The program that generates the ".d" files is a python script, which is why you need to have python installed as part of cygwin.
As far as building natively in Visual Studio, I don't have any good advice, as I've never done that myself (for STAF).
On a positive note, Sharon, one of our developers, is trying to implement the feature to provide the PIDs for processes started with STAF. With any luck it will be in the STAF V3.1.1 release which should be released in the next week or so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm glad that Sharon is working on the feature. I got things to build, but now I run into the exact same problem that I had in visual studio.
---
Caught unknown exception in HandleRequest()
Error initializing service loader service, STAFSERVICELOADER1, RC: 22, Result: E
rror initializing service, STAFDSLS, Result:
Caught unknown exception in main()
---
(sigh) I'd be content to wait, but my management actually wants me to get things building so that we can modify with the source *if* we ever need to. It's my full intention to rely on official releases as much as possible... this includes the feature for disabling DNS lookup. However, at work is a manager's innate reflex to minimize risks and reduce dependencies.
I graciously thank you for all your help, and I really do appreciate it. Please understand if it seems that I'm pestering on "wasted effort", it's because my job is asking me to. I have been on the implementation end of feature creep - so I do understand the cumulative effect of "little features" adding up to a lot of time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
fyi...I have completed Feature #1356848 "Get PID for process" and checked the updated files into CVS.
We would also like you to be able to build STAF so that you can contribute any bug fixes or features to the STAF project.
Are you sure that you have set up the environment variables to point to the appropriate directories where you built STAF before running STAFProc?
Add both the bin and lib directories to your path. For example, my STAF retail build directory is C:\dev\sf\rel\win32\staf\retail.
SET STAFDir=c:\dev\sf\rel\win32\staf\retail
SET PATH=%STAFDir%\bin;%STAFDir%\lib;%PATH%
SET CLASSPATH=%STAFDir%\lib\JSTAF.jar
SET STAFCONVDIR=%STAFDir%\codepage
cd \dev\sf\rel\win32\staf\retail
STAFProc
If that doesn't help, did you try comment out the default service loader line in the default STAF.cfg file? For example:
# Add default service loader
#serviceloader library STAFDSLS
If you're still having problems, paste the output from SET here (to show your environment variables that you're using when you run STAFProc from your STAF build tree).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I backed up my STAF install and I copied my build/res dir over it, and I still get an exception when attempting to load STAFDSLS. Given that all of the source is from v3.1.0, unless STAF requires that JSTAF be built at the same time as STAF.
I commented out STAFDSLS, but I get errors when initializing other services. I suppose it makes sense that I need the STAFDSLS for the Event and EventManager services.
The error that I'm getting seems identical to the problem encountered when building in the Visual Studio .NET 2003 IDE. Out of curiosity, which compiler did you use for your official Win32 release? If I need to, I can probably install that on a Virtual PC system and see if my version of Visual Studio is causing problems.
The output from SET appears at the bottom of the page.
--- SET ----
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\nkidd\Application Data
BISTRO_GLOBAL_CACHE_DIR=C:\Program Files\Intel\VTune\CGGlbCache
CLASSPATH=C:\Program Files\Intel\VTune\Analyzer\Bin;.;C:\STAF\bin\JSTAF.jar;C:\STAF\samples\demo\STAFDemo.jar
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=NKIDD-DEV
ComSpec=C:\WINDOWS\system32\cmd.exe
CSSCRIPT_DIR=C:\Documents and Settings\nkidd\Desktop\scripting\cs-script
DevEnvDir=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
FP_NO_HOST_CHECK=NO
FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework
FrameworkSDKDir=C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1
FrameworkVersion=v1.1.4322
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\nkidd
INCLUDE=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\
INTEL_LICENSE_FILE=C:\Program Files\Common Files\Intel\Licenses
LIB=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\LIB;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\lib\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\lib;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\
LOGONSERVER=\\NKIDD-DEV
MSVCDir=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program Files\Intel\VTune\CGGlbCache;C:\Program Files\Intel\VTune\Shared\Bin;C:\Program Files\Common Files\Intel\Shared Files\IDVC;C:\Program Files\Intel\VTune\Analyzer\Bin;C:\STAF\bin;C:\Documents and Settings\nkidd\Desktop\scripting\cs-script\lib;C:\Documents and Settings\nkidd\Desktop\scripting\cs-script;C:\Program Files\ParaSoft\Insure++\bin.Win32;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\doxygen\bin;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0207
ProgramFiles=C:\Program Files
PROMPT=$P$G
SESSIONNAME=Console
STAFCONVDIR=C:\STAF\codepage
SystemDrive=C:
SystemRoot=C:\WINDOWS
TCLLIBPATH=C:\STAF\bin
TEMP=C:\DOCUME~1\nkidd\LOCALS~1\Temp
TMP=C:\DOCUME~1\nkidd\LOCALS~1\Temp
USERDOMAIN=NKIDD-DEV
USERNAME=nkidd
USERPROFILE=C:\Documents and Settings\nkidd
VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio .NET 2003
VS71COMNTOOLS=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\
VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
VTUNE_GLOBAL_DIR=C:\Program Files\Intel\VTune\global_data\
windir=C:\WINDOWS
--- END ---
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You do not have C:\STAF\lib in your PATH. You only have C:\STAF\bin in your PATH. When running STAF from the directories where you have built STAF on Windows, you need to have both in your PATH. Note that result of STAF that you've built at this point is not the same as the version of STAF that gets packaged and then installed.
Please try adding C:\STAF\lib to your PATH environment variable before starting STAFProc.
Our STAF Windows build machine (and the machine where I build STAF) use Microsoft Visual C++ 6.0.
Registering external STAF services like Event and STAX do not require the STAFDSLS service.
You aren't merging your STAF directory that you installed in C:\STAF with the files that you built for STAF are you? That's not a good idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please explain why I can't merge the installed stuff with the built stuff (projects="staf connprov*"). While I certainly understand how problems arise when mixing compiled binaries with different source code revisions, I am confused as to why using binaries built from unmodified v3.1.0 source will cause problems. Are the binaries signed to prevent mismatched versioning? I want to rely on the official binaries as much as possible. I don't want to rebuild something that I'm not changing.
As for running the built stuff, STAFDSLS loads successfully. However the Event and EventManager fail to load. I copied JSTAF*.* from the original install directory and my original /services directory, and I got an "unable to connect to JVM". The odd thing is that if I type "java -version" from the command-line, I successfully get my java version of build 1.5.0_05-b05.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sharon may have more to add, but from my point of view, the primary thing to be careful of is doing a direct copy of the "rel" tree on top of an existing STAF installation, particularly on Windows. The "rel" tree isn't organized like the install directory, so your environment settings might not be configured correctly, and you might be picking up a mix of our binaries and the ones you built (more on that in a minute).
But, if you are being careful to copy files from the "rel" tree on top of the "install" tree, then you should be ok.
As far as mixing binaries, this may not be a big deal. The biggest problem area could be dependencies between shared libraries and executables. For example if you make a change in STAFProc.exe that also depends on a change in STAF.dll, but copy your "rel" STAF.dll to the wrong place in the install tree, then you could end up picking up the "old" STAF.dll instead of your new one. Similar things could go wrong if you are changing compilation flags and such and/or intermixing binaries from different compiler levels.
As long as you are careful in what you do, you should be ok. Personally, I always do something like Sharon does when using "rel" output. I just set my settings to point to those binaries directly. That also has the side effect of leaving my "installed" STAF intact in case I want to make side-by-side comparisons (which is relatively easy to do since you can run multiple instances of STAF simultaneously as of STAF V3.0).
Now, given that STAFDSLS is working, you are probably in good shape. It would be worthwhile to try and do a HELP command on one of the services STAFDSLS is responsible for loading, such as the Log service. This way you can see if most things are working correctly.
With regards to your Java service problem, it seems to me like JSTAF is loading fine, it is just having a problem with the JVM itself. The first thing to check is to make sure that "java.exe" is in your path. If not, either add it to the path or point to it directly with the OPTION JVM=<fully qualified path of java.exe> option. The other thing to look in is the STAF JVM log. Given default settings, this will be the data/STAF/lang/java/jvm/STAFJVM1/JVMLog.1 file. It may contain more data on why the JVM couldn't be found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The incompatibility errors that I seem to be facing have been resolved by building things on Visual Studio 6 Enterprise Edition. I compiled "staf connprov*" and copied STAFProc.exe by itself and everything
Therefore, I think it's safe to say that mixing binaries is fine so long as they were compiled with the same version of the compiler... I suspect it's really not the compiler per se, but rather the updated libraries that were used during linking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sharon: I pulled the HEAD today and succesfully built "staf connprov*" and verified that the PIDs are showing up as expected. Thanks for implementing this feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
STAF seems to expose only its own handle to manage processes launched using the Process service. I need to obtain the OS PID in order to perform some other things. I don't see that exposed in the API anywhere. Does anyone know how to get the PID for a process launched through a Process service call??
Currently, there is no way to do this. It doesn't seem like it would be too hard to add, so open a feature request (although, I can't guarantee any timeframe for implementation).
If the process you need to interact with can help out, then it could set a STAF variable containing it's PID (e.g., Test/Handle/<Handle>/PID=<pid>).
This feature would be SUPER!
I downloaded the 3.1.0 source and tried building in cygwin/win32 so I could hack my a local version in the meantime. (At a cursory glance, it seems that the only things that really need to change is STAFProc's implementation of fProcessInfoMapClass, fListProcessMapClass, and fListLongProcessMapClass need an additional key for the PID. )
Unfortunately i can't seem to get things built from staf/makefile, due to a variety of reasons (e.g. cygwin installing stuff to paths that don't match makefile, rexx and tcl are not installed, etc.)
I did manage to get STAFProc compiled by itself in Visual Studio, but I get a "STAFSERVICELOADER1 fails to initialize" message at startup. My project uses the files listed in the makefile.staf and I link against STAF.lib, so I suspect it's something really basic that I'm missing. Any ideas on what's going on?
You should be able to get around the service loader initialization failure by commenting out that line in the STAF.cfg (the one with STAFDSLS).
As for building STAF on Windows, let's just say things are a little picky. Given that you have visual studio set up, we should be able to get things working for you.
First things first... read the STAF Developer's Guide (if you haven't already) as it gives you details on what (environment) variables need to be set up (and other details) in order to build STAF. You may also want/need to looking build/makefile.mvc to verfiy you have your compiler path settings defined correctly (there are settings for various versions of the microsoft compilers). Hopefully, you won't need to actually change anything in build/makefile.mvc -- I'm pointing you there just as augmented documentation to what's in the STAF Developer's Guide.
I read the dev guide and I looked through makefile.win32 and makefile.mvc. I am using the source from STAF310-src.zip, to minimize the chance that my custom services linked against the existing binary of STAF.lib have issues.
When building under Visual Studio 2003, I included only c:\staf\bin\STAF.lib, LIBCPMTD.lib, and LIBCMTD.lib; this allowed successful linking. Including only the advapi32, user32, and wsock32 as seen in makefile.win32 resulted in linker errors. I managed to get STAFDSLS to load, but only by replacing references to gAnonymousString with a hard-coded "anonymous". (For some weird reason, gAnonymousString.buffer((void*)0) was returning a bad memory pointer.) Unfortunately getting STAFDSLS to load did not work for any of the other STAF services, like event, stax, etc. So, if any of this somehow sparks any insights as to how I'm screwing this up, I'm all ears. If not, oh well. I'm willing to accept that the attempt failed.
I gave cygwgin another shot, too. I defined the variables as described in the dev guide. In particular, used these settings: OS_NAME="win32", CC_TYPE="MVC7", MSVCDIR="C:/PROGRA~1/MICROS~2.NET", VSCOMMONDIR="C:/PROGRA~1/MICROS~2.NET/Common7", MSSDKDIR="C:/PROGRA~1/MICROS~2.NET/Vc7/PLATFO~1", BUILD_TYPE="retail", PROJECTS="staf connprov*".
The errors that I get are rather odd:
/cygdrive/c/src/staf/codepage/makefile.staf:42: /cygdrive/c/obj/win32/staf/retai
l/codepage/ucm2bin.d: No such file or directory
/cygdrive/c/src/staf/services/defaultsls/makefile.staf:39: /cygdrive/c/obj/win32
/staf/retail/services/defaultsls/STAFDefaultSLS.d: No such file or directory
/cygdrive/c/src/staf/services/log/makefile.staf:39: /cygdrive/c/obj/win32/staf/r
etail/services/log/STAFLogService.d: No such file or directory
-- errors continue, all of similar nature --
Any ideas what I'm doing wrong? I could find the object/win32/staf/retail dir, but the ..retail/codepage part wasn't there. I can find uc2mbin.cpp and a variety of other .cpp files. Is there a reason why the makefile is looking for .d files? Did I miss an environment variable somewhere?
For the heck of it, I tried using Microsoft's nmake, with zero success.
Those "errors" are expected. The ".d" files are dependency files. Make reports that they can't be found, and then uses one of our rules to generate them. At the bottom of that list of missing ".d" files, you should see the real error. My current guess would be that you don't have python installed as part of your cygwin setup. The program that generates the ".d" files is a python script, which is why you need to have python installed as part of cygwin.
As far as building natively in Visual Studio, I don't have any good advice, as I've never done that myself (for STAF).
On a positive note, Sharon, one of our developers, is trying to implement the feature to provide the PIDs for processes started with STAF. With any luck it will be in the STAF V3.1.1 release which should be released in the next week or so.
I'm glad that Sharon is working on the feature. I got things to build, but now I run into the exact same problem that I had in visual studio.
---
Caught unknown exception in HandleRequest()
Error initializing service loader service, STAFSERVICELOADER1, RC: 22, Result: E
rror initializing service, STAFDSLS, Result:
Caught unknown exception in main()
---
(sigh) I'd be content to wait, but my management actually wants me to get things building so that we can modify with the source *if* we ever need to. It's my full intention to rely on official releases as much as possible... this includes the feature for disabling DNS lookup. However, at work is a manager's innate reflex to minimize risks and reduce dependencies.
I graciously thank you for all your help, and I really do appreciate it. Please understand if it seems that I'm pestering on "wasted effort", it's because my job is asking me to. I have been on the implementation end of feature creep - so I do understand the cumulative effect of "little features" adding up to a lot of time.
fyi...I have completed Feature #1356848 "Get PID for process" and checked the updated files into CVS.
We would also like you to be able to build STAF so that you can contribute any bug fixes or features to the STAF project.
Are you sure that you have set up the environment variables to point to the appropriate directories where you built STAF before running STAFProc?
Add both the bin and lib directories to your path. For example, my STAF retail build directory is C:\dev\sf\rel\win32\staf\retail.
SET STAFDir=c:\dev\sf\rel\win32\staf\retail
SET PATH=%STAFDir%\bin;%STAFDir%\lib;%PATH%
SET CLASSPATH=%STAFDir%\lib\JSTAF.jar
SET STAFCONVDIR=%STAFDir%\codepage
cd \dev\sf\rel\win32\staf\retail
STAFProc
If that doesn't help, did you try comment out the default service loader line in the default STAF.cfg file? For example:
# Add default service loader
#serviceloader library STAFDSLS
If you're still having problems, paste the output from SET here (to show your environment variables that you're using when you run STAFProc from your STAF build tree).
I backed up my STAF install and I copied my build/res dir over it, and I still get an exception when attempting to load STAFDSLS. Given that all of the source is from v3.1.0, unless STAF requires that JSTAF be built at the same time as STAF.
I commented out STAFDSLS, but I get errors when initializing other services. I suppose it makes sense that I need the STAFDSLS for the Event and EventManager services.
The error that I'm getting seems identical to the problem encountered when building in the Visual Studio .NET 2003 IDE. Out of curiosity, which compiler did you use for your official Win32 release? If I need to, I can probably install that on a Virtual PC system and see if my version of Visual Studio is causing problems.
The output from SET appears at the bottom of the page.
--- SET ----
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\nkidd\Application Data
BISTRO_GLOBAL_CACHE_DIR=C:\Program Files\Intel\VTune\CGGlbCache
CLASSPATH=C:\Program Files\Intel\VTune\Analyzer\Bin;.;C:\STAF\bin\JSTAF.jar;C:\STAF\samples\demo\STAFDemo.jar
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=NKIDD-DEV
ComSpec=C:\WINDOWS\system32\cmd.exe
CSSCRIPT_DIR=C:\Documents and Settings\nkidd\Desktop\scripting\cs-script
DevEnvDir=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
FP_NO_HOST_CHECK=NO
FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework
FrameworkSDKDir=C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1
FrameworkVersion=v1.1.4322
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\nkidd
INCLUDE=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\INCLUDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\ INTEL_LICENSE_FILE=C:\Program Files\Common Files\Intel\Licenses
LIB=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\LIB;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\lib\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\lib;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\ LOGONSERVER=\\NKIDD-DEV
MSVCDir=C:\Program Files\Microsoft Visual Studio .NET 2003\VC7
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin\prerelease;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program Files\Intel\VTune\CGGlbCache;C:\Program Files\Intel\VTune\Shared\Bin;C:\Program Files\Common Files\Intel\Shared Files\IDVC;C:\Program Files\Intel\VTune\Analyzer\Bin;C:\STAF\bin;C:\Documents and Settings\nkidd\Desktop\scripting\cs-script\lib;C:\Documents and Settings\nkidd\Desktop\scripting\cs-script;C:\Program Files\ParaSoft\Insure++\bin.Win32;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\doxygen\bin;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0207
ProgramFiles=C:\Program Files
PROMPT=$P$G
SESSIONNAME=Console
STAFCONVDIR=C:\STAF\codepage
SystemDrive=C:
SystemRoot=C:\WINDOWS
TCLLIBPATH=C:\STAF\bin
TEMP=C:\DOCUME~1\nkidd\LOCALS~1\Temp
TMP=C:\DOCUME~1\nkidd\LOCALS~1\Temp
USERDOMAIN=NKIDD-DEV
USERNAME=nkidd
USERPROFILE=C:\Documents and Settings\nkidd
VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio .NET 2003
VS71COMNTOOLS=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\ VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
VTUNE_GLOBAL_DIR=C:\Program Files\Intel\VTune\global_data\ windir=C:\WINDOWS
--- END ---
You do not have C:\STAF\lib in your PATH. You only have C:\STAF\bin in your PATH. When running STAF from the directories where you have built STAF on Windows, you need to have both in your PATH. Note that result of STAF that you've built at this point is not the same as the version of STAF that gets packaged and then installed.
Please try adding C:\STAF\lib to your PATH environment variable before starting STAFProc.
Our STAF Windows build machine (and the machine where I build STAF) use Microsoft Visual C++ 6.0.
Registering external STAF services like Event and STAX do not require the STAFDSLS service.
You aren't merging your STAF directory that you installed in C:\STAF with the files that you built for STAF are you? That's not a good idea.
Please explain why I can't merge the installed stuff with the built stuff (projects="staf connprov*"). While I certainly understand how problems arise when mixing compiled binaries with different source code revisions, I am confused as to why using binaries built from unmodified v3.1.0 source will cause problems. Are the binaries signed to prevent mismatched versioning? I want to rely on the official binaries as much as possible. I don't want to rebuild something that I'm not changing.
As for running the built stuff, STAFDSLS loads successfully. However the Event and EventManager fail to load. I copied JSTAF*.* from the original install directory and my original /services directory, and I got an "unable to connect to JVM". The odd thing is that if I type "java -version" from the command-line, I successfully get my java version of build 1.5.0_05-b05.
Sharon may have more to add, but from my point of view, the primary thing to be careful of is doing a direct copy of the "rel" tree on top of an existing STAF installation, particularly on Windows. The "rel" tree isn't organized like the install directory, so your environment settings might not be configured correctly, and you might be picking up a mix of our binaries and the ones you built (more on that in a minute).
But, if you are being careful to copy files from the "rel" tree on top of the "install" tree, then you should be ok.
As far as mixing binaries, this may not be a big deal. The biggest problem area could be dependencies between shared libraries and executables. For example if you make a change in STAFProc.exe that also depends on a change in STAF.dll, but copy your "rel" STAF.dll to the wrong place in the install tree, then you could end up picking up the "old" STAF.dll instead of your new one. Similar things could go wrong if you are changing compilation flags and such and/or intermixing binaries from different compiler levels.
As long as you are careful in what you do, you should be ok. Personally, I always do something like Sharon does when using "rel" output. I just set my settings to point to those binaries directly. That also has the side effect of leaving my "installed" STAF intact in case I want to make side-by-side comparisons (which is relatively easy to do since you can run multiple instances of STAF simultaneously as of STAF V3.0).
Now, given that STAFDSLS is working, you are probably in good shape. It would be worthwhile to try and do a HELP command on one of the services STAFDSLS is responsible for loading, such as the Log service. This way you can see if most things are working correctly.
With regards to your Java service problem, it seems to me like JSTAF is loading fine, it is just having a problem with the JVM itself. The first thing to check is to make sure that "java.exe" is in your path. If not, either add it to the path or point to it directly with the OPTION JVM=<fully qualified path of java.exe> option. The other thing to look in is the STAF JVM log. Given default settings, this will be the data/STAF/lang/java/jvm/STAFJVM1/JVMLog.1 file. It may contain more data on why the JVM couldn't be found.
The incompatibility errors that I seem to be facing have been resolved by building things on Visual Studio 6 Enterprise Edition. I compiled "staf connprov*" and copied STAFProc.exe by itself and everything
Therefore, I think it's safe to say that mixing binaries is fine so long as they were compiled with the same version of the compiler... I suspect it's really not the compiler per se, but rather the updated libraries that were used during linking.
Sharon: I pulled the HEAD today and succesfully built "staf connprov*" and verified that the PIDs are showing up as expected. Thanks for implementing this feature.