WebLogic Server Terminologies

What is domain?
The logically related group of WebLogic server instances managed from single set of configuration artifacts. DOmian will have the servers and the clusters.


What is server?
It is the configured instance to host applications and resources. Server can be managed server or administraton server.



What is admin server?
One domain will have one administration server. It will have the administration console. From the administration console we can start and stop the servers.



What is Managed Server?
Each managed server is independent of other managed servers. There can be multiple managed servers in a domain. Managed servers are managed by the administration server. Each managed server will have the local copy of the configuration. Managed server and the administration server will be in sync. If you make any changes to the managed server from the administartation server then that configuration will be moved to the Managed server.


What is Cluster?
The group of managed servers running simultaneously in a domain is called as Cluster. There can be multiple clusters in a single domain. All the servers within the cluster have to be at the same Maintenance pack level. The clustered servers can be in the same or different machines.

What is Node Manager?
It is not associated with any domain. It is the utility running on the server which enables to start ,stop and restart the server. It is required for the server Migration


What is Machine?
Machine is piece of hardware. In a machine we can have the multiple managed servers

Administration tools
1. Configuration Wizard. : For creating the domains
2. Administration console : Complete administatration of the server is involved here.We can monitor dmains,deploy the applications and control the servers.The operation that can be performed on the admin console can be performed in the WLST i,e WebLogic Scripting Tool
Along with these we can use the command line tools for the deployment.
Weblogic.Deployer.

Conclusion

The best practice is to have the each manged server in its own physical server.Each application will have its own domain. Even the admin server have to be in its own phusical server.

Developing a portlet with multiple actions

In our portlet class we need not implement our functionalities using processAction(),
We can write our own method actions.The name of the method can be whatever you want since you will be
referring to it when creating the URL


public class MyGreetingPortlet extends MVCPortlet {
public void setGreeting(
ActionRequest actionRequest, ActionResponse actionResponse)
throws IOException, PortletException {
PortletPreferences prefs = actionRequest.getPreferences();
String greeting = actionRequest.getParameter("greeting");
if (greeting != null) {
try {
prefs.setValue("greeting", greeting);
prefs.store();
}
catch(Exception e) {
SessionErrors.add(actionRequest, "error");
}
}
SessionMessages.add(actionRequest, "success");
}
public void sendEmail(
ActionRequest actionRequest, ActionResponse actionResponse)
throws IOException, PortletException {
// Add code here to send an email
}
}


The jsp element to call this is as below

Passing information from the action phase to the render phase

Information can be passed from action phase to the render phase in 2 ways
1. By setting the setRenderParameter in the processAction method
2. Using the session

1. BY setRenderParameter
Within the implementaiton in the
processAction method you can invoke the setRenderParameter to add a new parameter
to the request that the render phase will be able to read:
actionResponse.setRenderParameter("parameter-name", "value");
From the render phase (in our case, the JSP), this value can be read using the
regular parameter reading method:
renderRequest.getParameter("parameter-name");

It is important to be aware that when invoking an action URL, the parameters
specified in the URL will only be readable from the action phase (that is the
processAction method). In order to pass parameter values to the render phase you
must read them from the actionRequest and then invoke the setRenderParameter
method for each parameter needed.

2. By using SessionMessages

SessionMessages.add(actionRequest, "success");

This is displayed in the jsp with the below tag

Understanding the two phases of portlet execution: action and render

Action phase: The action phase can only be invoked for one portlet at a
time and is usually the result of an user interaction with the portlet. In
this phase the portlet can change its status, for instance changing the
user preferences of the portlet. It is also recommended that any inserts
and modifications in the database or operations that should not be
repeated are performed in this phase.

• Render phase: The render phase is always invoked for all portlets in
the page after the action phase (which may or not exist). This includes
the portlet that also had executed its action phase. It's important to
note that the order in which the render phase of the portlets in a page
gets executedis not guaranteed by the portlet specification. Liferay has
an extension to the specification through the element render-weight in
liferay-portlet.xml. Portlets with a higher render weight will be
rendered before those with a lower value.


renderURL: this is the type of URL that we have used so far. It invokes a
portlet using only its render phase.

• actionURL: this type of URL tells the portlet that it should execute its
action phase before rendering all the portlets in the page.

Exploring tlds

Liferay exposes some of the default objects this is been done from the tag

and the corresponding class is com.liferay.taglib.theme.DefineObjectsTag

it exposes the objects like themeDisplay , layouts ,layout ,user ,theme etc


There is one more tag




It exposes the class
com.liferay.taglib.portlet.DefineObjectsTag

It exposes the objects like portletConfig , portletName , portletPreferences , portletPreferencesValues , portletSession , portletSessionScope and conditionally
actionResponse, eventResponse, renderResponse, resourceResponse based on the phase.


That is the reason we include these imports in all the pages.

Exploring Liferay Login Portlet

From this example we will know how to submit the portlet, how to read the parameters from the page. We will know some of the default objects of the Liferay and how the values will be populated.

ConfigurationActionImpl is responsible for the struts actions

The Liferay Portlet configuration is as below



58
/html/icons/login.png
login
com.liferay.portlet.login.action.ConfigurationActionImpl
false
false
false
50
/html/portlet/login/css/main.jsp
portlet-login
true



The LoginAction will explain the basic concept of handling the parameters