Page tree
Skip to end of metadata
Go to start of metadata

On this page:

Target audience:

CAST Administrators

Summary: this page provides detailed information about CAST's support for the J2EE technologies.

Detailed technology support

Language VersionSupportedComments

Java JDK 1.1 - 1.8


Information about versions 1.5 - 1.8 is listed below in the "Technology support notes" section.

JSP 1.1


JSPX documents (JSP in XML format) are not supported.

JSP 1.2


JSP 2.0


STRUTS Framework

  • Struts 1.0, 1.1 (including STXX 1.0 - 1.2)
  • Struts 2.0 - 2.1

EJB 2.0


EJB 2.1


EJB 3.0


Only @Stateless, @Stateful, @Local and @Remote annotations are supported

JPA 1.0 (part of EJB 3.0), JPA 2.0 (part of Hibernate 4.0)


WSDL 1.1


Spring IoC:

  • 1.2.x
  • 2.x
  • 3.x


  • 2.x
  • 3.1, 3.2, 3.3, 3.4, 3.5, 3.6
  • 4.0, 4.1, 4.2

Note that Applications using Hibernate 4.3 can be analyzed but new features introduced in this release are not supported.

Struts Validator:

  • 1.2, 1.3

Java Server Faces:

  • 1.2
  • 2.0, 2.1

This includes the support of the following third-party JSF libraries:

  • Richfaces
  • IceFaces
  • MyFaces (Apache)
  • PrimeFaces


  • 1.0, 1.1, 1.2
(tick)See section below for more information.

Required third-party software

To successfully deliver and analyze J2EE technologies, the following third-party software is required:

Install on workstation running the DMT (for extraction)
Install on workstation running CMS (for analysis)

Nothing required

Note that the CAST Delivery Manager Tool simply requires the location of the J2EE files for extraction and packaging.
Nothing required

J2EE objects and links

The following section lists the objects and links between objects that the J2EE analyzer is capable of detecting and storing in the CAST Analysis Service:


J2EE miscellaneous

J2EE Analysis

J2EE Application

Bean Property

CDI Named Bean

Entity Java Bean

Hibernate Configuration File

Hibernate Entity

Hibernate Entity Property

Hibernate HQL Named Query

Hibernate Mapping File

Hibernate SQL Named Query

Form Validation File

Java Properties Files

Java Property Mapping

J2EE Scoped Bean

J2EE Web Application Descriptor


J2EE XML Object

JPA Embeddable

JPA Embeddable Property

JPA Entity

JPA Entity Property

JPA Named Native Query

JPA Named Query

JPA ORM Configuration File

JPA Persistence Configuration File

JPA Persistence Unit

JPA Result Set

JSF Converter

JSF Faces Config File

JSF Input Field

JSF Managed Bean

JSF Outcome

JSF Validator

JSF View ID Pattern

JSP Custom Tag

JSP Custom Tag Attribute

JSP Custom Tag Library

JSP EL Function

Message Driven Java Bean


Servlet Attributes Scope

Servlet Mapping

Session Java Bean

Spring Bean

Spring Beans File

Spring Controller

Spring View

Struts Action

Struts Action Mapping

Struts Configuration File

Struts Form Bean

Struts Forward

Struts Interceptor

Struts Interceptor Stack

Struts Package

Struts Result

Struts Validator

STXX Pipeline

STXX Transform

STXX Transforms File

Validation Form

Validation Form Field

Validation Forms Set

XML Bean

Java pure

Annotation Type

Annotation Type Method





Data Object

Data Object Group

Entity Java Bean

EJB Group


Enum Item



Generic Class

Generic Constructor

Generic Interface

Generic Method

Generic Type Parameter



Instantiated Class

Instantiated Constructor

Instantiated Interface

Instantiated Method


Message Driven Java Bean




Session Java Bean



Enterprise Java Beans

Web Services

WBS Project

Wsdl File

Wsdl Service

Wsdl Port

Wsdl Port Type

Wsdl Operation

J2EE - References that are detected by the analyzer while analyzing JSP Pages and static references 

Link Type

When is this type of link created?Example
MENTIONThis link is created for the taglib directive.

The caller is the JSP File where the directive is defined.

The callee is the Tag Library identified by the "uri" attribute.

<%@ taglib uri="/examples-taglib" prefix="eg"%>
INCLUDEThis link is created for the include directive.

The caller is the JSP File where the directive is defined.

The callee is a JSP File, Static File or a JSP Mapping as specified by the "file" attribute.

<%@ include file="URL"%>
INHERITThis link is used to describe object hierarchy. It is created for the page directive.

It is always enriched by the sub-type Extend (class to super-class).

The caller is the JSP File where the directive is defined.

The callee is a Java Class as specified by the "extends" attribute.

<%@ page extends="com.cast.SuperClass"%>
THROWThis link is used to describe exception handling. It is created for the page directive.

The caller is the JSP File where the directive is defined.

The callee is a File (JSP or static) or a JSP Mapping as specified by the "errorPage" attribute.

<%@ page errorPage="URL"%>

This link is used to describe run-time interactions. It may be enriched by the following sub-types:

  • Read
  • Write
  • Forward
  • Include

In the "example" column you will find a list of all cases when these links are created. If omitted, the caller is the JSP File where the standard or custom action is defined.

<jsp:getProperty name="clock" property="dayOfMonth"/>

The callee is the Bean Property as specified by the "property" attribute.

<jsp:setProperty name="clock" property="dayOfMonth" value="13"/>

The callee is the Bean Property as specified by the "property"attribute.>

<eg:foo attr1="value"/>

The callee is the Tag Attribute as specified by the name of an attribute of the custom action.

<jsp:forward page="URL"/>

The callee is a File (JSP or static) or a JSP Mapping.

Definition of a servlet mapping: the caller is the Servlet Mapping and the callee is the associated Servlet.

Definition of a property mapping: the caller is the Property Mapping and the callee is a File (JSP or static), a JSP Mapping or a Java Type.

<jsp:include page="file"/>

The callee is a File (JSP or static) or a JSP Mapping.

RELY ONThis link is used to describe typing.

Caller uses callee to define its Java type. Callee always refers to a class or interface.

In our case the caller is a Bean and the callee is its class as specified by either "class" or "beanName" attribute.

Note that for all beans created from a XML Configuration file, a link of this type is automatically created.

<jsp:useBean id="clock" class="beans.clockBean" ... />
USEThis link is created for the jsp:useBeanstandard action.

The caller is the JSP File where the action is defined.

The callee is a Bean as specified by the "id" attribute.

This type is also used for dynamic link resolution. It covers server side objects referencing.

<jsp:useBean id="clock" class="beans.clockBean" ... />
PROTOTYPEThis link is used as follows:

Servlet: between the servlet component and its servlet class or JSP File as specified in the application descriptor via "servlet-class" or "jsp-file" XML element.

Custom Tag: between the tag object and its class or tei-class as specified in the tag library descriptor via "tag-class" and "tei-class" xml elements.

USER DEFINEDThese links are entirely specified by the user in the application's additional XML configuration files.

Users can use the following string values to specify the link type:

access (Access), call (Call), catch (Catch), fire (Fire), include (Include), inherit (Inherit), issonof (Is Son Of), lock (Lock ), mention (Mention), prototype (Prototype), raise (Raise), refer (Refer), relyon (Rely On), throw (Throw) or use (Use).

The following table shows a non exhaustive list of these types of links:

XML Configuration File
  • Java Type (class or interface)
  • Java Method
  • JSP Mapping
  • File (JSP or static)

  • Bean

Action Mapping
  • Java Type (class or interface)
  • JSP Mapping
  • File (JSP or static)
  • Bean

ESCALATEDWhen two objects are linked via a third object.Denoted by the square brackets around the link type in CAST Enlighten: [U]
INTERNAL ESCALATEDCreated when the calling object is not saved in the CAST Knowledge Base (i.e. a variable that is local to a function). As a result the analyzer will save the link and associate it with the parent of the calling object.Denoted by the curly brackets (or braces) around the link type in CAST Enlighten: {U}

References detected by the analyzer when carrying out a pure Java analysis

Link typeWhen is this type of link created?Example
MENTIONThis link is traced on following expressions:

- "instance of" operator

- cast expression

- class literal

- this literal

- class creation

- array creation

Callee always refers to a class or interface.

- if (b instanceof A . class) ...

- A . this = 1;

- B b = (B) new A(1);

- B b [] = new A[5];

THROW, RAISE, CATCHThese links are used to describe exception handling.
  • Throw link is traced on "throws" clause of method declaration towards exceptions possibly raised by the method.
  • Raise link is traced on "throw" statement towards type of the exception actually thrown by the method.
  • Catch link is traced on "try" statement towards type of the exception parameter declared in catch clause(s).

Callee always refers to a class.

- void f () throws C1 {...}

- throw new Exception()

- try {...}
catch (Throwable e) {...)

RELY ONThis link is used to describe typing.

Caller uses callee to define its Java type.

Callee always refers to a class or interface.

- void f (A a) {...}

- A a [] = null;

ACCESSThis link is used to describe run-time interactions.

It may be enriched by the following sub-types:

- Read

- Write

- Exec

- Member

- Array

- return x

- x = 1

- x++

- x[1] = 2

- x[] = {1,2}

- f(1)

- x.toString()

- x.f()

- x.y = 1

- read

- write

- read and write

- array not read

- read

- exec

- member

- member on x ; exec on f

- member on x ;write on y

INHERITThis link is used to describe object hierarchy. It may be enriched by the following sub-types:

- Extend:

  • class to super-class
  • interface to super-interface

- Implement:

  • class to super-interface(s)

Caller and callee always refer to classes or interfaces.

By extension the Inherit link is also used to describe method overriding as directly related to inheritance. In this case exclusive sub-types are available:

- Hide: for static methods;

- Override: for instance methods; in addition link can be enriched by the Implement sub-type if overriding is from a non abstract overriding method to an abstract overridden one.

Caller and callee always refer to methods.

- class C1 extends C2 implements I

- interface I1 extends implements I2

USEThis type is reserved for dynamic link resolution. It covers server side objects referencing:

- Select

- Insert

- Update

- Delete

PROTOTYPEThis link is reserved for J2EE components' support and is used as follows:
  • Applet: between the applet component and its applet class.

Caller and callee always refer to a component and to a class or interface.

  • "Exec access" links can be thought of as invocation calls.
  • To avoid redundancy with a corresponding escalated link, a "member access" link is not traced on a qualifier if this one matches the member parent.
  • "Prototype" links are never escalated.

References that are detected by the analyzer while analyzing JSP pages and Tag Files as client files

Link TypeWhen is this type of link created?
<!--METADATA TYPE = "TypeLib" FILE = "TypLibFileName" -->
<APPLET CODE = "AppletCode" CODEBASE = "AppletCodeBase" >
ActiveX through a variable
x = new ActiveXObject("A.B")
function f()

Use link between f and A.B

Dynamic data source
<OBJECT id = id_obj classid = "clsid:Sample"></OBJECT>
<A DATASRC=#id_obj datafld = "url" id=id_a>

Use link between id_a and id_obj

Database object

ExecuteSQL("select * from authors")
<img src="images/cover.jpg" border=0 usemap="#covermap" ismap id=id_img>
<map name="covermap">
<area shape=rect href="whatis.htm" coords="0,0,315,198">
<area shape=rect href="signup.asp" coords="0,198,230,296">
<area shape=rect href="holdings.asp" coords="229,195,449,296">
<area shape=rect href="question.htm" coords="314,0,449,196">
MENTIONIndicates the area in which the ActiveX is mentioned
function f()
return CreateObject("A.B")

Mention link between f and A.B

Indicates the area in which the class name is mentioned
function f()
return new g()

Mention link between f and g

INCLUDEIndicates the inclusion of a file
<SCRIPT LANGUAGE = "JavaScript" SRC = "inc.js">
CALLIndicates a call to a file
<A HREF = "called_file.htm" ></A>
<SCRIPT LANGUAGE = JavaScript>"called_file.htm")
Indicates a function call
function f()
return 1;
function g()
return f()

Call link between g and f

ACCESSIndicates a access type link enters a property of an HTC component together with the associated PUT or GET function.
GET="getxmlData" PUT="putxmlData"/>

ACCESS link between xmlData and the getxmlData and putxmlData functions.

Read only access to a file
<!--#FLASTMODE FILE = "accessed_file.htm">
Read only access to a variable
function f()

Read only access between f and x

Read and write access to a variable
function f()

Read and write access between f and y

ACCESS and PAGE_FORWARDIndicates a redirection. Only available for analyzed IIS applications.-
REFERIndicates that a variable refers to another variable
x = new ActiveXObject("A.B")

Refer link between Application("y") and x

RELY ON and INSTANCE OFIndicates that a variable is an instance of a class
x=new ActiveXObject("A.B")

INSTANCE_OF link between x and A.B

GO THROUGHIndicates the error file(s) used. Only available for analyzed IIS applications.-

References that are detected by the analyzer while analyzing the JSP page implementation class and/or Tag Handlers are dynamic references

For the dynamic references which are issued from a grep or have the caller located in a JSP script element as a declaration, expression or scriplet, a static link will be created. This new link has almost the same properties as the dynamic link, however the caller can be different. For example, when an object is located in an included file we will have a dynamic reference from the _jspService function of the JSP Page (resp. doTag method of a Tag File) and the object and a static reference from the included JSP File (resp. Tag File) and the object.

Note that the main function of the generated servlet/handler class is a pure dynamic object. So, it cannot have static references and we will create them at the function's parent (JSP Page/Tag File) level.

The following table summarizes the process of creation of the static links using the dynamic links while parsing generated servlet classes ('Dynamic Caller' are replace by 'Static caller'):

Caller: Dynamic ObjectLink code located inCaller: Static Object
_jspServiceJSP pageJSP page
_jspServiceJSP pageJSP page
servlet classJSP pageJSP page
servlet classJSP File (included file)JSP File (included file)
callerJSP Page or JSP File (included file)JSP Page or JSP File (included file)

Code sample

file a.jsp

<%! String redirectA; %>
<% redirectA = "/jsp/fileA.jsp"; %>

file a.jsp

<%@ include file="included.jsp"%>

file included.jsp

<%! String includedA; %>
<% includedA = "/jsp/fileA.jsp"; %>

The following lists describes references that are detected by the J2EE analyzer and the context in which corresponding links are traced and stored in the CAST Analysis Service:

Links between bean and class/interfaces are flagged as "Prototype" and are oriented as follows:

  • From bean local and remote interfaces to the EJB itself,
  • From the EJB itself to its bean class and, for entity bean, primary key class.

In addition the following links are also traced:

Link TypeWhen is this type of link created?

1. Traced between bean class member methods that are implicitly called by the EJB Container:

Home interface
Bean class
Remote interface

< implemented business methods ><--F--< exported business methods >

2. Traced between bean class/home interface and server side objects. For example in this standard ejb-jar.xml file:

         <method-name >findByFirstName</method-name>
      <ejb-ql>SELECT DISTINCT OBJECT(c) FROM Customer AS c WHERE c.firstName = ?1</ejb-ql>

The signature of the method is created from the values of the tags <method-name> and <method-param>. The method is searched for using the home interfaces (for the findXXX) and the bean class (for the "select methods").

The abstract schema name identified by grep in the query "EJB-QL" is used to find the associated bean (the query can reference the abstract schema name of another bean). From the bean it is possible to retrieve the associated table names and then link resolution is possible.

3. Also traced between SEI.Mi (Service Endpoint Interface) and BC.Mi (Bean Class). Mi stands for methods that have the same signature in the SEI and the BC. The EJB must be a stateless session bean:

  • SEI.Mi -- Fire --> BC.Mi

4. In addition, this link type is used for implicit invocations. They are used to reflect:

  • either the life cycle events of a component (such as creation/destruction)
  • or the interaction of an external actor such as a container (for EJBs or servlets) or a web browser (for applets)

Caller always refers to a component or a class member method. Callee always refers to a class member method.

Note: "Fire" links are never escalated.
Traced between bean and server objects (tables).
  • Bean --Usdui--> Table (U for Use, s for Select, d for Delete, u for Update, i for Insert)
  • Finder and select Method --Us--> Table

The link Bean --Usdui--> Table is traced only with container managed persistence (cmp) beans. For Bean managed persistence (bmp) beans, this link is indirect and is represented by two links:

  • One from Bean component to its java class (traced by EJB Assistant ).
  • One from Methods of the bean class where access to database objects is coded (via jdbc) to server objects corresponding to these objects (tables in this case). This link is traced by Java Analyzer.

For example in this standard ejb-jar.xml file:

<entity id="ContainerManagedEntity_1">

The bean in question is found in the ejb-jar.xml file using its name. Persistence information is identified using descriptors specific to each server type:

This link type is reserved for J2EE components' support and is used as follows:
  • EJB: between the bean component and its implementation classes (bean class, local/remote interfaces and possibly primary key class).
  • Servlet: between the servlet component and its servlet class.
  • EJB: between the bean and the SEI (Service Endpoint Interface).

For example the Webservices.xml (must be placed in the module directory)

<webservices ...>
      <jaxrpc-mapping-file>mapping.xml</jaxrpc-mapping-file> // relatif ou absolu

JAX-RPC mapping file (mapping.xml in the example) indicates that the mapping information between the web service operation and the java methods can be found in mapping.xml.

<java-wsdl-mapping ...>

Link example:

Note: "Prototype" links are never escalated.
These links correspond to inter-bean references. These references are made via a logical name (declared in the ejb-jar.xml file and that specifies the target ejb) used in the bean client code. The tags containing this logical name are <ejb-ref> or <ejb-local-ref>.
  • EJB client -- Access --> EJB target

For example in this standard ejb-jar.xml file:

<entity> //ou session ou message-driven
   <ejb-name> AddressBean</ejb-name>
   <ejb-ref> //ou ejb-local-ref

Each bean specifies the list of other beans it accesses as well as the references used to do so.

Traced between entity beans based on the abstract schema defined in deployment descriptor (beneath the <relationships>...</relationships> tag).

An entity bean (source EJB) is linked to another entity bean (destination EJB) only if navigation is possible from source EJB to destination EJB, i.e the relation-role in which source EJB is involved contains at least one cmr (container managed relationship) field allowing access to the destination EJB.

  <description>Team To Player</description>

Considering the example above, the source EJB TeamEJB will be linked to the destination EJB PlayerEJB because the cmr field players makes navigation possible from source to destination EJB.

For the same reasons, PlayerEJB (now source EJB) will have Refer link to TeamEJB (destination EJB for this link).

For each Join link, the information below is retrieved from the deployment descriptor and accessible in HTML Report:

  • Relation Name

    The name of the EJB relation as found in the <ejb-relation-name> tag of the deployment descriptor (PlayerEJB.teams-TeamEJB.players in the example). If no name is provided, EJB Assistant computes a name for the relation, based on the names of the two beans involved. For instance, the computed name would be TeamEJB-PlayerEJB if PlayerEJB.teams-TeamEJB.players was missing in the example.

  • Relation Description

    The relation description as specified in the descriptor. No default value for this attribute.

  • Multiplicity

    One of the string Many, One or N/S if relation role multiplicity is not specified in the descriptor.

Link TypeWhen is this type of link created?Example
Inherit + ImplementThis link is created when a port xml element is found within a service element and the corresponding binding and Port Typefound in a WSDL file.

Caller is the Port

Callee is the Port Type

<portType name="ServerSoapPort">
<binding name="ServerSoapBinding" type="wsdlns:ServerSoapPort">
<service name="CodaServices">
    <port name="ServerSoapPort" binding="wsdlns:ServerSoapBinding">
    <soap:address location="http://demeter:80/TestDCom/CodaServices.WSDL"/>
UseThis link is created for each Operation xml element within a Port Type when this one is linked to a Port.

The caller is a Port

The callee is an Operation

<portType name="ServerSoapPort">
    <operation name="ProcessAccount" parameterOrder="objAccount">
<binding name="ServerSoapBinding" type="wsdlns:ServerSoapPort">
<service name="CodaServices">
    <port name="ServerSoapPort" binding="wsdlns:ServerSoapBinding">
        <soap:address location="http://demeter:80/TestDCom/CodaServices.WSDL"/>
PrototypeThis link is traced toward service implementation objects and for each portTypeImpl and operationImplelements as specified in the generated file resulting from language specific mapping files.

The Caller is a Port Type or an Operation

The Callee is searched for among objects selected in the objects browser and is of the type specified in the generated file (cwClassId xml element). See KeyClass in the Keys Table in the CAST Analysis Service.

WSDD deployment descriptor

<deployment >
    <service name="AdminService" provider="java:MSG">
        <parameter name="allowedMethods" value="AdminService"/>
        <parameter name="enableRemoteAdmin" value="false"/>
        <parameter name="className" value="org.apache.axis.utils.Admin"/>
</deployment >

Transformed into:

Generated file (if keepGeneratedFiles=yes is added under the [WBSAssistant] section in the GloballySharedSettings.ini file, generated files are kept in the %temp%\Cast Temporary Files folder)

<webservices-impl >
    <serviceImpl name="" wsdlFile="">
        <portTypeImpl name="AdminService" implClassFQName="org.apache.axis.utils.Admin">
            <cwClassId>5040</cwClassId> // 5040 corresponds to a Java Class 

Technology support notes

This section provides more detail about the support for specific J2EE technologies and the way in which CAST handles them.

Please also see Web technologies for more information about web technology specifics (i.e. XHTML, JScript, JavaScript).

JDKs 1.5 - 1.8

Limitations in support

CAST supports JDKs 1.5 - 1.8 with some limitations. These limitations are listed below, but are not exhaustive:

  • Compilation errors are not always noticed by J2EE Analyzer.
  • Compilation errors due to generics are not detected. To avoid analysis interpretation issues you must ensure that the source code that references generics does actually compile.
  • The Java interface related to the implementation of an annotation is not stored in the CAST Analysis Service database. Note that this doesn't mean that annotation properties of classes, interfaces and ... are not stored in the CAST Analysis Service database.

Packaging /analyzing applications containing Web Services

If your JEE application contains Web Services defined in .WSDL or .WSDD files, the CAST Delivery Manager Tool will package these files correctly. However, when the version is delivered and is set as the current version in the CAST Management Studio, you must ensure that you add the .WSDL or .WSDD file extensions to the XML File Extensions list in your Analysis Unit so that they are taken into account during the analysis:

JPA 2.0/Hibernate 4

Basic or Embeddable types

Collections of Basic or Embeddable types are supported so that links between these entities and the data table is identified.


In Hibernate 4, @org.hibernate.annotations.Entity has been deprecated and the advice is to replace its individual attributes/values with annotations. For example, the following:

@Entity(dynamicUpdate = true)
Class MyEntity {

should be replaced with:

Class MyEntity {

CAST supports this change and in particular the following Quality Rules will still function correctly:

  • Avoid select-before-update when the Table is not associated to an UPDATE Trigger (7634)
  • Avoid UPDATE trigger firing when not necessary (7490)

JEE Web Apps

Support of Java Servlet annotations

The Java Servlet annotation @WebServlet introduced in JEE 1.6 (Java Servlet 3.0) is now supported by CAST AIP and links between JSP and Java files made using this annotation will be correctly resolved by CAST AIP. Important notes:

  • CAST AIP is capable of detecting @WebServlet annotations and their presence and will automatically apply the Servlet 2.5 or 3.0 options in the CAST Management Studio during the application on-boarding:

  • CAST AIP will:
    • create prototype links from the servlet to the annotated class
    • create a servlet mapping for each urlPatterns whose parent is the servlet and create an access page forward link to the servlet
    • handle any URL matching the urlPatterns to create the correctlink (on Struts - the action mapping, JSF - the managed bean), when not defined on the servlet mapping
  • Other annotations provided in the javax.servlet.annotations package are not supported, however, their presence in Application source code will not cause warnings in the analysis log.

Spring Framework

Spring 1.2.8

While using the Spring Framework 1.2.8 environment profile, the J2EE analyzer does not create objects for bean properties. As a consequence, links are created directly between beans, no matter if the reference to another bean occurs inside a property or inside an anonymous bean.

Spring 3.x

@bean and @configuration annotations are supported. For example with the following source code:

package com.sample;

@Configuration @Lazy("false")
public class AppConfig {
@Bean(autowire=NO) @Scope("prototype")
public MyService myService()

{ toto(); return new MyServiceImpl(); }


A Spring bean myService will be created with a RelyOn link to the MyServiceImpl class with the following properties:

  • singleton: false
  • lazy-init: true
  • autowire: false
  • ImplementationClass: initialized com.sample.MyServiceImpl

In addition, a RelyOn link will be created to the class com.sample.MyServiceImpl.

Struts 2.0 & 2.1 Framework

Configuration types

The following Struts configuration types are not supported:

  • By naming convention
  • By annotation

This means that the analyzer must have the struts.xml file to deduce the relations between Struts actions and Java.


OGNL: the language that permits to query objects properties from the JSP or from the XML is not supported and have the following consequences:

  • We have no links from JSP pages to the Action getter/setter methods used to fill the JSP page
  • We have no links from a Struts Action to another Struts Action when the action is specified with OGNL in the struts.xml file

Integration with Spring

When Struts 2.x is integrated with Spring, we do not deduce the action class from the spring bean specified in the XML. Links from this action to the method of the Spring implementation class will not be created.

Scope Attributes

No scope attributes for Struts 2.x are created since Struts 2.x use the value stack to get these values.

JSP 2.0

  • JSP Documents are not supported. This may lead to syntax errors during server-side and/or client-side code analysis.
  • Tag Files can be packaged in the /META-INF/tags/ directory in a JAR file installed in the /WEB-INF/lib/ directory of the web application. In this context, you should extract the Tag Files to an equivalent /META-INF/tags/ folder under your application root path (at the same level as the WEB-INF folder) before the J2EE Analyzer can process them.

EL Expressions

EL expressions for JSP 2.0 that appear in tag attribute values and template data (client-side code) are supported.

Note that EL 2.1 is not supported.

Enabling/ Disabling EL expressions

With regard to the JSP 2.0 specifications, EL expressions can be disabled in three ways (these three methods of disabling EL expressions are all supported by CAST):

  • Using the page or tag directive as follows (note that the J2EE analyzer applies this setting sequentially: true is used for the remaining of the translation unit (main .jsp page plus included files) until it finds the same directive with another value for the isELIgnored attribute).
<%@ page isELIgnored="true" %>
<%@ tag isELIgnored=" true" %> 
  • Escaping any string starting with "${" as show below:
  • Using a jsp-config element within web.xml:

What does the CAST J2EE Analyzer do with an EL expression?

An EL expression has the form ${ expression }, where expression corresponds to the expression to interpret. The expression may have one of the following forms:

${ term1 operator term2 }
${ unaire-oprator term }
${ term1 operator term2 operator term3 [operator term*]... }

Each term can be:

1) Primary Type

Since everything is an object in EL, the result of the evaluation of a primary type is its corresponding "wrapper class" (i.e. java.lang.Integer for int).

2) Implicit Objects

The following objects are implicitly created and stored in the Knowledge Base (even thought they do not actually host a child object).

  • sessionScope (hosts all session scope attributes/beans)
  • requestScope (hosts all request scope attributes/beans)
  • applicationScope (hosts all application scope attributes/beans)

They have the JSP Attributes Scope type. Other EL implicit objects deal with HTTP headers/request parameters and cookies. Since no object is created elsewhere for these elements (not supported yet), they are also not taken into account while analyzing EL expressions (resolution would never succeed).

With the example:

  • ${ sessionScope["book"].title}

...the analyzer will look for a bean named book within the session scope (as child of the sessionScope Object) and only within that scope. If the lookup is successful then:

  • A Bean Property object named title is created as a child of the book bean.
  • Let T be the java Type of the book bean and F a method we will look for within T.

If T is a List (implements java.util.List) or a Map (implements java.util.Map) then F is get (java.lang.Object). Otherwise F is getTitle() (Title is the property name). If F could be resolved within T, let TF be the return type of F. The following links are created:

CallerCalledLink Type
  • ( getTitle()
  • get(…))

This process is applied recursively for each part of a qualified bean property name. Note that for expressions within braces ([expression]) that use operators, only the "+" is interpreted if its operands are literals. Hence, ${sessionScope["book" + 1].title} will work fine if there is a "book1" bean within the session scope.

In other cases, evaluation results to an empty string. This is because there is not yet a reliable way to get actual attributes values.

3) Scope attributes

If a term within an expression does not correspond to an implicit object or a primitive type then it is resolved as a scoped attribute (a bean within a scope) in the following scopes: page, session, request then application.

If the term is a qualified bean property name then it is handled as described in the previous paragraph (2) Implicit Objects).



In this example, book is resolved as a scoped attribute (bean). If resolution succeeds, then a bean property is created.

EL Functions

EL functions are Tag Library Descriptor elements. Hence, they are created by the CAST J2EE Analyzer when parsing the containing .tld file. These objects are stored in the Analysis Service and have the JSP EL Function type. An EL Function is used as follows:

${ prefix:FunctionName ( [parameters...] ) }

When a reference to an EL Function is made in an expression, the analyzer resolves the function using the same mechanism it uses for custom tags:

  • The prefix is used to find the tld
  • The function is then searched for within the found tld.

The table and image below summarize the links/objects that are created:

CallerCalledLink TypeWhen
JSP PageFunctionUseWhile analyzing EL expression
FunctionJava MethodPrototypeWhile analyzing .tld

Using EL Function in a JSP page:

Support for JSE Generics

The J2EE Analyzer supports JSE Generics in Java . This section provides detailed information about the various objects that are created during an analysis and how the information is displayed in CAST Enlighten (both in the Object Manager and in the Graphical View):


The following "Generics" specific objects are created by the analyzer:

IconObject typeObject example
Generic Classjava.util.HashSet<E>
Generic Constructorstatic <T> void fromArrayToCollection(T[] a, Collection<T> c)
Generic Interfacejava.util.Set<T>
Generic Methodstatic <T> void fromArrayToCollection(T[] a, Collection<T> c)
Generic Type Parameterjava.util.Set<T>
Instantiated Classjava.util.Set<String>
Instantiated ConstructorfromArrayToCollection<String>(String[] a, Collection<String> c)
Instantiated Interfacejava.util.Set<String>
Instantiated MethodfromArrayToCollection<String>(String[] a, Collection<String> c)

Display in CAST Enlighten Object Manager

Java Generics are displayed in the CAST Enlighten Object Manager as shown in the image below:

The following information also applies:

  • The Generic Java classes and interfaces appear under the Java file that defines them
  • The Generic Java methods, constructors and type parameters appear under the class or interface that defines them like a normal class
  • The Java instantiated classes and interfaces appear in a subfolder called Instantiation. So, even if the declaration of an instantiated generic class or interface is in a specific file, this class will not appear in the folder related to this file. This is because: it is possible to have the same instantiation in various different files (not just one), and secondly, all the code is in the Generic class and not the instantiated generic class. In addition, it is possible to see whether a Generic class is used or not.
  • The Java instantiated constructors and methods also appear as a child of the folder named with the generic constructor or method.
  • The generic Java type parameter appears under the Generic class, interface, constructor or method that defines it. Note that its name has been prefixed with the name of the component that defines it to avoid a situation where many Java type parameters appear with the same name T, U etc.
Note that the methods and fields of instantiated classes and interfaces are not represented since their actual implementation is located in the generic class or interface.

Display in the CAST Enlighten Graphical View

Java Generics are displayed in the CAST Enlighten Graphical View as follows:

Impacts on Quality Rules

Generic classes, methods and constructors are counted as a standard Java classes, methods and constructors because all the code is inside these objects. Quality Rules will apply to these Generic object types exactly as with any other Java objects. Instantiated classes, methods and constructors are not counted as classes, methods and constructors because they do not handle any code (there is no effort to maintain them), this is why they appear in a specific category.

JavaScript support

The J2EE analyzer supports the analysis of JavaScript delivered with the J2EE project files. Please see the JavaScript section in Web technologies.

CDI support

The J2EE analyzer supports CDI (Contexts and Dependency Injection) as follows:

  • Supported versions 1.0, 1.1 and 1.2
  • The following annotations/scopes are supported:
    • @Inject
    • @Named
    • @Produces
    • @Qualifier
    • All scopes, including the following standard scopes
      • @SessionScoped
      • @RequestScoped
      • @Dependent
    • Custom scopes built from:
      • @Scope
      • @NormalScope
  • @Named CDI beans used in place of JSF specific injection features (@ManagedBean annotated classes) are supported
  • CDI Beans are resolved and saved in the CAST Analysis Service schema whenever a bean qualifier or scope is used to annotate a class.
  • Links:
    • A Rely On link will be created from the annotated class (with a scope and/or a qualifier) to the bean.
    • When there is an injection of a class on a field using the @Inject annotation, a Fire link is created from the object the field is injected into, to the constructor(s) of the injected type(s). Though CDI only allows one type to match the injection constraints, many links can be drawn in case of ambiguity, for instance if projects embed more objects than the development environment.

  • In order for support of CDI to function, in the CAST Management Studio, at Analysis Unit level, the following options must be set:
    • Java Version option must be set to a minimum of JDK 6.0
    • Is CDI used must be set to YES (default position)
    • JSP/Servlet standard version must be set to Servlet 3.0/JSP2.0

Additional notes

The following section lists technical and functional aspects with regard to analysis of J2EE source code:

Please also see Web technologies for more information about web technology specifics (i.e. XHTML, JScript, JavaScript).

Funnel programming and Strongly Connected Components

Where "funnel programming" causes Strong Connected Components (SCC - see Transaction Configuration Center - Information - Definition and impacts of the large Strongly Connected Component) a number of ambiguous links may be generated during an analysis. This can in turn cause erroneous Function Point values for Transactions.

Example of "funnel programming":

  • An abstract class called "ABS" exists.
  • All of its methods are abstract, except "processFlow", which is implemented. 
  • "ABS.processFlow" calls methods "ABS.method1", "ABS.method2" and "ABS.method3" (which are abstract)
  • Classes "B", "C" and "D" inherit class "A"
  • All their methods are overriden but "processFlow" ("processFlow" is already implemented in "A")
  • A method "methodFromZ" from class "Z" does the following:
public methodFromZ(){
  B myB = new B();
  • The analyzer will draw a link from "methodFromZ" to "ABS.processFlow", and then "ABS.processFlow" will have a link to "B.method1", "C.method1", "D.Method1", "B.Method2", "C.Method2", "D.method1", "D.Method2" which will resemble a "funnel" when viewed in CAST Enlighten.
  • CAST recommends creating an "Update CAST Knowledge Base" tool job (Content Enrichment editor in the CAST Management Studio) to remediate situations where Strongly Connected Components exist.
  • The TF Graph Adjustment feature in the CAST Transaction Configuration Center can help reduce the impact of Strongly Connected Components.

Anonymous classes

Objects are not saved in the CAST Analysis Service schema for anonymous classes and their sub-objects. For example, for the following code where an anonymous class implementing interface "MyInterface" is dynamically created. There will be no object dsaved in the CAST Analysis Service for this anonymous class, nor for the overriding method "doSomething".

post( new MyInterface(){
	public void doSomething(){

Java Identifiers containing the '$' character

Identifiers containing the '$' character: '$' is used by java compilers as a class name delimiter in inner class file generation. It is also a legal java character authorized in class names. When reversing class files containing a reference to a class name with a '$', the analyzer can not determine if the '$' should be kept as is or interpreted as a '.' delimiter. It always takes the '.' alternative, meaning that "C$D" will always be interpreted as inner class "D" of class "C". The impact on the analyzer is that the '$' character is not supported in class names reversed from class files. However it is supported for code defined in java source files.

Overloaded Java methods

J2EE Analyzer cannot distinguish two overloaded methods if the signature (i.e. the name + parameters) of one of them exceeds 1024 characters. Both methods will be considered as one single method and links will be created for only one of them.

JSP Syntax

JSP comments are not supported within the body of an action (custom and standard).

Incorrect JSE registry key in the environment profile

When the registry key specified in a J2EE Environment Profile does not correspond to the real registry key used by the JSE installed on the analysis PC, you should duplicate the Environment Profile of the JSE version that you want to use and reference there the rt.jar of the JSE installed on your machine. Note that duplication is required to ensure that the parameterization related to JSE will be effective for this profile.

Java code in a JSP tag

When analyzing JSP expressions that are the value of attributes in a tag, the analyzer may try to identify a bean with the same name as the java code. The analyzer will not find this bean in the scope as it does not exist.
Take the following JSP example:

<logic:equal name="<%=Colors.KEY_COLOR%>" value="<%=Colors.RED%>">

When this code is analyzed by the J2EE Analyzer, the log will contain the following warning:

Bean 'KEY_COLOR%>' not found in scope

Tag Libraries

J2EE Analyzer is unable to take into account attributes that are IMPLIED. This occurs when the TLD references a DTD that contains IMPLIED attributes. When the analyzer encounters such attributes in a JSP page, it gives the following error message in the log: "Attribute 'xxx' is not valid for custom tag 'yyy'". Workaround: Modify the TLD and add all IMPLIED attributes with their values defined in the DTD. This allows J2EE Analyzer to correctly parse the TLD.

Links between tag attributes and JavaScript functions

The J2EE analyzer does not create links between tag attributes and JavaScript functions, for example:

  • A .tag file defines some JSP content, in which HTML 5 content is defined. This content includes a call to a JavaScript function.
  • A JSP file refers to this tag, which is expanded to code including a call to the JavaScript function

Supported path resolution for links between JSP files and JSP or JavaScript files/functions

The JEE analyzer supports the following path configuration rules in JSP source files:

  • If the path starts with a slash ("/"), then this refers to the Web Application Root Path (as configured in the CAST Management Studio)
  • If not, the path is a relative to the folder containing the current file

If the above rules are adhered to, then the analyzer will correctly resolve links between JSP files and the following components:

  • other JSP files
  • JavaScript files and functions

If any other path resolution rule is used, links will not be created.

No link bookmarks generated

When Java Methods are defined inside a JSP file, no link bookmarks are generated (bookmarks can be seen in CAST Enlighten or in the Dynamic Link Manager). Example of a Java Method defined in a JSP file:

<%@ page language="Java" %>
public void myMethod(String message)
{ System.out.println(message); }

JSON/AJAX support

The JEE Analyzer does not support .json/AJAx syntax used in JavaScript files, for example:


    		type: "POST",   
    		url: "saveColumnAdSolutions",   
        	data: "ColumnValue="+totalColumn,
        	async: true,  
    		cache: false,  
        	success: function (msg) {  
  • No labels