J2EE

Q: What is the Java 2 Platform, Enterprise Edition (J2EE)?

Java 2 Platform, Enterprise Edition (J2EE) is a set of coordinated specifications and practices that together
enable solutions for developing, deploying, and managing multi-tier server-centric applications. Building
on the Java 2 Platform, Standard Edition (J2SE), J2EE adds the capabilities necessary to provide a
complete, stable, secure, and fast Java platform to the enterprise level. It provides value by significantly
reducing the cost and complexity of developing and deploying multi-tier solutions, resulting in services that
can be rapidly deployed and easily enhanced.

Q: What are the main benefits of J2EE?

J2EE provides the following:

1. Faster solutions delivery time to market. J2EE uses "containers" to simplify development. J2EE
containers provide for the separation of business logic from resource and lifecycle management,
which means that developers can focus on writing business logic -- their value add -- rather than
writing enterprise infrastructure. For example, the Enterprise JavaBeans (EJB) container
(implemented by J2EE technology vendors) handles distributed communication, threading,
scaling, transaction management, etc. Similarly, Java Servlets simplify web development by
providing infrastructure for component, communication, and session management in a web
container that is integrated with a web server.
2. Freedom of choice. J2EE technology is a set of standards that many vendors can implement. The
vendors are free to compete on implementations but not on standards or APIs. Sun supplies a
comprehensive J2EE Compatibility Test Suite (CTS) to J2EE licensees. The J2EE CTS helps
ensure compatibility among the application vendors which helps ensure portability for the
applications and components written for J2EE. J2EE brings Write Once, Run Anywhere (WORA)
to the server.
3. Simplified connectivity. J2EE technology makes it easier to connect the applications and systems
you already have and bring those capabilities to the web, to cell phones, and to devices. J2EE
offers Java Message Service for integrating diverse applications in a loosely coupled,
asynchronous way. J2EE also offers CORBA support for tightly linking systems through remote
method calls. In addition, J2EE 1.3 adds J2EE Connectors for linking to enterprise information
systems such as ERP systems, packaged financial applications, and CRM applications.
4. By offering one platform with faster solution delivery time to market, freedom of choice, and
simplified connectivity, J2EE helps IT by reducing TCO and simultaneously avoiding single-
source for their enterprise software needs.

Q: What technologies are included in the J2EE platform?

The primary technologies in the J2EE platform are: Java API for XML-Based RPC (JAX-RPC), JavaServer
Pages (JSPs), Java Servlets, Enterprise JavaBeans (EJBs), J2EE Connector Architecture, J2EE
Management Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE Authorization
Contract for Containers, Java API for XML Registries (JAXR), Java Message Service (JMS), Java Naming
and Directory Interface (JNDI), Java Transaction API (JTA), CORBA, and JDBC data access API.

Q: How does J2EE relate to Enterprise JavaBeans technology?

Enterprise JavaBeans (EJB) technology is the basis of J2EE. EJB technology provides the scalable
architecture for executing business logic in a distributed computing environment. J2EE makes the life of an
enterprise developer easier by combining the EJB component architecture with other enterprise
technologies to solutions on the Java platform for seamless development and deployment of server side
applications.
Q: How are J2EE technology and the Sun ONE platform related?

The Sun ONE portfolio of products and technologies is built on the J2EE architecture, which defines the
service container for the platform. Developers familiar with J2EE technology can easily apply their skills to
building software, including Web services, using the Sun ONE products. For more information, see the Sun
ONE for Developers Web site.

Q: Who needs J2EE?

ISVs need J2EE because it gives them a blueprint for providing a complete enterprise computing solution
on the Java platform. Enterprise developers need J2EE because writing distributed business applications is
hard, and they need a high-productivity solution that allows them to focus only on writing their business
logic and having a full range of enterprise-class services to rely on, like transactional distributed objects,
message oriented middleware, and naming and directory services.

Q: Is J2EE available under the community source program?

Yes. The Java 2 SDK, Enterprise Edition is available under Sun's Community Source Licensing program.
For more information on Sun's community source program, see http://www.sun.com/communitysource.

Q: Are there compatibility tests for J2EE?

Yes. The J2EE Compatibility Test Suite (CTS) is available for J2EE. The J2EE CTS contains over 5,000
tests for J2EE 1.4 and will contain more for later versions. This test suite tests compatibility by performing
specific application functions and checking results. For example, to test the JDBC call to insert a row in a
database, an EJB component makes a call to insert a row and then a call is made to check that the row was
inserted.

Q: What is the Java Enterprise BluePrints?

The Java Enterprise BluePrints are the best practices philosophy for the design and building of J2EE-based
applications. The design guidelines document provides two things. First, it provides the philosophy of
building n-tier applications on the Java 2 platform. Second, it provides a set of design patterns for designing
these applications, as well as a set of examples or recipes on how to build the applications.

Q: What is the purpose of the Reference Implementation?

The purpose of the reference implementation is to validate the specifications. In short, it is to prove that the
specifications can be implemented.

Q: Why don't you allow the binary Reference Implementation to be deployed or redistributed?

We do not allow the binary reference implementation to be deployed or redistributed because it is not
supported and it could distract developers from robust, commercial J2EE implementations. We recommend
that people use those implementations which have the support of vendors and are tested and built for
performance and reliability. The J2EE Reference Implementation is designed to validate the test suite and
to be clearly understandable to vendors who want to see how we implemented a specific specification.
These design goals sometimes conflict with the goals of producing a highly performing, robust, full
featured implementation.

Q: What is the relationship of the Apache Tomcat open-source application server to the J2EE
reference implementation?
Tomcat is based on the original reference implementation of the JavaServer Pages (JSP) and Java Servlet
specifications, which was donated by Sun to the Apache Software Foundation in 1999. Sun continues to
participate in development of Tomcat at Apache, focusing on keeping Tomcat current with new versions of
the specifications coming out of the Java Community Source Process SM. Sun adapts and integrates the then-
current Tomcat source code into new releases of J2EE RI. However, since Tomcat evolves rapidly at
Apache, there are additional differences between the JSP and Servlet implementations in the J2EE and in
Tomcat between RI releases. Tomcat source and binary code is governed by the ASF license, which freely
allows deployment and redistribution.

Q: Is Web Services supported in J2EE?

Web Services is an essential component in the J2EE platform. J2EE provides a framework for developing
and deploying web services on the Java platform. The Java API for XML-based RPC (JAX-RPC) enables
Java technology developers to develop SOAP based interoperable and portable web services. Developers
use the standard JAX-RPC programming model to develop SOAP based web service clients and endpoints.
A web service endpoint is described using a Web Services Description Language (WSDL) document. JAX-
RPC enables JAX-RPC clients to invoke web services developed across heterogeneous platforms. In a
similar manner, JAX-RPC web service endpoints can be invoked by heterogeneous clients. For more info,
see http://java.sun.com/webservices/.

1.3 Frequently Asked Questions

A list of Frequently Asked Questions for the J2EE SDK 1.3 FCS release is available at
http://java.sun.com/j2ee/sdk_1.3/faq.html.

Branding

Q: What is the difference between being a J2EE licensee and being J2EE compatible?

A J2EE licensee has signed a commercial distribution license for J2EE. That means the licensee has the
compatibility tests and has made a commitment to compatibility. It does not mean the licensees products
are necessarily compatible yet. Look for the J2EE brand which signifies that the specific branded product
has passed the Compatibility Test Suite (CTS) and is compatible.

Q: Where can I find more information on J2EE?

For more information about J2EE and how to get the specification, see http://java.sun.com/j2ee/

Q1: What is the Java 2 Platform, Enterprise Edition ("J2EE") SDK? What is its intended use?

The J2EE SDK is the software development kit ("SDK") of the reference implementation ("RI") of the Java
2 Enterprise Edition ("J2EE") Platform. The RI is a complete implementation of the J2EE platform
intended as a proof of concept and example for implementations in the application server marketplace. The
J2EE SDK includes a J2EE application server and various tools to help developers prototype J2EE
applications and learn about the J2EE platform and technologies. It can be used as a J2EE development
enviroment for applications prior to their deployment and distribution.

Q2: Is the J2EE SDK supported on Solaris Operating Environment (Intel Platform Edition)?

J2EE SDK versions 1.2.1 and 1.3.1 are not officially supported on the Solaris Operating Environment 8
(Intel Platform Edition, formerly known as X86). The J2EE SDK is free of native code and is expected to
run on Solaris/Intel.
Q3: Is the J2EE SDK supported on Windows 95/98/ME?

We do not officially support Windows 95/98/ME. It is possible, however, to run the J2EE SDK 1.3.1 on
Windows 95/98/ME with some tweaking in the batch files. Please refer to
http://forums.java.sun.com/thread.jsp?forum=13&thread=21673 for more information. Please note that we
have not tested the solutions set out there.

Q4: How can I receive information about licensing the J2EE Reference Implementation(RI)?

To receive information about licensing the J2EE RI, fill out the J2EE License Request form. A member of
our licensing team will contact you shortly.

The J2EE SDK is free to you if you are using it for development only. As a licensee, you will have the use
of RI technology in products you develop, and access to Sun developed tests that can be used to establish
J2EE compatibility.

Q5: When will the source code for the J2EE 1.3.1 SDK be available?

The source code for the J2EE SDK 1.3.1 is to be available soon after the J2EE SDK final release.

Installation and Configuration

Q1: I'm having trouble downloading J2EE SDK. Have any common problems been reported?

We recommend using Netscape software to download our products.

Download errors have been reported with Microsoft Internet Explorer. If you have IE problems, we suggest
you search the Microsoft website on the following terms to determine if you have one of the problems
described there: Q248439, Q195155, Q231580.

Q2: Where do I set the variables for the J2EE SDK on a Windows machine?

You can set the value of J2EE_HOME for a particular window by running userconfig.bat. Open a
command prompt and use the following command:

c:\j2sdkee1.3\bin\userconfig

Otherwise, open your Control Panel, go to System Properties, and click on the Environment tab, to open a
dialog where you can add a new variable called J2EE_HOME with its value. This sets the variable for all
windows subsequently opened, and you don't have to run the batch file every time you open a new window.

The value for the variable is the directory where you installed the J2EE SDK. Set your J2EE_HOME
variable to:

c:\j2sdkee13
assuming you have installed J2EE SDK under c:\.

Q3: Where can I find the XML DTDs for deployment descriptors?

There are three places where you can access the DTD files:

1. DTDs for all components are available at http://java.sun.com/dtd/.

 2. Look in the download directory on your system: $J2EE_HOME/lib/dtd/.
3. Every J2EE component's Specification includes the DTD. Look for specifications under
http://java.sun.com/products/.

The use of each element is documented in the DTD file.

Q4: How do I modify the port number for the deploytool/server to avoid conflicts?

The J2EE server listen port number can be modified in the properties file at
$J2EE_HOME/config/orb.properties.

Q5: How do I do connect to a J2EE server on a different machine?

Take these steps to connect to a J2EE server on a different machine:

1. Make sure that the J2SE version on both machines is the same.
2. Compile the application. Start the server on one machine.
3. Deploy the application and ask for the client stub jar file.
4. Transfer the client stubs and the compiled client class onto the other machine
5. Using the IP address or the machine name run the client as follows:
java -Dorg.omg.CORBA.ORBInitialHost=<hostname> (Supply your host name.)
-Dorg.omg.CORBA.ORBInitialPort=1050
-classpath
"ClientStub.jar:$J2EE_HOME/lib/j2ee.jar" Client

Q6: I have trouble connecting from a Windows/Solaris client to a Linux server. What should I do?

In this situation you may see the following message:

Caught an unexpected exception!

javax.naming.CommunicationException: Can't find SerialContextProvider

After the default installation of Red Hat Linux the InetAddress.getLocalHost() method returns the loopback
address (127.0.0.1) instead of the actual host address. The fix is to assure that the method returns the actual
host by updating the /etc/hosts file, or the name service configuration file, etc/nsswitch.conf, using a query
to dns or nis before the InetAddress.getLocalHost() method is called.

The situation is explained in following release note for J2SE SDK 1.4:

http://java.sun.com/j2se/1.4/networking-relnotes.html.

Q7: Is there a JNDI browser provided with the J2EE SDK? How do I set up a JNDI browser for the
J2EE SDK?

There is no JNDI browser in the RI download, but one is available free through Forte for Java software.
Here is how to set it up:

1. Download Forte for Java.

2. Start your server.
3. Deploy your application.
4. Copy cloudutil.jar and j2ee.jar to the lib/ext directory of Forte.
 5. Start Forte for Java.
6. In Forte Explorer click on the "runtime" tab.
7. Go to the JNDI drop down folder.
8. Add a new provider copy from jndi.properties.
1. Add the following in the JNDI context factory:

com.sun.enterprise.naming.SerialInitContextFactory

2. Add a property:

java.naming.factory.url.pkgs.Naming=com.sun.enterprise.naming

9. Go back to the JNDI folder and right click on the newly added SerialInitContextFactory and click
to see if the provider has been installed. It should pop up a box saying "Provider is installed."
10. Now right click on the same box and say "Connect using" - It will throw a box similiar to the
configuration box. Just enter anything in the Context Label box and press OK.
11. If all has gone well, you should be able to see our naming hierarchy and drill down.

Uses of the J2EE SDK

Q1: To run Java ServerPages, do I need to install the J2EE SDK or do I only need a web server?

Java ServerPages ("JSP") require a web server and a Java 2 Platform, Standard Edition ("J2SE")
implementation to run. The J2EE SDK, has the functionality needed for running JSP pages.

JSP technology is one of the J2EE SDK technologies. If you want to use JSP pages with other J2EE SDK
technologies, e.g. Enterprise JavaBean ("EJB") technology, using the J2EE SDK is a good choice.

Q2: Where is the javax.naming.* package?

The javax.naming.* package now comes with J2SE 1.3. To be able to run J2EE SDK 1.3.1, you need J2SE
1.3.1_02.

Q3: How do I debug my J2EE applications running in the J2EE SDK?

1. Download and install Forte for Java.

2. Create a new project from the project menu.
3. Mount the filesystem to point to the sources in the workspace.
4. Put the following as one line in setenv.sh in the $J2EE_HOME/bin directory:
JAVACMD="$JAVA_HOME/bin/java -Xmx128m -Xdebug
-Xrunjdwp:transport=dt_socket,server=y,address=9876 $SSL_OPTIONS $JAAS_OPTIONS "
5. In Forte go to the Debug menu and select "Attach to Vm" and give the hostname and port (e.g., as
in the above case : 9876) to connect to the vm. Make sure Degugger Type is selected as "Default
Debugger (JPDA)".

You are now ready to debug.

The memory requirements are 198 MB for Forte for Java and 128 MB for J2EE.

Dealing With Common Errors

Q1: The following error occurred during deployment: Exception during packaging: [error]
com.sun.enterprise.deployment.xml.ParseException. What does this signify?

The problem can occur if you already have Java API for XML Processing ("JAXP") installed on your
machine (e.g. as part of J2SE). Its path was added to the environment variable PATH. You should delete
your J2SE installation and reinstall it without the extensions that include the JAXP and run the example
again.

Q2: I have received the following error message: java.lang.RuntimeException: Unable to create
ORB. Possible causes include TCP/IP ports in use by another process at ... What does this signify?

The error message may mean you have a port conflict. You may want to close Outlook (or similar
programs, such as MS proxy or Eudora client software) and try to start your server again.

Another possibility is you already have an instance of the J2EE SDK server running that has claimed the
port. You can stop the running of the previous instance to clear the way for starting your server again.

Q3: I have encountered the following error: No local string for enterprise.deployment. What does it
signify?

This occurs if your classpath does not include the following path:

$J2EE_HOME/lib/locale

A remedy is to use the command line tools provided with J2EE SDK. The command line tools
automatically insert the above path in the classpath.

Q4: What should I do if I encounter an error during startup of the J2EE SDK server?

Some of the typical causes of an error on startup are the following:

• The JDK version on the machine may not be the one that is supported by the J2EE SDK.
• A port conflict might exist due to its use by another process. (Typically this is caused by Outlook,
MS proxy, or Eudora client software)
• The TCP/IP setup may be flawed (Typically on Windows machine)
• On Linux, the following line should be included in /etc/hosts:
127.0.0.1 localhost
• On Windows, the LoopBack Adapter must be set in order for localhost to work.

Please refer to http://forums.java.sun.com/thread.jsp?forum=59&thread=129162 for more information.

Here is what to do if you receive one of the following messages:

• org.omg.CORBA.INITIALIZE: Could not find the POA-to-id mapper. Please ensure orb
has been started.

See the discussion at http://forums.java.sun.com/thread.jsp?forum=59&thread=129162.

• org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge

Make sure no older versions of JDK are in CLASSPATH/PATH. Client and server should use the
same Java 2 SDK, Standard Edition versions.
Q5: What should I do if I encounter an error during deployment?

Obtain diagnostic information as follows:

• Look in $J2EE_HOME/logs/<machine-name>/j2ee/j2ee/error.log for more information on the

error.
• Run the Verifier tool to determine what may be wrong with the application.

Q6: What should I do if I encounter an error while running an Enterprise JavaBeans application?

• Check the JNDI name on which the lookup is being done.

• Make sure he Client stub jar file is included in the classpath while running the client.

Q7: What should I do if I encounter a java.lang.ClassCastException when running an example that

uses Enterprise JavaBeans?

• Make sure the client jar is in the CLASSPATH.

• Make sure objects passed between client and server are serializable.

Access and Security Issues

Q1: What should I do if I encounter the following exception: java.rmi.AccessException: CORBA

NO_PERMISSION 0 No?

With 1.3.1 final release, the J2EE SDK became strict about checking adherence to the security policies of
J2EE components.

How can you make your application run under the Final Release?

1. If you don't want security checks, do the following:

Use the deploytool to build a deployment descriptor that does not require a strict security policy:

Under the Security screen of the EJB wizard or the Security tab of the EJB inspector in
deploytool, click "Deployment Settings..". Under the box "Client Authentication", make sure
"Support Client Choice" is checked instead of "Certificate" or "Password".

2. To require the application pass security checks to run, do the following:

When an enterprise bean specifies "Certificate" or "Password" as the method of Client

Authentication, use a J2EE application client, instead of a stand-alone Java application, to access
the bean. You will need to login as a valid J2EE user.

Q2: How come a "guest" principal is returned by getCallerPrinicipal() in an enterprise bean even
when the caller is authenticated with a specific principal?

You will need to specify "Certificate" or "Password" as in the "Deployment Settings..." for the enterprise
bean. See the previous question for more information.