On this page:

Target audience:

Users of the extension providing JEE analysis support.

Summary: This section provides more detail about the support for specific JEE technologies and the way in which the JEE Analyzer extension handles them.

Java JDK

CAST supports the analysis of Java JDK with some limitations. These limitations are listed below, but are not exhaustive:

JPA / Hibernate

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:

JPA 2.1 / Hibernate 4.3 - 5.x

Access to database stored procedures using one of the below mechanisms is now supported:

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:

Note that by default, the analyzer will assume that the source code always uses the latest JEE Servlet release, however, this can be overridden and a specific release can be selected:

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:

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

Spring 4.x

Includes support for @Query annotation.

Spring Batch

Spring Batch is supported as standard by the JEE Analyzer: by default, Spring frameworks present in the delivered source code will be analyzed and objects / links relating to Spring Batch will be detected and stored in the results:

Objects detected:

Links resolved:

Spring Batch extension also exists which provides dedicated support for the Spring Batch framework. CAST highly recommends that you install and use this extension if your application contains Spring Batch source code:

  • No further development of Spring Batch support will be added in any future release of the JEE Analyzer - all future development will be done in the Spring Batch extension
  • Any Spring Batch related objects created by the JEE Analyzer will be deleted and replaced with corresponding objects created by the Spring Batch extension. You should therefore expect a small impact on existing analysis results in terms of the number of added/deleted objects.

Struts Framework


Support includes the following annotations:


Configuration types

The following Struts configuration types are not supported:

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:

Scope Attributes

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


Support for classic JSP via the HTML5/JavaScript extension

CAST recommends using the HTML5 and JavaScript extension to analyze classic JSP applications (JSP versions 1.1 - 2.3) - this is because the JEE Analyzer is not capable of analyzing the JavaScript elements of the JSP application. Below is a screenshot of the analysis of a classic JSP application using the HTML5/JavaScript extension - click to enlarge:

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):

<%@ page isELIgnored="true" %>
<%@ tag isELIgnored=" true" %> 

What does the JEE 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).

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:

...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:

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 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:

JSE Generics

The JEE 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 Java Classjava.util.HashSet<E>

Generic Java Constructorstatic <T> void fromArrayToCollection(T[] a, Collection<T> c)

Generic Java Interfacejava.util.Set<T>

Generic Java Methodstatic <T> void fromArrayToCollection(T[] a, Collection<T> c)

Generic Java Type Parameterjava.util.Set<T>

Java Instantiated Classjava.util.Set<String>

Java Instantiated ConstructorfromArrayToCollection<String>(String[] a, Collection<String> c)

Java Instantiated Interfacejava.util.Set<String>

Java 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:

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.

CDI support

The JEE Analyzer supports CDI (Contexts and Dependency Injection) out of the box. No configuration is necessary.

Web Services

If your JEE application contains Web Services defined in .WSDL or .WSDD files, the CAST Delivery Manager Tool will identify and package these files correctly according to their extension:

Creation of objects / links

The extension will store (in the CAST Analysis Service schema) objects that represent the description of Web Services using only the contents of WSDL files

These objects include:

There is no correlation between the language used to implement the Web Services and the objects stored in the CAST Analysis Service schema.

Belongs To links and those that follow (Internal links) are created during this initial phase:

  1. Port == Hi ==> Port Type  (i)
  2. Port == U ==> Operation  (ii)

The extension will resolve and create implementation links (External links) for the Web Services components stored in the Analysis Service

The link type created is the same for all implementations and should be as follows:

  1. Port Type == P ==> Object1 (iii)
  2. Operation == P ==> Object2 (iv)

How are these objects and links constructed?

Objects (Phase 1): Objects result from the analysis of the WSDL files. During this analysis, only the "local names" are taken into account and the files must conform to WSDL 1.1 specifications. The internal link Inherit-Implement (i) is created via a Binding object (represented in the Graphical View but not stored in the Analysis Service schema) that associates the port with a Port Type as follows:

Port > Binding > Port Type

The association Port > Binding is specified in the value of the binding attribute in the tag <port> that declares the Port. This value is a reference in the form prefix:name - the part in bold (prefix) is optional and variable. Only the name is taken into account for the resolution of the corresponding Binding.

The second association is also specified in a similar way, but instead via the value of the type attribute in the <binding> element that declares the Binding. The format is identical and only the name is taken into account in the resolution of the Port Type.

The internal link Use (ii) results from the Belongs To link between the Operations and the Port Type. However, for each Operation under the Port Type that was found in the first phase, a Prototype link will be created from the Port.

External Links (Phase 2): The external links go from the web service objects to the objects of the implementation language (VB, Java etc.)

These links are created on the basis of the correspondence files. These files are, generally, XML files but their format differs from one language to another. As a result, the extension needs to already know the format of these files in their different versions for all the supported languages and thus support of new languages would normally require the revision of the Web Services Asst. code. In order to work around this constraint, a format that is unique to the extension has been developed: an XSLT file is used to transform these files from their proprietary format into the format used by the extension. In order to do this, the extension requires the mapping files to actually transform and the XSLT files to do the transforming. Together these elements are known as Mapping File Profiles to which two labels can be associated (language name and a succinct description of the format of the mapping files) - these two labels are used for identification and selection of the Profile.

How is the support provided?

Support for Web Services is provided through the Environment Profile feature. Assign a Web Services Environment Profile via the Web Service Version drop down list in the JEE - Analysis configuration (Analysis tab), under Frameworks:

What about Mapping Files

In the case of VB the mapping files coincide with the WSDL files. However, their format does not specify a PortType > Language object mapping. The only mappings actually specified are:

These elements can be found in the value of the soapAction attribute in the tag binding/operation/XXX:operation where XXX: is a variable and optional prefix (soap, wsdlSoap etc.).

In order to function correctly, the Web Services Asst. requires the following information:

Entity Java Bean5150
Generic Java Class5040
Generic Java Constructor5050
Generic Java Interface5030
Generic Java Method5070
Generic Java Type Parameter5045
Java Class5040
Java Constructor5050
Java Data Object5180
Java Enum5040
Java Enum Item5060
Java Field5060
Java File5170
Java Import5171
Java Initializer5080
Java Instantiated Class5042
Java Instantiated Constructor5055
Java Instantiated Interface5035
Java Instantiated Method5075
Java Interface5030
Java Method5070
Java Package5020
Java Project5010
Message Driven Java Bean5165
Session Java Bean5160

This information is thus extracted from the mapping files during the transformation process. For Java, this name must be present in the WSDD - if no name exists, the resolution process will stop on the first web component of the type being searched with the name being searched. Please note that the Port Type names appear under the element <service> with the attribute name.

The search for external objects (those specific to each language) follows the Dependency Rules defined in the Dependencies tab in the CAST Management Studio - only those objects associated with the project currently being analyzed must be selected.

Please note that the analyses that create the external objects must have already been executed.


CAST can support Enterprise Java Beans (EJB) deployment files to EJB 2.02.1 and 3.x specifications. Support is achieved by creating the EJB object and map it with the Java classes constituting the bean (bean class, local and remote interfaces and, for entity beans, primary key class) based on their fully qualified name. Beans are registered in the Analysis Service with their logical name independently of their constituting classes.

How is support provided?

Support for EJB is provided through predefined Environment Profiles:

EJB 2.x

The JEE Analyzer supports EJB 2.x specifications and the Web Services support they provide via a varierty of Environment Profiles.

Each EJB 2.x environment profile:

EJB 3.x

Includes support for JSR 330 @Inject and @Named annotations.

See EJB 3.x based application.



In the maven dependency, the version should be defined or inherited from the parent. Check the packaging of the source code

When packaging a J2EE Maven resource package, if a pom file has a parent, the parent file is not scanned and we may have the following warning message in the discoverer log file:

In the maven dependency, the version should be defined or inherited from the parent. Check the packaging of the source code.

This is a limitation, the parent pom files are not scanned.

Note that this limitation has been removed in CAST AIP ≥ 8.3.8.

Additional notes

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

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":

public methodFromZ(){
  B myB = new B();

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 saved 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 unsupported syntax

Comments within the body of an action

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

Use of conditional <c:if> in a <div> element

The use of a conditional <c:if> in a <div> element is not supported and will cause a syntax error when analyzed. For example:

<div <c:if test="${not empty currentNode.properties.classNames}">
   	 <c:if test="${not empty currentNode.properties.classId}"> 
   	</c:if> >
   	<template:area path="content_${currentNode.name}"/>

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.

Supported path resolution for links between JSP files

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

If the above rules are adhered to, then the analyzer will correctly resolve links between JSP files and other JSP files.

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