6 Configuring Resources in a Web Application
This chapter includes the following sections:
Configuring Resources in a Web Application
The resources that you use in a Web application are generally deployed externally to the Web application. JDBC data sources can optionally be deployed within the scope of the Web application as part of an EAR file.
To use external resources in the Web application, you resolve the JNDI resource name that the application uses with the global JNDI resource name using the web.xml
and weblogic.xml
deployment descriptors. (The web.xml
file is located in the WEB-INF
directory of your Web application.) See Configuring Resources for more information.
You can also deploy JDBC data sources as part of the Web application EAR file by configuring those resources in the weblogic-application.xml
deployment descriptor. Resources deployed as part of the EAR file with their scope defined as application are referred to as application-scoped resources. These resources remain private to the application, and application components can access the resource names by adding <resource-ref>
elements as explained in Configuring Resources.
Configuring Resources
When accessing resources such as a data source from a Web application through Java Naming and Directory Interface (JNDI), you can map the JNDI name you look up in your code to the actual JNDI name as bound in the global JNDI tree. This mapping is made using both the web.xml
and weblogic.xml
deployment descriptors and allows you to change these resources without changing your application code. You provide a name that is used in your Java code, the name of the resource as bound in the JNDI tree, and the Java type of the resource, and you indicate whether security for the resource is handled programmatically by the servlet or from the credentials associated with the HTTP request. You can also access JMS module resources, such as queues, topics, and connection factories.
For more information see, Configuring JMS Application Modules for Deployment in Administering JMS Resources for Oracle WebLogic Server.
To configure resources:
Example 6-1 Using an External DataSource
servlet code: javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup ("myDataSource"); web.xml entries: <resource-ref> . . . <res-ref-name>myDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>CONTAINER</res-auth> . . . </resource-ref> weblogic.xml entries: <resource-description> <res-ref-name>myDataSource</res-ref-name> <jndi-name>accountDataSource</jndi-name> </resource-description>
Referencing External EJBs
Web applications can access EJBs that are deployed as part of a different application (a different EAR file) by using an external reference. The EJB being referenced exports a name to the global JNDI tree in its weblogic-ejb-jar.xml
deployment descriptor. An EJB reference in the Web application module can be linked to this global JNDI name by adding an ejb-reference-description
element to its weblogic.xml
deployment descriptor.
This procedure provides a level of indirection between the Web application and an EJB and is useful if you are using third-party EJBs or Web applications and cannot modify the code to directly call an EJB. In most situations, you can call the EJB directly without using this indirection. See Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
To reference an external EJB for use in a Web application:
More about the ejb-ref* Elements
The ejb-ref
element in the web.xml
deployment descriptor declares that either a servlet or JSP is going to be using a particular EJB. The ejb-reference-description
element in the weblogic.xml
deployment descriptor binds that reference to an EJB, which is advertised in the global JNDI tree.
The ejb-reference-descriptor
element indicates which ejb-ref
element it is resolving with the ejb-ref-name
element. That is, the ejb-reference-descriptor
and ejb-ref
elements with the same ejb-ref-name
element go together.
With the addition of the ejb-link
syntax, the ejb-reference-descriptor
element is no longer required if the EJB being used is in the same application as the servlet or JSP that is using the EJB.
The ejb-ref-name
element serves two purposes in the web.xml
deployment descriptor:
-
It is the name that the user code (servlet or JSP) uses to look up the EJB. Therefore, if your
ejb-ref-name
element isejb1
, you would perform a JNDI name lookup forejb1
relative tojava:comp/env
. Theejb-ref-name
element is bound into the component environment (java:comp/env
) of the Web application containing the servlet or JSP.Assuming the
ejb-ref-name
element isejb1
, the code in your servlet or JSP should look like:Context ctx = new InitialContext(); ctx = (Context)ctx.lookup("java:comp/env"); Object o = ctx.lookup("ejb1"); Ejb1Home home = (Ejb1Home) PortableRemoteObject.narrow(o, Ejb1Home.class);
-
It links the
ejb-ref
andejb-reference-descriptor
elements together.
Referencing Application-Scoped EJBs
Within an application, WebLogic Server binds any EJBs referenced by other application components to the environments associated with those referencing components. These resources are accessed at run time through a JNDI name lookup relative to java:comp/env
.
The following is an example of an application deployment descriptor (application.xml
) for an application containing an EJB and a Web application, also called an Enterprise Application. (For the sake of brevity, the XML header is not included in this example.)
Example 6-2 Example Deployment Descriptor
<application> <display-name>MyApp</display-name> <module> <web> <web-uri>myapp.war</web-uri> <context-root>myapp</context-root> </web> </module> <module> <ejb>ejb1.jar</ejb> </module> </application>
To allow the code in the Web application to use an EJB in ejb1.jar
, the Java EE standard Web application deployment descriptor, web.xml
, must include an ejb-ref
stanza that contains an ejb-link
referencing the JAR file and the name of the EJB that is being called.
The format of the ejb-link
entry must be as follows:
filename#ejbname
where filename
is the name of the JAR file, relative to the Web application, and ejbname
is the EJB within that JAR file. The ejb-link
element should look like the following:
<ejb-link>../ejb1.jar#myejb</ejb-link>
Note that since the JAR path is relative to the WAR file, it begins with "../
". Also, if the ejbname
is unique across the application, the JAR path may be dropped. As a result, your entry may look like the following:
<ejb-link>myejb</ejb-link>
The ejb-link
element is a sub-element of an ejb-ref
element contained in the Web application's web.xml
descriptor. The ejb-ref
element should look like the following:
Example 6-3 <ejb-ref> Element
<web-app> ... <ejb-ref> <ejb-ref-name>ejb1</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>mypackage.ejb1.MyHome</home> <remote>mypackage.ejb1.MyRemote</remote> <ejb-link>../ejb1.jar#myejb</ejb-link> </ejb-ref> ... </web-app>
Referring to the syntax for the ejb-link
element in the above example,
<ejb-link>../ejb1.jar#ejb1</ejb-link>,
the portion of the syntax to the left of the #
is a relative path to the EJB module being referenced. The syntax to the right of #
is the particular EJB being referenced in that module. In the above example, the EJB JAR and WAR files are at the same level.
The name referenced in the ejb-link
(in this example, myejb
) corresponds to the ejb-name
element of the referenced EJB's descriptor. As a result, the deployment descriptor (ejb-jar.xml
) of the EJB module that this ejb-ref
element is referencing should have an entry similar to the following:
Example 6-4 <ejb-jar> Element
<ejb-jar> ... <enterprise-beans> <session> <ejb-name>myejb</ejb-name> <home>mypackage.ejb1.MyHome</home> <remote>mypackage.ejb1.MyRemote</remote> <ejb-class>mypackage.ejb1.MyBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> ... </ejb-jar>
Notice the ejb-name
element is set to myejb
.
At run time, the Web application code looks up the EJB's JNDI name relative to java:/comp/env
. The following is an example of the servlet code:
MyHome home = (MyHome)ctx.lookup("java:/comp/env/ejb1");
The name used in this example (ejb1) is the ejb-ref-name defined in the ejb-ref
element of the web.xml
segment above.
Serving Resources from the CLASSPATH with the ClasspathServlet
If you need to serve classes or other resources from the system CLASSPATH
, or from the WEB-INF/classes
directory of a Web application, you can use a special servlet called the ClasspathServlet
. The ClasspathServlet
is useful for applications that use applets or RMI clients and require access to server-side classes. The ClasspathServlet
is implicitly registered and available from any application.
The ClasspathServlet
is always enabled by default. To disable it, set the ServerMBean
parameter ClassPathServletDisabled
to true
(default = false
).
The ClasspathServlet
returns the classes or resources from the system CLASSPATH
in the following order:
-
WEB-INF/classes
-
JAR files under
WEB-INF/lib/*
-
system
CLASSPATH
To serve a resource from the WEB-INF/classes
directory of a Web application, call the resource with a URL such as:
http://server:port/myWebApp/classes/my/resource/myClass.class
In this case, the resource is located in the following directory, relative to the root of the Web application:
WEB-INF/classes/my/resource/myClass.class
Note:
WebLogic Server provides a secured production mode that enforces more restrictive and stringent security settings to ensure less vulnerability to threats. The ServerTemplateMBean
includes a ClasspathServletSecureModeEnabled
attribute that, when secure mode is enabled, will serve only class files from well known packages required for JDBC and JMS functionality.
If secure mode is disabled, do not place any resources or classes that should not be publicly available in any of the locations listed above that the ClasspathServlet
serves.
As of the April 2021 Patch Set Update (PSU), the ClasspathServletSecureModeEnabled
attribute is set to true
by default.
Using CGI with WebLogic Server
WebLogic Server supports all CGI scripts through an internal WebLogic servlet called the CGIServlet
. To use CGI, register the CGIServlet
in the Web application deployment descriptor.
See Configuring How a Client Accesses a Web Application.
Note:
WebLogic Server provides functionality to support your legacy Common Gateway Interface (CGI) scripts. For new projects, Oracle recommends that you use HTTP servlets or JavaServer Pages.
Configuring WebLogic Server to Use CGI
To configure CGI in WebLogic Server:
Example 6-5 Example Web Application Deployment Descriptor Entries for Registering the CGIServlet
<servlet> <servlet-name>CGIServlet</servlet-name> <servlet-class>weblogic.servlet.CGIServlet</servlet-class> <init-param> <param-name>cgiDir</param-name> <param-value> /bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin </param-value> </init-param> <init-param> <param-name>*.pl</param-name> <param-value>/bin/perl.exe</param-value> </init-param> </servlet> ... <servlet-mapping> <servlet-name>CGIServlet</servlet-name> <url-pattern>/cgi-bin/*</url-pattern> </servlet-mapping>
Requesting a CGI Script
The URL used to request a Perl script must follow the pattern:
http://host:port/myWebApp/cgi-bin/myscript.pl
Where
host:port
—Host name and port number of WebLogic Server.
myWebApp
—Name of your Web application.
cgi-bin
—url-pattern
name mapped to the CGIServlet
.
myscript.pl
—Name of the Perl script that is located in the directory specified by the cgiDir
initialization attribute.