ExtraView with WebLogic

WebLogic from Oracle is an alternative application server to Apache Tomcat, and ExtraView Corporation supports its use with ExtraView. This support extends to using WebLogic in a clustered environment. The WebLogic software must be licensed directly from Oracle. If you want to access the code by download from Oracle, visit http://www.oracle.com. ExtraView Corp assumes that you have expertise in installing and configuring WebLogic. Support for this installation is from Oracle, not ExtraView. The following is just a brief guide of the key points to watch for. We suggest you install a reference system first, and then migrate this to your corporate environment. There is no need for multiple instances of the same servlet to be initiated in a single WebLogic container, and we do NOT want any of the following WebLogic behaviors to be configured:

  • Dynamic reloading of the servlet
  • Session migration from one servlet/WebLogic instance to another; we require sticky sessions
  • SingleThreadModel behavior (the ExtraView servlet does NOT implement SingleThreadModel)
  • Automatic shutdown of the servlet except by administrator command
  • EJB or other bean processing (ExtraView does not use beans)
  • WL Connection pool; ExtraView maintains its own connection pool
  • WL JDBC; ExtraView should only use versions of JDBC software that have been qualified with ExtraView
  • Specific EAR behaviors; ExtraView runs with WAR’s and exploded class directories and does not expect or use any features related to EAR packaging

If you want to install with EAR’s LDAP and / or SSO, it is strongly suggested that you install and verify the standard installation, then move to configure these components. Please consult the full installation instructions available with WebLogic. A short synopsis of these instructions that will install WebLogic as a reference system follows:

Task Recommended response
Create WebLogic Home c:beaxxx for the Windows platform
Install Custom Just install the WeblogicServer. Do not install the Weblogic Workshop. Do not install the service
Configuration Wizard Run the configuration wizard to make a user_project. This example shows the creation of a user project named ev in user_projects. Start the Configuration Wizard. myserver SvrA SvrB
  1. Create new WebLogic Configuration (This will end up under user_projects)
  2. Basic WebLogic domain
  3. Custom
  4. name=myserver port=7001
  5. Yes to add managed servers
  6. Press add In the name field enter SvrA, port field enter 7010 Press add In the name field enter SvrB, port field enter 7020
  7. Press next NO Clusters Added
  8. Press Add for the add machine option name = myMachine
  9. Add all the servers to myMachine since all the servers are on this physical machine
  10. No JDBC options
  11. NO JMS options
  12. Add an admin password
  13. Add to shortcut (optional) No to add service
  14. Browse to your own Java installation. ExtraView strongly recommends using a Java installation you install, as opposed to the default installation provided with WebLogic. d:javajava_150_14
  15. Configuration name ev (or whatever user_project/name you selected)
Optional Configuration If you are planning for a database with hundreds of thousands, or more, issues, it is worth increasing the default value of the Weblogic parameter WLIOTimeoutSecs from the default value of 300 seconds to something like 1500 seconds.
 
Create startSvrA.cmd In the user_projects/ev directory create a startup file as required for WebLogic. This script is specific to WebLogic and ExtraView assumes you have the expertise to create this script.
   

Once you have the basic installation with WebLogic configured, you can migrate the system to your working environment. This is fairly simple if it is done one step at a time. If you are using a single corporate database server, this server is prepared with ExtraView scripts and the database imported from the reference site; the corporate application server then is pointed to the corporate database. Again, a short acceptance test should confirm that everything is still working correctly. Now, extras such as LDAP and SSO can be enabled, preferably one feature at a time. When the system fails, you need only step back to the prior step to get it working again, then move forward more slowly or debug what changed in the latest step because the variables are fairly isolated. During this entire time, you may revert to the reference system to see what the "correct" behavior looks like in comparison to the system under installation.