Detailed technology support

Language Version	Supported	Comments
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
Hibernate: 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
CDI: 1.0, 1.1, 1.2		See section below for more information.

Required third-party software

To successfully deliver and analyze J2EE technologies, the following third-party software is 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:

Objects

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 File
	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
	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
	Tiles Configuration File
	Tiles Definition Attribute
	Tiles Definition
	Validation Form
	Validation Form Field
	Validation Forms Set
	XML Bean

Java pure

EJB

Web Services

Links

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

<%@ taglib uri="/examples-taglib" prefix="eg"%>

<%@ include file="URL"%>

<%@ page extends="com.cast.SuperClass"%>

<%@ page errorPage="URL"%>

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

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

<eg:foo attr1="value"/>

<jsp:forward page="URL"/>

<jsp:include page="file"/>

<jsp:useBean id="clock" class="beans.clockBean" ... />

<jsp:useBean id="clock" class="beans.clockBean" ... />

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

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

<!--METADATA TYPE = "TypeLib" FILE = "TypLibFileName" -->

<APPLET CODE = "AppletCode" CODEBASE = "AppletCodeBase" >

x = new ActiveXObject("A.B")
function f()
{
x.Method()

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

<SCRIPT>
ExecuteSQL("select * from authors")
</SCRIPT>

<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">
</map>

function f()
{
return CreateObject("A.B")
}

function f()
{
return new g()
}

<SCRIPT LANGUAGE = "JavaScript" SRC = "inc.js">
</SCRIPT>

<A HREF = "called_file.htm" ></A>
<SCRIPT LANGUAGE = JavaScript>
window.open("called_file.htm")
</SCRIPT>

<SCRIPT>
function f()
{
return 1;
}
function g()
{
return f()
}
</SCRIPT>

<PUBLIC:PROPERTY NAME="xmlData"
 ID="xmlDataID" 
GET="getxmlData" PUT="putxmlData"/>

<!--#FLASTMODE FILE = "accessed_file.htm">

<SCRIPT>
function f()
{
y=x
}
</SCRIPT>

<SCRIPT>
function f()
{
y=x
}
</SCRIPT>

<SCRIPT>
x = new ActiveXObject("A.B")
Application("y")=x
</SCRIPT>

<SCRIPT>
x=new ActiveXObject("A.B")
</SCRIPT>

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

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"; %>

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:

<entity>
   <ejb-name>CustomerBean</ejb-name>
   ...
   <abstract-schema-name>Customer</abstract-schema-name>
   ...
   <query>
      <query-method>
         <method-name >findByFirstName</method-name>
         <method-params>
            <method-param>java.lang.String</method-param>
         </method-params>
      </query-method>
      <ejb-ql>SELECT DISTINCT OBJECT(c) FROM Customer AS c WHERE c.firstName = ?1</ejb-ql>
   </query>
</entity>

<entity id="ContainerManagedEntity_1">
   <ejb-name>PlayerEJB</ejb-name>
   ...
   <abstract-schema-name>Player</abstract-schema-name>
   ...

<webservices ...>
   <webservice-description>
      ...
      <webservice-description-name>MyHelloService</webservice-description-name>
      <jaxrpc-mapping-file>mapping.xml</jaxrpc-mapping-file> // relatif ou absolu
      <port-component>
      ...
         <port-component-name>HelloIF</port-component-name>
         <service-endpoint-interface>helloservice.HelloIF</service-endpoint-interface>
         <service-impl-bean>
            <ejb-link>HelloServiceEJB</ejb-link>
         </service-impl-bean>
      </port-component>
   </webservice-description>
</webservices>

<java-wsdl-mapping ...>
...
      <port-mapping>
         <port-name>HelloIFPort</port-name>
      </port-mapping>
   </service-interface-mapping>
   <service-endpoint-interface-mapping>
      <service-endpoint-interface>helloservice.HelloIF</service-endpoint-interface>
      <service-endpoint-method-mapping>
         <java-method-name>sayHello</java-method-name>
         <wsdl-operation>sayHello</wsdl-operation>
            <method-param-parts-mapping>
               <param-position>0</param-position>
               <param-type>java.lang.String</param-type>
               ...
               </method-param-parts-mapping>
   </service-endpoint-method-mapping>
   </service-endpoint-interface-mapping>
</java-wsdl-mapping>

<entity> //ou session ou message-driven
   <ejb-name> AddressBean</ejb-name>
   <ejb-ref> //ou ejb-local-ref
      <ejb-ref-name>ejb/CustomerRef</ejb-ref-name>
      ...
      <ejb-link>CustomerBean</ejb-link>
   </ejb-ref>
</entity>

<ejb-relation>
  <description>Team To Player</description>
  <ejb-relation-name>PlayerEJB.teams-TeamEJB.players</ejb-relation-name>
  <ejb-relationship-role>
     <ejb-relationship-role-name>TeamEJB</ejb-relationship-role-name>
     <multiplicity>many</multiplicity>
     <relationship-role-source>
         <ejb-name>TeamEJB</ejb-name>
     </relationship-role-source>
     <cmr-field>
        <cmr-field-name>players</cmr-field-name>
        <cmr-field-type>java.util.Collection</cmr-field-type>
     </cmr-field>
  </ejb-relationship-role>
 
  <ejb-relationship-role>
     <ejb-relationship-role-name>PlayerEJB</ejb-relationship-role-name>
     <multiplicity>many</multiplicity>
     <relationship-role-source>
        <ejb-name>PlayerEJB</ejb-name>
     </relationship-role-source>
     <cmr-field>
        <cmr-field-name>teams</cmr-field-name>
        <cmr-field-type>java.util.Collection</cmr-field-type>
     </cmr-field>
  </ejb-relationship-role>
</ejb-relation>

Web services links

<portType name="ServerSoapPort">
    ...
</portType>
<binding name="ServerSoapBinding" type="wsdlns:ServerSoapPort">
    ...
</binding>
<service name="CodaServices">
    <port name="ServerSoapPort" binding="wsdlns:ServerSoapBinding">
    <soap:address location="http://demeter:80/TestDCom/CodaServices.WSDL"/>
    </port>
</service>

<portType name="ServerSoapPort">
    <operation name="ProcessAccount" parameterOrder="objAccount">
    </operation>
</portType>
<binding name="ServerSoapBinding" type="wsdlns:ServerSoapPort">
    ...
</binding>
<service name="CodaServices">
    <port name="ServerSoapPort" binding="wsdlns:ServerSoapBinding">
        <soap:address location="http://demeter:80/TestDCom/CodaServices.WSDL"/>
    </port>
</service> 

<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"/>
    </service>
</deployment >

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

Technology support notes

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

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.

@org.hibernate.annotations.Entity

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:

@Entity
@SelectBeforeUpdate
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

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.

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:

\${customer.name}

• Using a jsp-config element within web.xml:

<jsp-config>
    <jsp-property-group>
        <url-pattern>/jsp/cal/cal1.jsp</url-pattern>
        <el-ignored>true</el-ignored>
    </jsp-property-group>
</jsp-config>

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:

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

Example:

<tr>
    <td>${book.title}</td>
    <td>${my:caps(book['title'])}</td>
</tr>

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:

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

Objects

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

Icon	Object type	Object example
	Generic Class	java.util.HashSet<E>
	Generic Constructor	static <T> void fromArrayToCollection(T[] a, Collection<T> c)
	Generic Interface	java.util.Set<T>
	Generic Method	static <T> void fromArrayToCollection(T[] a, Collection<T> c)
	Generic Type Parameter	java.util.Set<T>
	Instantiated Class	java.util.Set<String>
	Instantiated Constructor	fromArrayToCollection<String>(String[] a, Collection<String> c)
	Instantiated Interface	java.util.Set<String>
	Instantiated Method	fromArrayToCollection<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.

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:

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

Bean 'KEY_COLOR%>' not found in scope