*All the random domains/URLs used here are setup on a private, local network for testing HelloWorld programs! So please don't try accessing any of them over the internet! :-)
OS: Linux / Fedora Release 12 / 64bit
WebLogic 10.3.2.0
JDK: Sun JDK 1.6.0_18
I assume that you already have WebLogic (and a JDK) installed at this point and now just need to setup a working instance to deploy applications etc. I've seen a lot of times where the server that runs the WLS Admin console is also used to host other applications as well rather than keep them separated because it's an easy setup. This can work, of course, but isn't a good idea for a few reasons:
- Eventually when you do need to run the applications in a distributed environment, it's not easy when your application sits on the same server as the Admin Server and you need to manage multiple instances, clusters, servers etc.
- Shutting down the server hosting the application will shut down the Admin Server as well
- It's better for application errors/exceptions, memory issues etc. in the application be restricted to the WebLogic server instance hosting the application alone rather than take down the WLS Admin console with it.
Ideally, it's nice to set it up this way (even in development):
- Admin Server: Leave this alone to manage all your WLS instances, servers, deployments, clusters etc.
- Managed Server(s): Should be a dummy node just reporting information back to home base (Admin Server) and do what it's supposed to do - serve up applications that you deploy on it.
I wanted to post this to show that it can be just as easy to setup WebLogic with a separate server for Administration and a separate Managed Server to host your application. This way you build and deploy applications in a distributed way on WLS right from the start.
In my setup, I have it installed under
/usr/local/oracle/middleware/weblogic
Change your current working directory to where the WebLogic Server configuration script is located
cd /usr/local/oracle/middleware/weblogic/common/bin
Launch the Configuration Wizard and the first couple of screens should be self-explanatory.
./config.sh
The "Advanced Web Services Extension" is optional. I've enabled it for now. This typically just adds resources and services for Web Service development in the WLS domain - like adding a JMS queue in the default JMS etc.
In the following screen, make sure "Managed Servers, Clusters and Machines" is also selected. This will help setup the initial
Managed Server separate from the
Admin Server
The next screen basically asks for which ports the Admin Server will listen on.
You don't
have to enable SSL here. It's just that I like having my development environment have "Production-like" environment settings so I can resolve any issues that might show up in a live system right from the start. There's no harm in setting up SSL at this point either - WLS just uses a sample certificate for SSL which is not trusted by an authorized CA (Certification Authority). I'll cover how to set this up in a later post.
This screen is usually the one left blank most of the time when the Admin Server (configured above) also double as the server where applications are deployed (not a good idea). You can click on "Add" and have as many Managed Servers as you'd like here. In a real-world scenario, these will probably have separate physical/virtual servers of their own. Yes - I've got SSL on this too :-)
We are not setting up a cluster in this exercise. Clusters are useful when you have multiple (as in more than one!) managed servers. We just have one here - so no need for a cluster setup.
Node managers are used to
easily manage WLS servers across multiple servers. Once this is setup, you can remote start/stop servers from just your Admin Server and much more. Again, we just have one Admin and one Managed server in this exercise - so we don't need to set this up.
You can see in the summary that there's a nice, clean, separate setup of Admin and Managed Server.
Ok. So at this point, we have everything ready. Next step: Turn on the new WLS instances and see if they work. The directory that contains this new setup will be at
/usr/local/oracle/middleware/user_projects/domains/GeneralDomain/ or similar.
Note: You do
NOT need to start the servers in the sequence described below. Eventually, once you complete development and deployment of your application, all you will (hopefully) need to do is just start the Managed Server to serve up your application. Starting up the Admin Server would be done a few times when you need to administer the servers or applications etc.
From a command prompt, change your current working directory to where all the start up scripts for the new domain are located.
cd /usr/local/oracle/middleware/user_projects/domains/GeneralDomain/bin
Starting the Admin Server
./startWebLogic.sh
You'll see a log messages scrolling on screen. Ignore any security notices about trusted certificates - all this is because SSL is enabled and we don't have a valid CA certificate deployed yet. Wait till you see something like this which indicates that the server has started up:
Server started in RUNNING mode
Starting the Managed Server
Start up another terminal window and navigate to the same directory as above. Then run the following command.
./startManagedWebLogic.sh ManagedServer http://hostname:7001
The
hostname:port would be that of your Admin Server. Again, you will see a lot of log messages scrolling. You will also get prompted for the Username/Password you would use to boot up the server (This should be the same as what you entered during configuration above)
Enter username to boot WebLogic server:weblogic
Enter password to boot WebLogic server:
...
Server started in RUNNING mode
You might see a warning (not an error) similar to:
Unable to find a WorkManager with name weblogic.wsee.mdb.DispatchPolicy. Dispatch policy weblogic.wsee.mdb.DispatchPolicy will map to the default WorkManager for the application bea_wls9_async_response
The WebLogic documentation indicates that it can be ignored (of course). But like many of us, I'm sure we want to get to the bottom of these things! Work Managers are classes/modules that help a WebLogic server manage it's work (d-uh). It is deployed on the Admin Server by default - but not on any Managed Servers. My thought is if it something is NOT deployed on a Managed Server (that too on a clean install with nothing on it yet), then why should the Managed Server reference it? Anyway, I do have a workaround (covered below) to make this annoyance go away - but I'm still trying to find out what this is all about. If you know - let me know!
Anyway, at this point:
- hostname:7001 is where the Admin Server is listening for requests
- hostname:7002 is the secure port where the Admin Server is listening for requests
- hostname:7003 is where the Managed Server is listening for requests
- hostname:7004 is the secure port where the Managed Server is listening for requests
Access the WebLogic Administration console: Open a web browser and navigate to
http://hostname:7001/console
NOTE: "console" itself is a web application that hosted on the Admin Server
You will get a screen as below.
Once logged in, navigate to
Servers and you should see the newly setup servers up and running.
Now, to fix the
Unable to find a WorkManager with name weblogic.wsee.mdb.DispatchPolicy.... warning that shows up during start up of the Managed Server.
In the WebLogic Admin console, navigate to
Work Managers. You should see the
weblogic.wsee.mdb.DispatchPolicy Work Manager configured. Click on it and then click on "
Targets" and basically assign this Work Manager to the Managed Server as well and click "
Save".
You should not see these messages anymore on start up.
