Wednesday, August 27, 2008

Generalization and Specialization

At some stages in life, you will suddenly have a desire to do a turn-around in your career, whether to continue specializing something or generalizing to handle more tasks. Face it, people who are specialized in an area for ages will have difficulties in adapting to the idea of multi-area + multi-process + multi-tasking. The same happened for generalized worker, they might have phobia of scaring entering a job dead-end or ceasing of learning curve. Anyway, ignore what I had said, these are just crappy murmuring.

Here's the meat. There are reasons why you need certified and well trained personnel to deploy your applications into production environments. One of it is that they always got some well-kept secrets that make them different from typical persons who try to be hero or force to be. For the sake of goodness of your enterprise, pay whatever that is necessary to get the job done properly. Cheapskate is not the way to survive.

Like thousands of others outside, me as a generic person, sometimes need to do stuff i'm not good at (or at least not at the current moment). Last week, I setup a Websphere Application Server in a machine which is Windows domain member. Naively, I just do whatever I did in the company test environment, thought it will turns on and run flawlessly. Well, most of the features do.

I had this problem of obtaining list of Windows groups and users from the LocalOS registry when try to map security roles in the deployed applications. WAS smartly returned me "*null" message on the screen and some "User not found" or "Not authorized" or "Password something" in the logs.

Stratching my nearly bald head and suspecting something to do with Windows domain, I look up the WAS 6 information center, and search for LocalOS registry. The fact is that WAS has different setting requirements for standalone machine, domain member and domain controller if you are using LocalOS.

A quick fix will be to add "com.ibm.websphere.registry.UseRegistry" custom property with the value "local" to the LocalOS custom property sheet. This will explicitly stop the WAS from querying domain registry for list of groups and users (That's my requirement, your's might be different). If you want it to get the list from both domain and local registry, then read on the documentation, there are a list of things to set up for the user who starts WAS process.

This is just one issue that I encountered so far, however just cross my finger and hopes there are no others.


The risks of being not specialized.

No comments: