To start a WLP server as a Windows service it is simplest to make your own script based on the provided standard script located at WL_HOMEserverbininstallSvc.cmd. The standard script works fine for a plain WLS domain, but lacks some classpath and options necessary for WLP.

Start by making a copy of the installSvc.cmd script and naming it something specific to your domain.

Next, just under SETLOCAL you will find where WL_HOME is defined. Here you will add the definitions you would normally add in a script that later calls installSvc.cmd (as per the standard documentation).

set DOMAIN_NAME=gnma_test_domain
set USERDOMAIN_HOME=D:my_test_domain
set SERVER_NAME=AdminServer
set WLS_USER=weblogic
set WLS_PW=gnmaAdmin01
set PRODUCTION_MODE=true
set MEM_ARGS=-Xms512m –Xmx512m
set MW_HOME=C:OracleMiddleware

Note: I had heard of people using this approach who had issues with the length of the command line. This may be due to their use of the default domain path. In the example above, I use a shorter path.

At this point, edit the DOMAIN_HOMEbinstartWebLogic.cmd and set it to echo both the classpath and the options. Then start the domain and capture the output of those echoes, then shut the domain back down. Now REM out the existing CLASSPATH definition, then use the outputs you captured earlier to set the CLASSPATH and JAVA_OPTIONS like this:

REM set CLASSPATH=%WEBLOGIC_CLASSPATH%;%CLASSPATH%;
set CLASSPATH=%MW_HOME%patch_wls1034profilesdefault...
[REMAINING CLASSPATH SNIPPED TO FIT]

set JAVA_OPTIONS= -Xverify:none  -ea -da:com.bea...
[REMAINING CLASSPATH SNIPPED TO FIT]

Note that all absolute paths have been replaced with the definitions created earlier to keep the length down and make the script more portable. You should definitely make your own version rather than copying the above. If you do copy the above, be careful of extra spaces and carriage returns used for formatting this blog entry.

Finally, before the ENDLOCAL, add an uninstall line for later use:

rem call "%WL_HOME%serverbinuninstallSvc.cmd"

And that’s it. Looks really simple, but it took me quite some time to gather all the necessary pieces in order to make it work. Hopefully you find this before you went through half as much research.

The example here uses a domain with only the Admin server and no managed servers. For a variety of reasons I only want the Admin server to be run as a service. The standard documentation along with the example above should allow you to expand this to include managed servers should you feel the need.

© Scott S. Nelson

Recently I was working on code to manage roles in WLP. WLP roles can be at the global, enterprise application, or web application scope and I needed it at the enterprise application scope because these roles were for use with the content repository.  However, I could only find examples for the web application scope, which generally looked like this:

RolePolicyManager rpm = new RolePolicyManager();
RolePolicyItem rpi = new RolePolicyItem();
rpi.setEntAppName("testTT");
rpi.setWebAppName("ProducerWEB");
rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);
rpi.setPolicyName("myTestPolicy");
ArrayList a = new ArrayList();
a.add("testUser");
rpi.setUserList(a);
rpm.createRolePolicy(rpi);

From that example, I would assume that changing

rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);

to

rpi.setResourceScope(
   EntitlementConstants.ENT_APP_ROLE_INHERITANCE);

would be sufficient. Alas, it wasn’t. The role was still created at the web application level. So, being clever, I removed

rpi.setWebAppName("ProducerWEB");

which had an interesting result. The role was created at the Enterprise Application scope, but only in the RDBMS, not in LDAP and, consequently, not in the Portal Admin Console. For someone in a hurry this might be acceptable as the role could be managed from code. And, while in a hurry, I had the long view that these roles would also need to be managed from Portal Admin Console, so don’t ask me if the role actually worked for entitling when out of sync as I never tested it.

To make a long story short (probably too late for some), I contacted support, who in turn opened a bug. The response from engineering was that the WebAppName had to remain, and that one more piece was required:

rpi.setPolicyUser(
   EntitlementConstants.P13N_APPLICATION_POLICY);

And that did the trick. I looked up the documentation for com.bea.p13n.entitlements.policy.RolePolicyItem and found the setPolicyUser method listed in the parent class, though found no reference as to its value, nor did I find a getter for the attribute, so I don’t believe it was something I missed, just one of those undocumented features that are handy to know about.

© Scott S. Nelson