How to Solve Servlet Errors in Eclipse?

Servlet Errors in Eclipse

For new users, it’s common to encounter following errors while developing servlet in Eclipse (I am using eclipse-jee-indigo-SR2-win32) or without it:

HttpServlet cannot be resolved to a type
HttpServletRequest cannot be resolved to a type
HttpServletResponse cannot be resolved to a type
ServletException cannot be resolved to a type
The import javax.servlet cannot be resolved
WebServlet cannot be resolved to a type

servlet-api.jar errors in eclipse
servlet-api.jar errors in eclipse

Java – Download Free EBooks and Whitepapers

The problem is “servlet-api.jar” is not on classpath.

How to add servlet-api.jar in classpath from Eclipse?

Right Click on the Web Project and Click on Properties

Dynamic Web Project Properties in Eclipse
Dynamic Web Project Properties in Eclipse

Select Java Build Path

Java Build Path in Eclipse
Java Build Path in Eclipse

Click on the Library Tab

Java Build Path in Eclipse-Libraries
Java Build Path in Eclipse-Libraries

Click on “Add External Jar” -> Locate servlet-api.jar from your local system (It’s available in Tomcat Distribution directory.)

Add External Jar servlet-api.jar from tomcat installation dir
Add External Jar servlet-api.jar from tomcat installation dir
servlet-api.jar external jar added
servlet-api.jar external jar added

Click OK and all errors will be resolved.

Servlet errors resolved
Servlet errors resolved


Other Interesting Tomcat related Articles:


Microsoft Visio 2010 – Free Quick Reference Card

Microsoft Visio 2010 – Free Quick Reference Card

 This Microsoft Visio 2010 Reference provides shortcuts, tips, and tricks for the popular diagramming software. Use this reference to brush up on the basics and to find alternative methods to your favorite commands.

Cloud Computing – Download Free EBooks and Whitepapers
Java – Download Free EBooks and Whitepapers
Windows – Download Free EBooks and Whitepapers
Microsoft Visio 2010 - Free Quick Reference Card
Microsoft Visio 2010 – Free Quick Reference Card

This printable quick reference is yours to use, distribute, and share at your organization!

Along with this free reference card, if you are eligible, you will also receive a 30-day trial of CustomGuide training, including over 7,000 Online Skills Assessments and Interactive Tutorials.

To Download Click Here.


Microsoft Access 2010 – Free Quick Reference Card

Microsoft Access 2010 – Free Quick Reference Card

This Microsoft Access 2010 Reference provides shortcuts, tips, and tricks for the popular database management system. Use this reference to brush up on the basics and to find alternative methods to your favorite commands.

Cloud Computing – Download Free EBooks and Whitepapers
Java – Download Free EBooks and Whitepapers
Windows – Download Free EBooks and Whitepapers
Microsoft Access 2010 - Free Quick Reference Card
Microsoft Access 2010 – Free Quick Reference Card

This printable quick reference is yours to use, distribute, and share at your organization!

Along with this free reference card, if you are eligible, you will also receive a 30-day trial of CustomGuide training, including over 7,000 Online Skills Assessments and Interactive Tutorials.

To Download Click Here.


Java – How to Decompile Class files from Jar Files

How to Decompile Class files from Jar Files?

According to Wikipedia, A decompiler is the name given to a computer program that performs, as far as possible, the reverse operation to that of a compiler. That is, it translates a file containing information at a relatively low level of abstraction (usually designed to be computer readable rather than human readable) into a form having a higher level of abstraction (usually designed to be human readable). The decompiler does not reconstruct the original source code, and its output is far less intelligible to a human than original source code.

Java – Download Free EBooks and Whitepapers

The term decompiler is most commonly applied to a program which translates executable programs (the output from a compiler) into source code in a (relatively) high level language which, when compiled, will produce an executable whose behavior is the same as the original executable program. By comparison, a disassembler translates an executable program into assembly language (and an assembler could be used to assemble it back into an executable program).
Java De-compiler
The “Java Decompiler project” aims to develop tools in order to decompile and analyze Java 5 “byte code” and the later versions.

JD-Core is a library that reconstructs Java source code from one or more “.class” files. JD-Core may be used to recover lost source code and explore the source of Java runtime libraries. New features of Java 5, such as annotations, generics or type “enum”, are supported. JD-GUI and JD-Eclipse include JD-Core library.

JD-GUI is a standalone graphical utility that displays Java source codes of “.class” files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields.

JD-Eclipse is a plug-in for the Eclipse platform. It allows you to display all the Java sources during your debugging process, even if you do not have them all.


  • JD-Core and JD-GUI are written in C++. This allows an extremely fast decompilation and a display.
  • JD-Core does not require the Java runtime environment for its functioning, therefore no special setup is required.
  • JD-Core works with most current compilers including the following:
    • jdk1.1.8
    • jdk1.3.1
    • jdk1.4.2
    • jdk1.5.0
    • jdk1.6.0
    • jdk1.7.0
    • jikes-1.22
    • harmony-jdk-r533500
    • Eclipse Java Compiler v_677_R32x, 3.2.1 release
    • jrockit90_150_06
  • JD-Core supports the following new features of Java 5:
    • Annotations
    • Generics
    • Type “enum”
  • JD-GUI supports Drag and Drop.
  • JD-GUI supports JAR files.
  • JD-GUI displays color coded Java source code.
  • JD-GUI allows you to browse the “class” files hierarchy.
  • JD-GUI displays “log” files, and allow you to decompile “class” files appearing in Java stack traces.
  • JD-Core, JD-GUI and JD-Eclipse use the excellent cross-platform wxWidgets toolkit.


Download from

Download Java Decompiler
Download Java Decompiler

Extract file -> Click on jd-gui Application

Slect Jar file to Decompile in JD-GUI
Slect Jar file to Decompile in JD-GUI
Decompiled Java Class from Jar File
Decompiled Java Class from Jar File


How to Import Existing Java Project in Eclipse

Import Existing Java Project -> Open Eclipse -> Click on File Menu -> New -> Java Project
Java Project
Java Project

Java – Download Free EBooks and Whitepapers

Give Java Project Name

New Java Project
New Java Project
New Java Project Settings
New Java Project Settings

Click on Finish; New Java Project will be available in Project Explorer -> Right Click on it…

Import Existing Project
Import Existing Project
Select General -> File System
Select General -> File System


Select Existing Project from File System
Select Existing Project from File System
Overwrite Dialog Box
Overwrite Dialog Box

See the Red Cross Mark in added Project due to Jar files

Java Source File Errors
Java Source File Errors

Right Click on the Imported Project

configure build path in eclipse
configure build path in eclipse

Click on Add Jars;

Add Jars in Eclipse
Add Jars in Eclipse

If Jars are not available in the Same Project which is imported then click on Add External Jar in above dialog box, Select Jars from the directory available on your system.

Jar Selcetion
Jar Selcetion

Click on Ok.

Notice, Red Marks are Gone..

Source Files Errors Removed After adding Jars in Classpath
Source Files Errors Removed After adding Jars in Classpath


1. Introduction

FEDERATED IDENTITY MANAGEMENT – “Identity” consists of a “set” of information based on context, allied with a definite entity (End User or System). Identity Management should include: Identity Provisioning, De-Provisioning, Identity Information Security, Identity Linking, Identity Mapping, Identity Federation, Identity Attributes Federation, Single Sign On, Authentication and Authorization.

Cloud Computing – Download Free EBooks and Whitepapers

For organizations, unauthorized access to information resources is a foremost concern. Authentication, Authorization and Auditing are the 3 popular “A”s in the context of growing demand of regulatory and compliance requirements.

Authentication (Who are you?): Authentication, solid form of identification; it is the process of validating the identity of an end user or system.

Authorization (What privileges do you have?): Privileges, the end user or system is permitted to after identity establishment. In other words, authorization is the process of implementing and enforcing policies.

Auditing (How the other “A”s are doing?): Auditing is performed to verify efficiency and compliance of IAM controls as per established access policies. It is used to detect security breaches and to specify corrective measures.

With the adoption of cloud services, the organization’s trust boundary has become dynamic. It has moved beyond the control of IT. Identity & Access Management is a critical requirement considering data sensitivity and privacy of information have become increasingly an area of concern in cloud.

Here comes Federated Identity Management as an aid. It allows identity credentials and their associated data to stay on premise or at trusted place while connecting organizations together by distributing copies of selected identity information or claims and allows proficient management, governance and movement in a Cloud world.

In information technology, federated identity has two general meanings:

1.      Assembled identity, of a person’s user information, stored across various identity management systems.

2.      A user’s authentication process across multiple IT systems or even organizations.

In our case, users of different cloud service providers can use a federated identification for identity establishment in cloud computing. Let’s consider Identity Management across “On Premise” and “On Cloud”.

2. On Premise Identity Management


In an archetypal organization, applications are deployed inside the organization’s outskirts and “trust boundary” is more often than not static and is monitored and controlled by the organization itself.

Standardized Access control policies and robust identity management tools help in secure and efficient connectivity for Employees, Partners or customers in day to day activities like:

·         To access Employee HR Portal

·         To access Intranet Portal from off-premise

·         To access knowledge management resources or to contribute in KM.

·         E-Transactions

The conventional approach to solve this problem has been Single Sign on (SSO), the centralization of access control information into one server. Use of LDAP, Kerberos and Active Directory is very popular.

2.1. Kerberos

Figure 1. Kerberos

Kerberos is a computer network authentication protocol, which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner [1].

1) The client authenticates itself to the Authentication Server and receives a ticket (All tickets are time-stamped).

2) It then contacts the Ticket Granting Server, and using the ticket it demonstrates its identity and asks for a service.

3) If the client is eligible for the service, then the Ticket Granting Server sends another ticket to the client.

4) The client then contacts the Service Server, and using this ticket it proves that it has been approved to receive the service.

Limitations of Kerberos Protocol:

·         Single point of failure: When the Kerberos server is down, none can log in.

·         Strict time requirements: The clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail.

·         The administration protocol is not standardized and differs between server implementations.

·         Compromise of authentication infrastructure will allow an attacker to pose as any user.

2.2. Active Directory:

Figure 2. Active Directory

Active Directory uses a number of standardized protocols to provide a variety of network services, including:

·         Lightweight Directory Access Protocol LDAP, the industry standard directory access protocol, compatible with many management and query applications. Active Directory supports LDAPv3 and LDAPv2.

·         Optional Kerberos-based authentication

·         DNS-based naming and other network information


·         Central location for network administration and security

·         Information security and single sign-on for user access to networked resources

·         The ability to scale up or down easily

·         Standardizing access to application data

·         Synchronization of directory updates across servers

The Kerberos security protocol (and therefore the AD domains and forests built on it) was designed to work in a fairly secure environment, such as a corporate intranet. Within organization, directory services such as Microsoft’s Active Directory or products using the Lightweight Directory Access Protocol have allowed companies to recognize their users through a single identity.


“But” What if,

·         Users and Resources are in two Different Organizations: Traditional SSO is impractical for extranets or Web services because partners may not agree on a single SSO vendor, and it is not possible / feasible to have a unified database.

·         For Cloud based application: In Cloud Computing, For example, when an organization uses hosted, software as a service (SaaS) CRM solution e.g., or Application developed on or Application deployed on Amazon EC2(Public Cloud), users are employees who access the application have enterprise identities. With external service providers, access is often managed by a separate account, which is not often associated with their organization’s identity management system and thereby represents a considerable security dilemma.

What about providing adequate security for these identities?

3. “On Cloud” Federated Identity Management

With federated identity, identity information can be ported across diverse security domains using “claims” and “assertion” from a digitally signed identity provider. Claims-based authentication (Multi-factor) is the foundation of federated identity. It is about presenting an application with the potentially “wide” range of identity information it needs, from an identity provider it trusts, regardless of whether the application is inside or outside the enterprise (Cloud in our case)[2].

With Cloud adoption, the organization’s trust boundary will become dynamic and will move beyond the control of an organization. The network, system, and application boundary of an organization will extend into the Cloud Service Provider domain. Loss of control will continue to challenge the established trusted governance and control model.

That is where we require Federated Identity, it allows companies to keep their own directories and securely exchange information from them.

Identity federation conquers the concern of “securely” managing identities, enabling the organization to share employee identity information with the Cloud Service Provider (CSP) or any other resource over the Internet. This allows the organization to boost their control over “who” has access to “what” information and resources, regardless of where those resources reside (e.g., on’s servers, AWS). Federated identity management improves security by controlling access on an operation base and providing a detailed audit trail.

Federated identity management enables:

·         Easier access to consume cloud resources

·         Superior end-user experience through SSO and just-in-time account provisioning

·         Reduced cost and time to incorporate authentication and authorization

·         Elimination of non-scalable proprietary SSO applications

Federation enables the communication of systems and applications separated by an organization’s trust boundary, e.g., a sales person interacting with from a corporate network. Federated Identity Management leverages lessons from the U.S. federal system and application integration. Local applications or organizations maintain their own repositories which respond to queries from both local and remote applications with security assertions containing user attributes and roles. When encountering external users, the local applications query other federated repositories to authenticate and authorize these non-local users [3].

Identity Federation can be accomplished any number of ways with the use of formal internet standards such as SAML, Information Cards, and OpenID etc [4]. Identity Federation has following solution areas:

1.      Single Sign On

2.      Application based Web Services Security

3.      Identity Lifecycle

Some of the cloud use cases that require IAM support from the CSP include:

·         Employees of an organization accessing a SaaS service using identity federation (e.g., sales and support staff members accessing Salesforce.)

·         To access the CSP management console to provision resources and access for users using a corporate identity

·         Developers creating accounts for partner users in a RightScale

·         End users accessing storage service in the within and outside a domain using access policy management features

·         An application residing in a cloud service provider (e.g., Amazon EC2) accessing storage (e.g., Amazon S3) from cloud service.

4. Face-Off

Kerberos / Active Directory

Claim based Authentication

In AD, every authenticated user has one or more Kerberos tickets that contain identity information.

A basic construct of claims-based authentication is the token, formatted in Security Assertion Markup Language (SAML). SAML token is similar to a Kerberos ticket.

A Kerberos ticket contains a payload, called the access token that asserts what security groups the user is a member of. The resource (e.g., a file server) trusts this assertion because the ticket is cryptographically confirmed to be from a valid identity source

The payload of this assertion contains a potentially broader set of identity information, called “claims”, than a Kerberos ticket holds. A claim can be anything you define it to be: name, email, phone number, age, privilege level, meal preference, etc.

In AD, a Kerberos ticket has time restrictions regarding when it can be used. This prevents replay attacks, in which packets are captured then played back to a server at a later time in an attempt to compromise it.

An SAML assertion conditions can restrict when the assertion is valid, who can use the assertion, how many times it can be used, and whether the assertion can be delegated.

AD Kerberos ticket is encrypted with either the ticket-granting server key (for a ticket-granting ticket—TGT) or the user key (for a session ticket).

An SAML assertion is signed and can have various degrees of encryption from the identity provider that created it, from individual components to the entire assertion.

The scope of an AD Kerberos ticket is essentially within the enterprise.

SAML token has no restrictions of this kind at all. This means that a claims-aware application can authenticate users equally comfortably inside or outside the corporate firewall.

5. How Federated Identity Works?

Private Cloud Scenario

User inside the enterprise attempts to access a claims-aware application that’s deployed in Private Cloud. This situation is common nowadays as more applications are becoming claims aware and the private cloud is becoming popular in large organizations.

Figure 3. Identity in Private Cloud [3]

All you need to implement this scenario is a federation service, such as

1.      Active Directory Federation Services (ADFS) 2.0, IBM Tivoli Federated Identity Manager, or Ping Identity’s PingFederate

2.      Claims-aware Application

1.The application needs identity information for the user.

2. The application triggers or initiates either a web service call or an HTTP redirect through the browser to ask for a token from an STS.

3. The STS responds to the request, returning the token to the application.


Public Cloud Scenario (SaaS)

Accessing a SaaS provider, in which an enterprise uses a service such as Salesforce or a hosted email provider without maintaining separate passwords at every provider.

Public Cloud Scenario (IaaS)

In Public Cloud users in the identity provider’s enterprise need to seamlessly access application deployed in the Public Cloud.

Figure 4. Federated Identity in Public Cloud

The single largest difference between this scenario and the previous one is that the Cloud Service Provider may have its own STS, and the application service trusts it alone. The federated trust agreements that the Cloud Service Provider establishes with its customers are supported by the STS, rather than the application service. This Cloud Service Provider configuration is more scalable than one without an STS because the resource load of potentially thousands of trusts is focused on the STS instead of the application service and won’t affect the application service’s resources. It’s also more secure, because the application service doesn’t trust any external claims—only the claims generated by its own STS in Public Cloud [3].

 6. IDaaS

 Federated identity management makes feasible the vision of “identity as a service (IDaaS)” where authentication and authorization functions are available to any application.

Figure 5. IDaaS

 The identity store in the cloud is kept in sync with the corporate directory through a provider-proprietary scheme. Organization can work with the CSP to delegate authentication to the cloud identity service provider.


·         Abstraction from complexity of integrating with various CSPs supporting different federation standards.

· and Google support delegated authentication using SAML. If they support two different versions of SAML then Identity Broker that support both SAML standards (multiprotocol federation gateways) can hide this integration complexity from organizations adopting cloud services.      


·         Dependency on 3rd party for an identity management service

·         Less visibility and Control into the service, implementation and architecture details.

o   Availability and Authentication performance of cloud applications hinges on the identity management service provider

7. Standards

 Identity Federation can be accomplished any number of ways with the use of formal internet standards as discussed below [5]:

Figure 6. Standards

7.1. SAML

·         Most mature, detailed, and widely adopted specifications family for browser-based federated sign-on for cloud users

·         Enables delegation (SSO)

·         Multifactor authentication

·         Support strong authentication and web SSO, avoid duplication of identity, and share only selected attributes to protect user privacy

·         Platform neutrality. SAML abstracts the security framework away from platform architectures and particular vendor implementations.

·         Business-to-business and employee-facing use cases

·         Shibboleth

o   Led by Internet2 to provide peer-to-peer collaboration using a federated identity infrastructure based on SAML.

o   Huge adoption rate in university and research communities

·         Liberty Alliance

o   An organization of vendors and enterprises that is largely perceived as having formed in response to Microsoft’s Passport efforts.

o   Identity federation framework (ID-FF) and identity Web services framework (ID-WSF). Their ID-FF work, which originally resulted in two versions of the ID-FF specification, has now been incorporated into SAML 2.0.

o   Provides testing services for SAML 2.0 as well as their own protocols.

7.2. SPML

·         Emerging

·         Xml-based framework being developed by oasis for exchanging user, resource, and service provisioning information among cooperating organizations.

7.3. XACML

·         XACML is an oasis-ratified, general-purpose, xml-based access control language for policy management and access decisions.

·         Xml schema for a general policy language, processing environment model to manage the policies and to conclude the access decisions.

·         A standard way to express authorization policies across a diverse set of cloud services and externalize  authorization and enforcement from the application

7.4. OAUTH

·         OAUTH is an emerging authentication standard that allows consumers to share their private resources (e.g., photos, videos, contact lists, bank accounts) stored on one csp with another csp without having to disclose the authentication information

·         Supported via an API by service providers including GOOGLE, TWITTER, FACEBOOK, and PLAXO


·         OPENID is an open, decentralized standard for user authentication and access control, allowing users to log on to many services with the same digital identity—i.e., a single sign-on user experience with services supporting OPENID.

·         Not adopted due to trust issues

7.6. WS-*

·         Driven by a collaborative effort between Microsoft, IBM, VeriSign, RSA Security, Ping Identity and others.

·         Composable suite of specifications for enabling secure Web services.

·         WS-Trust, WS-Federation, and WS-Policy is an evolving set of mechanisms for layering authentication, authorization and policy across both single and multiple security domains.


8. Conclusions


This paper reviewed the concept of Federated Identity Management in the particular context of Cloud Computing. The paper has re-examined most important approaches to traditional IdM systems.  The paper has also discussed the specific case of Identity management in various Cloud Deployment scenarios like public and private cloud.

As final remarks, we can notice that despite the diversity in implementation of Federated Identity, IDaaS will become the most important service in near future which abstracts away all diverse details of Identity management in Cloud Scenario.



[1]           Kerberos (protocol), Wikipedia

[2]           Federated Identity, Wikipedia

[3]           Sean Deuby, Ease Cloud Security Concerns with Federated Identity,

[4]           David F. Carr, What’s Federated Identity Management?

[5]           Cloud Security and Privacy, An Enterprise perspective on Risk and Compliance, O’REILLY

Tutorial: Struts Portlet in Weblogic Portal Server

Struts Portlet in Weblogic Portal Server

Java – Download Free EBooks and Whitepapers

Table 4-5 describes each WebLogic Portal-specific field of the dialog.

Table 4-5 New Portal Web Project Dialog Data Fields – Weblogic Portal Information 



Configurations dropdown menu

The value automatically displayed in this dropdown menu corresponds to the selections made in the tree view of project facets. You can select a preset group of facets from the dropdown menu, or select and unselect specific check boxes in the tree display. If you select a customized set of facets, displays in the field.

Project Facet Display Tree

Weblogic Portal primary

Select the Weblogic Portal facets that you want to install. If certain facets depend on others, messages appear to describe these dependencies and your selections must conform to these requirements.

§  Portal Customizations Framework

§   Portal Framework

§    Portal Framework Struts

§     Portal Visitor Tools

§Portal Web Application Services

§WSRP Producer

For more information about each of these sub-features, refer to Weblogic Portal J2EE Library Descriptions.

Weblogic Portal (Optional)

Check this box to choose from optional facets. Optional facets include commerce tag libraries, analytics integration, and content presenter framework.

For more information about these features, refer to Weblogic Portal J2EE Library Descriptions.

Weblogic Portal Collaboration

Check this box (and one or both of its sub-features) to add the collaboration portlets to the project, or to enable the project as a GroupSpace project.

§  Collaboration Portlets – causes the J2EE library wlp-collab-portlets-app-lib to be associated with your project. You can use these portlets outside a GroupSpace environment.

§   GroupSpace – causes the GroupSpace-related J2EE libraries to be associated with the project. If you select this option, you must also select the Collaboration Portlets sub-feature.

For detailed instructions on creating a GroupSpace-based application, refer to the Communities Guide

Note:        Do not add GroupSpace to portal web projects that already contain non-GroupSpace portals. For more information, refer to the Communities Guide.


Show Runtimes

Click to view the runtimes associated with this web project.

New Portal Web Project – Web Module Dialog

The New Portal Web Project – Web Module dialog is shown in Figure 4-5.

Figure 4-6 New Portal Web Project – Web Module dialog

Table 4-6 describes each field of the dialog.

Table 4-6 New Portal Web Project – Web Module Data Fields  



Context Root

The context root of the web application.

Content Directory

The default web content directory name WebContent is automatically displayed; you can change it if you wish.

As a best practice, you should locate your portal file(s) and other portal resources in a web content directory that is subordinate to the web project directory.

Java Source Directory

The default Java source directory name src is automatically displayed; you can change it if you wish.

New Portal Web Project – WebLogic Web Module Dialog

The New Portal Web Project – WebLogic Web Module dialog is shown in Figure 4-7.

Figure 4-7 New Portal Web Project – WebLogic Web Module Dialog

Table 4-7 describes the dialog.

Table 4-7 New Portal Web Project – Weblogic Web Module Dialog Description 



Shared J2EE Libraries selection buttons

If you select the Use Shared J2EE Libraries radio button, Weblogic Portal creates associations with shared J2EE libraries rather than copying the complete set of JAR files into your project. BEA recommends that you use shared J2EE libraries because of their significant advantages in source control, file sharing, and patch application. With any future patch installations, Weblogic Portal supports only configurations that do not have copied J2EE library resources in the project. For more information about shared J2EE libraries, refer to Weblogic Portal and Shared J2EE Libraries.

If you select not to use shared J2EE libraries, all of the necessary JAR files will be copied directly into the project.

 Once You have created the Portal EAR project & Portal WEB project You can integrate the struts application with the portal.

Integrating Struts Applications

You can integrate, or import, a Struts application into an enterprise application in Workshop for WebLogic. Once in Workshop for WebLogic, you can give the Struts application a portal user interface by creating portlets, add personalization and campaign functionality, and take advantage of WebLogic Portal’s content and user management services.

Preparing Your Struts Application for Integration

Follow the guidelines presented in this section as you prepare your existing Struts application for integration with WebLogic Portal:


If you have a top-level Struts application, you must refactor it before you can integrate it. Any Struts applications that are intended for use in a portal must be developed as Struts modules, including the usage of the html:link tag for any URLs used in JSPs. Without this, it is impossible for WebLogic Portal to perform the necessary URL rewriting that is required to transparently modify links when the Struts application is used within a portlet.

As part of this process, modify your application to use WebLogic Portal tags using either of these methods:

§  Rely on the taglib mapping in web.xml to map the WebLogic Portal struts adapter tags to the URI that you already have in your JSPs; this allows you to use your existing JSPs.

§  To use Struts 1.2, which is the default version of Struts used for new portal web projects, BEA recommends that you change your JSPs to use WebLogic Portal taglib URIs; this prevents you from having to change your web.xml file, and provides the benefit that these taglibs are automatically deployed.

Add Tags if Needed

If a Struts application used within a portal also needs to support stand-alone operation, JSPs referenced by Action forwards must be authored to use several optional tags in the HTML tag library found in struts.jar and struts-adapter.jar (a file that is created by BEA). The first of these, <html:html>, is found in both Struts and the Struts-adapter. The Struts-adapter version overrides the Struts version of the tag and adds support for detecting whether or not to inhibit rendering of the tag output text if it is used from within a portal, where outputting the HTML text would result in non-well-formed HTML. Two additional tags are provided in the Struts-adapter version of the HTML tag library; use them in JSPs that also need to be used standalone: <html:head> and <html:body>. These two tags have the same portal-aware rendering behavior as the <html:html> tag.

Override Certain Behaviors of a RequestProcessor

Some Struts applications use a custom RequestProcessor. WebLogic Portal Struts integration requires that you override certain behaviors of a RequestProcessor. The class com.bea.struts.adapter.action.AdapterRequestProcessor, located in struts-adapter.jar, provides this standard behavior and must be used in all Struts applications used within a portal. Any custom RequestProcessors must either extend this class or use a utility class to perform the same required operation that this RequestProcessor performs. When extending this class, overrides of doForward() must call the superclass doForward() and also must not attempt to write to the response. Custom RequestProcessors that do not extend AdapterRequestProcessor must call com.bea.struts.adapter.action.AdapterRequestProcessorUtil.forwardUsingRequest() to perform any forwarding operations. (This method replaces an actual RequestDispatcher forward request with an operation that captures the forward URI for later use in including the URI into the portal output.)

Refactor any Existing Custom Action Servlet

If a Struts application depends on the use of a custom Action servlet, it must be refactored to use a custom RequestProcessor instead, as outlined above, and as recommended by the Struts implementation. Since the page flow functionality in WebLogic Portal uses a custom Action servlet, and since there can be only one Action servlet in a portal web project, portal Struts integration requires that the Action servlet not be customized. For more information on refactoring an Action servlet customization into a RequestProcessor customization, see the Struts documentation at

Remove the <html:link> Tag

The StrutsContent control supports module switching using Action forwards. If the Action forward returned by an invoked Action results in a content URI that resides in another module, the current module is switched to the corresponding new module, and all further requests to the Struts portlet containing the control are performed using the new module. Perform module switching using only Action forwards, not by using the tag to directly link to a JSP in another module; doing so might prevent the portal and Struts frameworks from correctly setting up and selecting the module.

Integration Steps

Once you create the Portal EAR project and Portal WEB project then the directory structure will be like…


































(Workspace Name)






































Now we are ready to integrate the struts application into weblogic portal 10.

We need to do all the modifications in “src” and “Webcontent”  folders exists in the WAR folder.

Copy all the java files into “src” folder. With packaging structure. If class files resides in classes->struts->example foder in normal struts application then in case of struts portlet copy the “.java” files into “src” folder with package “struts->example”.

No need to copy the struts.jar and struts-adapter.jar into WEB-INF->lib because when you create struts portlet those files are automatically included in the project in “Merged Project Content”. Except this files copy all jar files in WEB-INF->lib.

Copy the Struts application module’s struts-config.xml or module configuration file into WEB-INF, but rename it struts-auto-config-<module-path>.xml, where <module-path> is the module path to the Struts application relative to the web application root, with all instances of ‘/’ or ” changed to ‘-‘.

For example, if the module path is /struts/my/module, then rename struts-config.xml to struts-auto-config-struts-my-module.xml. Naming the module configuration file in this manner enables the PageFlowActionServlet used as the Action Servlet to automatically register the module without explicitly registering it with an init-param in web.xml. If you don’t want to take advantage of this functionality, you can rename struts-config.xml arbitrarily, but you must manually register the module in web.xml as usual for a Struts 1.1 or 1.2 (Beehive) module.

In the module configuration file, add the following line to configure the RequestProcessor that is required for portal integration:

(unless the Struts application requires a custom RequestProcessor). (This AdapterRequestProcessor class resides in the struts-adapter.jar which is included in the portal application by weblogic itself automatically so no need to include it explicitly.)

copy all the jsp files in the struts module directory(Which you will create yourself or if you hae name the struts-config.xml file as struts-auto-config-strutsApp.xml then at the time of portlet creation the portlet by right clicking on struts-auto-config-strutsApp.xml file and select “Generate Portlet” , strutsApp folder will be created in the WebContent directory and the portlet which has been generated will be placed in that folder). In the same foder structure you have used in the normal struts application. And give the path of those jsp files into struts-auto-config-strutsApp.xml accordingly.

Use the Portlet Wizard to generate a portlet based on a Struts module, as explained in this section.

To create a Struts portlet, follow these steps:

1.       Right-click the Struts application module’s XML configuration file located in the WEB-INF directory of the portal web application.

2.       Select Generate Portlet from the menu. The wizard automatically collects and displays the module path and configuration file name(s) in the Struts Config File dialog. An example is shown in Figure 5-17. Use the Browse and Add buttons to locate and add additional configuration files, if applicable.

Figure 5-17 Struts Config File Dialog

1.       Click Next.

2.       In the Struts Actions dialog, specify an action for the Struts portlet. The actions that appear in the drop-down menu are based on entries in the configuration file(s) that were added previously.

Figure 5-18 Struts Actions Dialog

1.       Click Create.

The Workshop for WebLogic window updates, adding the Portlet_Name.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the directory that you specified in the Struts Module Path dialog of the wizard.

File->new->Portal and then save it.

Now Click on the portlet file in package explorer and drag into the portal window and save it.

Now select the .portal file and then right click on it and select Run on Server from Run menu.

Best Practices and Development Issues

Use the following guidelines for integrating Struts applications in portals: