Terminology: Weblogic Managed Server and JVMs

Terminology: Weblogic Managed Server and JVMs

A Domain can include multiple WebLogic Server instances. A minimal domain contains only one WebLogic Server instance, which functions both as an Administration Server and as a Managed server—such a domain can be useful while developing applications, but is not recommended for use in a production environment.

A Managed Server is a WebLogic Server instance that runs deployed applications. It refers to the Administration Server for all of its configuration and deployment information. Usually, you use Managed Servers to run applications in a production environment.

Each Managed Server runs on its own JVM.  Admin Server also runs in a different JVM.

A Managed Server retrieves its configuration data from the domain's Administration Server. There can be many Managed Servers in a domain, but only one Administration Server. Usually, you create and start server instances as Managed Servers to run your business applications in a production environment. In this standard scenario, the server instance that you start as the Administration Server does not run business applications. Instead, it only manages resources in the domain. To improve reliability and performance, you can install the WebLogic Server software on several computers and run the servers that you create on the various WebLogic Server hosts.

The first server instance that you start in a domain always functions as the Administration Server. If you start additional servers in a domain, you must start them as Managed Servers.

	Node Manager is a Java utility that runs as separate process from WebLogic Server and allows you to perform common operations tasks for a Managed Server, regardless of its location with respect to its Administration Server.

Debugging a remote application in Eclipse

 Debugging a remote application in Eclipse

I have the source code of a web application in my local Eclipse. While this application is running remotely on the server, can I debug the remote application using my local Eclipse?

Yes, You Can.



How do I debug a remote application in Eclipse?

Refer to this link:
http://www.eclipsezone.com/eclipse/forums/t53459.html

In Summary:

(1)Set Java Debugger in the launch of the application server and restart the server. This is to enable the app server to run in debug mode.

The default JPDA options for J2EE servers are as follows:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000

Adding the above into the server start up screen in Weblogic server console, or add them into weblogic server start up command.
Then restart the server. This would enable WebLogic instance to be running in debug mode.

(2)Go to Eclipse,go to Run | Debug, and Create new Remote Java Application configuration in Eclipse
For Host , enter localhost. To debug a remote server, enter its hostname or IP address. For port, enter 4000 or the port you defined in your WebLogic startup script. click "okay".

Go to "Debug" perspective, set trace points, and rock and roll!

Oracle 11g Portal: Deploy a Portal Page Filter to achieve a certain look and feel

Oracle Portal 11G

Deploy a Portal Page Filter to achieve a certain look and feel

Our client had rigid requirements on a common look and feel for the portal pages. In order to achieve that, we have developed a servlet filter, which works on the servlet responses. The servlet filter program is packaged into 2 jars:
..Filter.jar containing the filter java, regx code
..Antl.jar containing the required libraries

Where should this page filter jars be deployed?
We have 3 servers in our Oracle Portal Midtier:
(1)Admin Server
(2)WLS_Portal, where Oracle Portal 11g is deployed. This server is installed and configured via Oracle Fusion Middleware 11G installer.
(3)WLS_WSRP, where our portlets are deployed and hosted; serves as a WSRP producer.

The filter should be deployed onto (2)WLS_Portal server.

How could we deploy this filter jars?
In the oc4j (the old Oracle appServer) world, we can simply place the two filter jars under the proper WEB_INF/lib inside Oracle Portal, and update the web.xml (under WEB_INF) to include necessary filter definition, and under want conditions the filter program should work.

In the Oracle Portal 11g (deployed on WLS 10.3.6 server), placing the two jars and web.xml under some WEB_INF folder (under userdomain/users_project/server/tmp/.../WEB_INF) did not work.

Note that Oracle Portal application (the 11g portal) is deployed in WLS_Portal server. Oracle Portal 11G does not have an elegant solution for handling this situation. Oracle Portal Webcenter does.

(1)We first copied the entire Portal server into a backup folder.
(2)We then exploded the Portal.ear and the *.war inside into folder: oracle/portal/portal.ear
(3)We then added the 2 filter jars into the WEB_INF/lib of the expended portal.ear; and updated web.xml under WEB_INF

We then restarted WLS_Portal sever. It did not work, some error upon starting of the WLS_Portal server.

We then release that by re-deploying the Portal app, some configuration that linked the Portal app with the rest of the environment were lost.

We then copied over the four configure files from our WLS_Portal backup. and restarted WLS_Portal. It worked!

Then I thought of another more elegant way of deploying this filter into the Oracle Portal. This will be discussed in a later post.

commons logging API and weblogic logging

How to retrofit the logging of an OC4j based app into running under weblogic 10.3.6?

There are two basic components in any logging system: a component that produces log messages and another component to distribute (publish) messages. WebLogic Server subsystems use a message catalog feature to produce messages and the Java Logging APIs to distribute them, by default.


Logging mechanism provided by weblogic:
(1) Using the I18N Message Catalog Framework: the message catalog framework is used when there is a need for internationalization
(2) Using the NonCatalogLogger APIs: Used when no need to internationalize
(3) Server Logging Bridge
Used for Apps useing other logging mechanism, and have its messages redirected to WebLogic logging services without the need to make code changes or implement any of the propriety WebLogic Logging APIs

Our application are in the (3) category.

The Jakarta Commons Logging APIs define a factory API to get a Logger reference which dispatches log requests to the server Logger object.
The server Logger object can be an instance of java.util.logging.Logger or org.apache.log4j.Logger. We are using log4j logger. From our code, the import package shows that.


Best Practices: Integrating Java Logging or Log4j with WebLogic Logging Services

• If your application is configured for Java Logging or Log4j, in order to publish application events using WebLogic logging services, you can do either of the following:
• (Recommended) Configure your application's logger to use the Server Logging Bridge, which provides a lightweight means for your application's log messages to be redirected to WebLogic logging services without requiring any code changes. For more information, see Server Logging Bridge.
• Create a custom handler or appender that relays the application events to WebLogic logging services using programmatic API. For information, see How to Use Log4j with WebLogic Logging Services.

We can let app logs integrated into Weblogic server logs, at the same time, also output them to separate log4j log file. The drawback is that it may negatively impact the performance.

common-logging has a few implementations:
(1) Java JDK implementation (it is bundled after java 1.3 ): some perceive this as an inferior implementation than log4j. basic
(2) Log4j implementation
The Jakarta Commons Logging APIs provide an abstraction layer that insulates users from the underlying logging implementation, which can be Log4j or Java Logging APIs.
WebLogic Server provides an implementation of the Commons LogFactory interface, letting you issue requests to the server Logger using this API.

WebLogic Server supports Java based logging by default. The LoggingHelper class provides access to the java.util.logging.Logger object used for server logging. This lets developers take advantage of the Java Logging APIs to add custom handlers, filters, and formatters. See the java.util.logging API documentation at http://download.oracle.com/javase/6/docs/api/java/util/logging/package-summary.html.

Things to do to retro fit our application into weblogic logging :
(1) Set up the bridge in log4j.properties so that the log4j logs can be directed to weblogic server logging. This can also be done by
Setting “Logging Bridge Uses Parent Loggers” at the admin console configuration .
(2) Include log4j configuration, and the change to the build.xml to rebuild to ensure putting log4j.xml or log4j.properties to be under "classes" folder. Redeploy.
(3) Check server logs: Search log4j to confirm log4j subsystem is initialized.
(4) Check our config.xml to see whether there are already log4j configurations there. Some say this may superseds log4j.properties. If there are, remove them. Use log4j.properties instead. The new 11g weblogic doc did not mention config.xml.
(5) Need to do one of the following:
To specify logging to a Log4j Logger instead of the default Java Logging:
 When you start the Administration Server, include the following Java option in the weblogic.Server command:
-Dweblogic.log.Log4jLoggingEnabled=true
Or:
After the Administration Server has started, use the Administration Console to specify the Log4j logging implementation. See "Specifying the Logging Implementation" in the Administration Console Online Help.


Admin console logging configuration for Weblogic 10.3.6 (oracle fusion 11g):
http://docs.tpu.ru/docs/oracle/en/fmw/11.1.1.6.0/apirefs.1111/e13952/pagehelp/Corecoreserverserverlogginggeneraltitle.html


This is also a nice blog article on log4j and weblogic:
http://ananthkannan.blogspot.ca/2009/09/how-to-configure-log4j-in-weblogic.html

-------------------------------------------------------------------------------------
The following is from weblogic older version reference, not sure if they still apply.

Need to check config.xml, and still need to include log4j configuration if want app to use log4j logging.



http://stackoverflow.com/questions/576937/using-log4j-logging-in-weblogic-9-10

Difference between Servlet Config and Servlet Context

 Difference between Servlet Config and Servlet Context

Yes, they are extremely basic.

ServletConfig - parameter scope is limited to the scope of the servlet in which the parameter is defined. For example, shopping cart of a user is specific to a particular user so servletconfig params can be used.

ServletContext - parameter scope is application wide and the parameter can be use to store application session info/ application initialization parameters,etc not specific to a servlet.

Actually the servlet container will create ServletConfig object and pass it to the servlet when it's initialized. Servlet container does object creation for other interface types HTTP request, response etc.

ServletConfig has servlet wide scope. It is defined inside in web.xml

ServletContext has application wide scope . It is defined outside the tag in web.xml

---------------
ServletConfig
---------------
One ServletConfig per servlet
it is used to pass deploy-time info to servlet and configured in the deployment descriptor file, such as web.xml.
it is used to access ServletContext
It is within the Servlet element in Deployment descriptor.
It is accessed by using getServletConfig().getInitParameter("myname");
It is available only to the servlet in which init-param is configured.
 


--------------
ServletContext
---------------
It returns the current context of a web application running in a particular JVM.
if the web application is distributed,it is one per JVM.
It is used to access the elements configured in deployment descriptor.
It is accessed by using getServletContext().getInitParameter("myname");
It is available to any servlet or jsp that is part of web application.


  

Servlet Life Cycle

Servlet Life Cycle

The following is a nice tutorial on Servlet Life Cycle.
http://tutorials.jenkov.com/java-servlets/servlet-life-cycle.html

By default the servlet is not loaded until the first request is received for it. You can force the container to load the servlet when the container starts up though.

A Servlet is part of a Java web application. A Servlet container may run multiple web applications at the same time, each having multiple servlets running inside. Here is an llustration of that:

The browser sends an HTTP request to the Java web server. The web server checks if the request is for a servlet. If it is, the servlet container is passed the request. The servlet container will then find out which servlet the request is for, and activate that servlet. The servlet is activated by calling the Servlet.service() method.


The servlet life cycle is managed by the servlet container. The life cycle contains the following steps:

1.Load Servlet Class.
2.Create Instance of Servlet.
3.Call the servlets init() method.
4.Call the servlets service() method.
5.Call the servlets destroy() method.