It took me a while to figure out, so here is a solution to this issue: Problem: after an upgrade (or rather uninstall/install) of an MQSeries Queue Manager to Version 8.0.0, my C application suddenly complains about being not authorized:
Now, the issue, it seems is that with MQ Verson 8, by default, the administrator must have user id and password set if he uses the MQ Client connection. I'm not here to judge, but you should read this
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'apodehl' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
Solution: be aware of the security implications, but you can change this authentication in the WebSphere MQ Explorer -> QM1 -> Authentication Information, choose SYSTEM...IDPWOS and set "Check client connections" to be "None" instead of 'Required for Adminstrators'
2. Change activemq.bat startup script to specify an explicit password files:
set SUNJMX=-Dcom.sun.management.jmxremote.port=1098 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=%ACTIVEMQ_BASE%/conf/jmx.password -Dcom.sun.management.jmxremote.access.file=%ACTIVEMQ_BASE%/conf/jmx.access
when you start ActiveMQ, you will probably get this error now:
> activemq.bat
Error: Password file read access must be restricted: .../conf/jmx.password
ActiveMQ requires the password file to have specific user-only permissions, see here for more information. Unfortunately this link is for Windows XP, so here's what to do on Windows 7
I've actually found two solutions, one graphical, the other one from the command line:
Solution (using Windows Explorer):
1) change the owner to be 'you' (required step!!)
Select jmx.password, Right-Mouse-Cick -> Properties -> Security -> Advanced -> Owner -> Edit
and select the single owner of this to be your username. Note: you need to click OK and exit out of Properties for this to be effective
2) Select jmx.password, Right-Mouse-Cick -> Properties -> Security -> Advanced -> Change Permissions - uncheck "Include inheritable permissions" and click Remove to remove all inherited permissions - then click Add... to add read/write permissions for only your user: Enter your username as object name, and select for example 'Full Control'. Click Ok and exit out of properties.
Solution (using Windows command line):
1) open a windows command prompt in your ActiveMQ 'conf' folder.
2) use icacls (run 'icacls' without options for help) to change the owner to be 'you', in my case:
icacls jmx.password /setowner apodehl
3) remove all inherited permissions:
icacls jmx.password /inheritance:r
4) grant minimal permissions to your user (read/write in this case):
Test the I/O performance by writing several messages to the current directory
The files created are named writetest..dat and should be removed after the test !!
Usage: writetest
Will write buffers of size each and print the rate every msgs.
The test is repeated times and the used time is displayed
Example: writetest async 1000000 100000 100 1
void _testWrite( int cnt, int nummsgs, int printrate, int msgsize )
{
char filename[30];
int msgCount;
int fd;
sprintf( filename, "writetest.%d.dat", cnt );
int oflags = O_RDWR | O_CREAT;
#ifdef WIN32
int pmode = _S_IREAD | _S_IWRITE;
#else
// this flag exists only on Unix
if( isSync==1 ) oflags = oflags | O_SYNC;
mode_t pmode = S_IRUSR | S_IWUSR;
#endif
fd = open( filename, oflags, pmode );
if( fd==-1 ) {
fprintf( stderr, "writetest: Could not create file %s, maybe you did not remove a former instance ?\n", filename );
exit(1);
}
#ifdef WIN32
// flush every message if sync writing (Windows NT only)
if( isSync==1 ) _commit(fd);
#endif
}
close(fd);
mt.stop( msgCount );
}
void usage()
{
fprintf(stderr,"Test the I/O performance by writing several messages to the current directory\n");
fprintf(stderr,"The files created are named writetest..dat and should be removed after the test !!\n\n");
fprintf(stderr,"Usage: writetest \n");
fprintf(stderr," Will write buffers of size each and print the rate every msgs.\n");
fprintf(stderr," The test is repeated times and the used time is displayed\n");
fprintf(stderr,"Example: writetest async 1000000 100000 100 1\n");
exit(1);
}
int nummsgs = atoi(argv[2]); // number of messages to write
int printrate = atoi(argv[3]); // number of tests to run
int msgsize = atoi(argv[4]); // length of the message to write in bytes
int numtests = atoi(argv[5]); // number of tests to run
if( msgsize > sizeof(buffer) ) {
fprintf(stderr,"writetest: msgsize can not be bigger than %ld\n", sizeof(buffer) );
exit(1);
}
When using the JDBC-ODBC bridge in the JDK to access Microsoft Access files, you would set your JDBC class to sun.jdbc.odbc.JdbcOdbcDriver and your JDBC URL, for example, to:
So far so good, but in case you are running a 64-bit JVM with a 32-bit Microsoft Office installation, your JVM and Access driver architecture don't match and you would see error messages such as:
java.sql.SQLException: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
or
"The setup routines for the Microsoft Access Driver .. could not be found."
Fortunately, there are now 64-bit Microsoft Access drivers available, but using them in this context is quite tricky. Once you install the drivers, Microsoft Office stops working ! Opening an Excel file, for example, tries to find the 64-bit version of Office, which you don't have :-( Instead of opening a file, you will see "Configuration Progress" and "Configuring Microsoft Office Professional Plus 2010..." - what the heck ?
But there's a neat little workaround which goes like this: 1. Download the Microsoft Access drivers 2. Check this registry key:
If if currently contains an entry with mso.dll, you are using Office 64-bit, which is ok. If there is NO mso.dll keythen your Office version is 32-bit. 3. Open a command prompt and install the 64-bit driver in passive mode (it won't let you do this any other way):
AccessDatabaseEngine_X64.exe /passive
4. If mso.dll was not in your registry in step 2, then remove this key now from
Eclipse as Java IDE is great. But there's (at least) one part of the GUI that's a bit cumbersome. One thing that frequently pops up is the problem of not finding a native library.
For example if you use TIBCO Rendezvous, your project uses a tibrvj.jar file which is dependent on a native libary, for example tibrv.dll on Windows. Of course you can solve this by setting a Run Configurations 'VM argument' to -Djava.library.path=. But if you have many Run configurations, for example because you write JUnit tests around your software, it would be a pain to configure java.library.path for every JUnit Run Configuration.
You would think you can do Project -> Properties -> 'default java library path' - or so.
Or maybe Windows -> Preferences -> 'default VM arguments'. But neither exists :-(
That's the part where I say the GUI design of Eclipse could be improved: it's not quite obvious that you can actually edit properties of a jar file in 'Referenced Libraries'. You add jar files and they look like non-editable references to files. But you can actually change some properties.
Select your jar file and do a right-mouse-click:
In this dialog you can specify the path to a dependent native library which is then added to your java.library.path for every existing and future Run Configuration of this project.
Another interesting jar-file setting is the 'Javadoc Location'. Once you specified the path to a Javadoc's index.htm, the online documentation will be available when you program against that API (IntelliSense and F2 work). For TIBCO Rendezvous however, there's no real Javadoc part of the product.
Please note, though, that when you upgrade to another version of the jar file, these jar-file settings are lost. You have to repeat the steps above. It would be nice from Eclipse to be asked whether to keep Javadoc Location/Native Library settings when upgrading a jar file.
After a crash on Windows 7, my beloved Eclipse environment wouldn't start again!
It just hung there, showing nothing but the Splash screen.
eclipse -clean didn't help, monitoring files with Sysinternal's ProcMon or 'handle.exe' didn't help - quite devastating...
But finally I found the solution here:
cd to your Eclipse home directory
cd .metadata/.plugins
ren org.eclipse.core.resources BAK (Keep this directory around)
Restart Eclipse, ignore the error message.
Close all open editors tabs !! (in my case, playing with the .xsd file editor caused the issue)
Exit Eclipse.
del org.eclipse.core.resources (Delete the newly created directory.)
ren BAK org.eclipse.core.resources (Restore the original directory.)