Tools | Options | Misc | Ant Optionstoplink-essentials-agent.jar in classpath. This jar only contains a java agent class:oracle/toplink/essentials/internal/ejb/cmp3/JavaSECMPInitializerAgent.clasBut its META-INF/MANIFEST.MF contains a Class-Path entry , in addition to a Premain-Class entry:Premain-Class: oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInSo the class loader will follow this reference and load
itializerAgent
Class-Path: toplink-essentials.jar
<other entries omitted here>
toplink-essentials.jar in the same directory. toplink-essentials.jar contains all the Java Persistence API and implementation classes.-javaagent:toplink-essentials-agent.jar, and any agent jars are automatically appended to the classpath. I wrote this post on -javaagent: option. So runtime classpath only needs to include application classes and jdbc driver jar.<?xml version="1.0" encoding="UTF-8"?>Compile classpath is different, since we need to use Hibernate jars. Strictly speaking, javac only needs JPA API classes in the classpath. But just to be consistent with runtime, it does't hurt to include all 17 Hibernate jar files.
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
<persistence-unit name="hello-world" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>com.foo.Greeting</class>
<properties>
<property name="hibernate.connection.url" value="jdbc:mysql://localhost:3306/test"/>
<property name="hibernate.connection.driver_class" value="com.mysql.jdbc.Driver"/>
<property name="hibernate.connection.password" value=""/>
<property name="hibernate.connection.username" value="root"/>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
</properties>
</persistence-unit>
</persistence>
C:\ws\nb\scrap\src\com\foo> javacNote that the "" around the classpath element is needed. Otherwise, you will get
-d C:\ws\nb\scrap\build\classes
-classpath "C:\tools\hibernate-em\*"
Greeting.java HelloWorld.java
javac error: invalid flag.log4j.rootCategory=WARN, dest1Unlike TopLink, Hibernate doesn't use -javaagent: option. First start MySql on localhost, then
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
C:\ws\nb\scrap\build\classes> java -cpThe 17 jars used by Hibernate Entity Manager are:
C:\tools\hibernate-em\*;C:\tools\mysql-java\mysql-connector-java-3.1.13-bin.jar;.
com.foo.HelloWorld
createDDL.jdbcO-:-Ofalse
dropDDL.jdbcO-:-Ofalse
log4j.propertiesO-:-Ofalse
META-INF/persistence.xmlO-:-Ofalse
No configuration found. Configuring ehcache from ehcache-failsafe.xml found in
the classpath: jar:file:/C:/tools/hibernate-em/ehcache-1.2.jar!/ehcache-failsafe.xml
Query returned: Greeting id=1, message=hello world, language=en
antlr-2.7.6.jar, commons-collections-2.1.1.jar, hibernate-annotations.jar, jta.jar, asm-attrs.jar, commons-logging-1.0.4.jar, hibernate-entitymanager.jar, log4j-1.2.11.jar, asm.jar, dom4j-1.6.1.jar, hibernate3.jar, c3p0-0.9.0.jar, ehcache-1.2.jar, javassist.jar, cglib-2.1.3.jar, ejb3-persistence.jar, jboss-archive-browsing.jarC:\tmp> javac -cp C:\Sun\AppServer\lib\*What's happening here is, the OS expands * to all files/directories in C:\Sun\AppServer\lib, since * has special meaning for the OS. So the real command resolves to:
HelloWorldServlet.java
javac: invalid flag: C:\Sun\AppServer\lib\addons
Usage: javac <options> <source>
use -help for a list of possible options
javac -cp C:\Sun\AppServer\lib\activation.jarAs all files/directories are expanded alphabetically, the first one (
C:\Sun\AppServer\lib\addon
C:\Sun\AppServer\lib\admin-cli.jar
C:\Sun\AppServer\lib\ant ... HelloWorldServlet.java
activation.jar) is treated as classpath element, and everything else starting with addon are treated as separate JVM options. Of course these are invalid JVM options, hence javac: invalid flag:javac -cp "C:\Sun\AppServer\lib\*" HelloWorldServlet.java
javac -cp C:\Sun\AppServer\lib\*;\nosuchdir HelloWorldServlet.java
classpath option, including java. The error is different but solution is the same as above.java -cp C:\temp\* A
Exception in thread "main" java.lang.NoClassDefFoundError: C:\temp\b/jar
java -cp C:\single-jar-file-folder\* A
this is A
java -cp tmp:$HOME/modules/*.jar Test abc
<?xml version="1.0" encoding="UTF-8"?>Entity class:
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
<persistence-unit name="hello-world" transaction-type="RESOURCE_LOCAL">
<!-- comment out to use the default provider
<provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
-->
<class>com.foo.Greeting</class>
<properties>
<property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/test"/>
<property name="toplink.jdbc.user" value="root"/>
<property name="toplink.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<property name="toplink.jdbc.password" value=""/>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
</properties>
</persistence-unit>
</persistence>
package com.foo;Main class:
import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
@Entity
public class Greeting implements Serializable {
@Id @GeneratedValue private int id;
@Basic private String message;
@Basic private String language;
public Greeting() {}
public Greeting(String message, String language) {
this.message = message;
this.language = language;
}
public String toString() {
return "Greeting id=" + id + ", message=" + message + ", language=" + language;
}
}
package com.foo;To compile the project,
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
public class HelloWorld {
private EntityManagerFactory emf;
private EntityManager em;
private String PERSISTENCE_UNIT_NAME = "hello-world";
public static void main(String[] args) {
HelloWorld hello = new HelloWorld();
hello.initEntityManager();
hello.create();
hello.read();
hello.closeEntityManager();
}
private void initEntityManager() {
emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
em = emf.createEntityManager();
}
private void closeEntityManager() {
em.close();
emf.close();
}
private void create() {
em.getTransaction().begin();
Greeting g_en = new Greeting("hello world", "en");
Greeting g_es = new Greeting("hola, mundo", "es");
Greeting[] greetings = new Greeting[]{g_en, g_es};
for(Greeting g : greetings) {
em.persist(g);
}
em.getTransaction().commit();
}
private void read() {
Greeting g = (Greeting) em.createQuery(
"select g from Greeting g where g.language = :language")
.setParameter("language", "en").getSingleResult();
System.out.println("Query returned: " + g);
}
}
C:\ws\nb\scrap\src\com\foo>To run it, start MySql on localhost, and run
javac -d C:\ws\nb\scrap\build\classes
-classpath C:\Sun\AppServer\lib\toplink-essentials-agent.jar
Greeting.java HelloWorld.java
C:\ws\nb\scrap\build\classes>
java -javaagent:C:\Sun\AppServer\lib\toplink-essentials-agent.jar
-cp .;C:\tools\mysql-java\mysql-connector-java-3.1.13-bin.jar
com.foo.HelloWorld
[TopLink Info]: 2006.07.27 01:34:26.484--ServerSession(20003078)--TopLink, version: Oracle TopLink Essentials - 2006.4 (Build 060412)
[TopLink Info]: 2006.07.27 01:34:27.686--ServerSession(20003078)--file:/C:/ws/nb/scrap/build/classes-hello-world login successful
[TopLink Warning]: 2006.07.27 01:34:27.926--ServerSession(20003078)--Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2006.4 (Build 060412)): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Table 'sequence' already existsError Code: 1050
Call:CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(38), PRIMARY KEY (SEQ_NAME))
Query:DataModifyQuery()
Query returned: Greeting id=1, message=hello world, language=en
[TopLink Info]: 2006.07.27 01:34:28.447--ServerSession(20003078)--file:/C:/ws/nb/scrap/build/classes-hello-world logout successful
-javaagent: is introduced in JDK 5, and it may be late to talk about any new features in JDK 5, while JDK 6 is just around the corner. I started to use it recently but at first couldn't find any good documentation on this option.java -help shows a brief message:-javaagent:<jarpath>[=<options>]JDK tools doc page doesn't give much more info. The official one is at the Javadoc page for java.lang.instrument, as suggested by
load Java programming language agent, see java.lang.instrument
java -help-javaagent: is much simpler than that.public static void premain(String agentArgs, Instrumentation inst);2. Agent classes must be packaged in jar file format whose META-INF/MANIFEST.MF contains at least one additional attribute:
Premain-Class. An example of MANIFEST.MF:Manifest-Version: 1.0Once you have the custom MANIFEST.MF file, run
Premain-Class: javahowto.JavaAgent
Created-By: 1.6.0_06 (Sun Microsystems Inc.)
jar command with cvfm option to create the agent jar:/projects/Hello/build/classes $3. All these agent jars are automatically appended to the classpath. So no need to add them to classpath, unless you want to reorder classpath elements.
jar cvfm ../../myagent.jar ../../mymanifest.mf javahowto/MyAgent.class
-javaagent: option any number of times. Agents are invoked in the same order as specified in options.-javaagent agent1.jar:agent2.jar, which is incorrect.vim not in path, or not installed anywhere in the current machine. There may be some network locations with vim executable, but it's hard to remember where they are. So I have to use /bin/vi.csh is used, rather than tcsh, bash, zsh, etc. If they really love csh, why can't they just upgrade to tcsh, which is totally csh-compatible. I guess /bin/csh is the default login shell and they never bother to change it.set prompt="%/ > " in my $HOME/.tcsh, to always include `pwd` in the prompt. I don't remember the last time I run pwd command.csh uses the hard-to-reach escape key for its limited file-completion, and doesn't support case-insensitive match, possible matches listing, nor hyphen-underscore auto switch. I usually don't type a complete path. I don't trust my typing, even though I'm a pretty good typist.$JAVA_HOME is not defined, or $JAVA_HOME/bin is not in the path. As a result, commands like java, javac, jar, etc are not recognized.history command all the time to get the previous commands. Slightly better, use shortcuts like !java, but that is not very accurate and may give you a javac -classpath ... command.$HOME/.common file, and every time I go to another workstation, I just run tcsh and source /home/me/.common.NullPointerException that is not evident from the line number. To reduce it to a simple testcase:package com.javahowto.test;In that line, it seems the only suspect is the variable
public class Project {
private Integer version;
public static void main(String[] args) {
Project project = new Project();
System.out.println(project.toString());
//NPE in the next line
int version = project.getVersion();
}
private Integer getVersion() {
return version;
}
}
project. But if project was null, the constructor, or project.toString() should've failed, and the execution shouldn't reach project.getVersion().int version = project.getVersion();is really this at runtime:
int version = project.getVersion().intValue();
project.getVersion() returned null and caused NPE. Unlike primitives, Integer and other wrapper types don't default to 0 when used as instance or class variables. With the autoboxing in JDK 5, primitives and their wrapper types are almost but not completely interchangeable.ServletOutputStream or PrintWriter in servlet classes. They are created and managed by the web container, and web components should not interfere with its lifecycle. If you do close them inside your servlet service/doGet/doPost methods, it won't cause trouble for a fault-tolerant container.PrintWriter in processRequest method:If NetBeans insists on closing
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
/* TODO output your page here
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet MyServlet</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet MyServlet at "
+ request.getContextPath () + "</h1>");
out.println("</body>");
out.println("</html>");
*/
out.close();
}
ServletOutputStream, the safe way is to close it in a finally block.OutputStream or PrintWriter, just as you won't close System.out.@OverrideAfter typing
public String toString() {
return super.toString();
}
@Override and return, the cursor in the new line is already indented 8 spaces. I have to manually correct it. I have to remember not to press CTRL-SHIFT-F to format code, since it will ruin my carefully and manually formated code and format java annotations in its own unique way.@OverrideThis is also how jEdit and Eclipse 3.2 formats java annotations. Note that
public String toString() {
return super.toString();
}
@Override doesn't need to be in its own line, but it looks cleaner to me.target() field is an empty array. For example,javax.ejb.ActivationConfigProperty:
@Target(value={})
@Retention(value=RUNTIME)
public @interface ActivationConfigProperty
javax.persistence.EntityResult
@Target(value={})
@Retention(value=RUNTIME)
public @interface EntityResult
@ActivationConfigProperty can only be used inside @javax.ejb.MessageDriven to specify properties for the Message-Driven Bean (MDB):@MessageDriven(name="MessageBean",
activationConfig = {
@ActivationConfigProperty(propertyName="destinationType",
propertyValue="javax.jms.Topic"),
@ActivationConfigProperty(propertyName="acknowledgeMode",
propertyValue="Auto-acknowledge"),
@ActivationConfigProperty(propertyName="subscriptionDurability",
propertyValue="Durable"),
@ActivationConfigProperty(propertyName="messageSelector",
propertyValue="name='java' AND bugs < 1")
})
public class MessageBean implements MessageListener {
...
}
@javax.persistence.EntityResult can only be used as nested annotation inside @javax.persistence.SqlResultSetMapping. Here is a more complex example from its java doc, with 3 nested annotations at 3 different levels:@SqlResultSetMapping(name="OrderResults",
entities={
@EntityResult(entityClass=com.acme.Order.class, fields={
@FieldResult(name="id", column="order_id"),
@FieldResult(name="quantity", column="order_quantity"),
@FieldResult(name="item", column="order_item")})},
columns={
@ColumnResult(name="item_name")}
)
grep, head, touch, tail, more, etc, and if you are patient enough to manage Cygwin installation. For anything beyond that, you should really consider Solaris x86 or Linux.jar command options can start with optional -. jar tvf a.jar is the same as jar -tvf a.jarjar cvf \tmp\b.jar com\javahowto\test\ will create the directory tree com\javahowto\test\ inside the target jar, and include all files under <current-dir>\com\javahowto\test\.jar will copy the absolute paths inside the jar file, which is not what you want. For example,C:\tmp > jar cvf a.jar C:\tmp\A.class10. If source files are not located in the current directory, you can use
added manifest
adding: C:/tmp/A.class(in = 405) (out= 279)(deflated 31%)
-C option to tell jar command to implicitly change to another directory and then include files there. For example,C:\ws\nb\scrap\dist > jar cvf hello-world.jar -C ..\build\classes com\javahowto\test11. If you use
-C ../build/classes option and want to include all files under ../build/classes, use . (dot) to represent all files there. Note that you can't use *, which will resolve by OS to all files to the current directory. For example,C:\ws\nb\scrap\dist > jar cvf hello-world.jar -C ..\build\classes .The following example (using -C and *) will ignore -C option and instead include all files in the current directory, which is not what we want:
C:\ws\nb\scrap\dist > jar cvf hello-world.jar -C ..\build\classes *12. There are 3 types of paths in
..\build\classes\com\hello-world.jar : no such file or directory
added manifest
adding: scrap.jar(in = 20487) (out= 7472)(deflated 63%)
jar command:m option is present. Either relative or absolute path is fine. The same as destination file.-C option is present. In that case, all source files should be relative to the value of -C option.-C option, I'd suggest you always cd into the parent directory of all source files, and then run jar command.e option to specify an entry-point class (Main-Class in META-INF/MANIFEST.MF) for self-contained applications packaged in a jar file. See this post for details.M option:jar cvfM no-meta.jar A.classNote: it's upper-case M. Lower-case m has a different meaning.
adding: A.class(in = 405) (out= 279)(deflated 31%)
m option:jar cvfm my-meta.jar my-meta-inf\my.mf A.classThe option used here
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)
cvfm tells the jar command that the destination file (f) will come next and then custom manifest file (m). I can also specify them in a different order:jar cvmf my-meta-inf\my.mf my-meta.jar A.classIt's lower-case m. Upper-case M has a different meaning.
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)
jar cvf ignore.jar A.class META-INFWhen it comes to manifest files for new jar file, you only have 3 options:
added manifest
adding: A.class(in = 405) (out= 279)(deflated 31%)
ignoring entry META-INF/
adding: META-INF/LICENSE.txt(in = 2657) (out= 1185)(deflated 55%)
ignoring entry META-INF/MANIFEST.MF
M not to include a manifest filem to use a custom manifest file. Inside the jar file, this file will always be named MANIFEST.MF under META-INF directory. Outside of the jar file, this custom manifest file can be anywhere and have any name.cvfm option, this custom manifest file is ignored and a default MANIFEST.MF is included.jar command can also operate on zip files. I usually run jar tvf hello.zip to quickly view its content, without starting up the WinZip program. jar xvf hello.zip should also be able to expand the target zip files. I find it hard to memorize Unix zip/unzip command line options, so I just use jar tvf/jar xvf instead. For example:C:\tmp > jar tvf eclipse-SDK-3.2RC7-win32.zip2.
jar tvf can selectively list table of contents for archive. I used to run jar tvf j2ee.jar | grep javax/servlet/http to search for servlet classes in j2ee.jar. Replace grep with findstr on Windows. In fact, I don't need grep or findstr; I can just run this command:jar tvf j2ee.jar javax/servlet/httpNote that the search criteria are matched against the beginning of all entries in jar file. It uses
String.startsWith(what) rather than String.contains(what). So this command jar tvf j2ee.jar ejb will not return any matching entries, though jar tvf j2ee.jar javax/ejb will return all ejb classes. The search is also case-sensitive.jar tvf my.jar | grep -i aNynAmEC:\Sun\AppServer\lib > jar xvf j2ee.jar META-INF/MANIFEST.MFOr using a backslash instead of a forward slash:
inflated: META-INF/MANIFEST.MF
C:\Sun\AppServer\lib > jar xvf j2ee.jar META-INF\MANIFEST.MFThe entry names are case sensitive, and so the following will not extract anything:
inflated: META-INF/MANIFEST.MF
C:\Sun\AppServer\lib > jar xvf j2ee.jar meta-inf/manifest.mfOf course, you can always double-click the entry to view it in WinZip, fileroller, or other tools.
jar command: e. Other options of the jar command are still the same. This is the partial usage from JDK 6 beta 2:C:\tools\jdk6\bin > jarFor example, I run
Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir] files ...
Options:
...
-e specify application entry point for stand-alone application
bundled into an executable jar file
...
jar command to package a self-contained application in a jar file:C:\ws\nb\scrap\build\classes > C:\tools\jdk6\bin\jar cvfe ..\..\dist\hello-world.jar com.javahowto.test.HelloWorld comThen I can distribute hello-world.jar to users, who can run hello-world app like this:
added manifest
adding: com/(in = 0) (out= 0)(stored 0%)
adding: com/javahowto/(in = 0) (out= 0)(stored 0%)
adding: com/javahowto/test/(in = 0) (out= 0)(stored 0%)
adding: com/javahowto/test/HelloWorld.class(in = 572) (out= 348)(deflated 39%)
C:\download\hello > java -jar hello-world.jarUsers can run it with any version of java; it doesn't have to be JDK 6. What the extra
Hello world!
e option does is simply adding a Main-Class entry in the jar's META-INF\MANIFEST.MF:Manifest-Version: 1.0This new feature is helpful when packaging simple self-contained apps, and application client modules in J2EE/JavaEE, both of them require a
Created-By: 1.6.0-beta2 (Sun Microsystems Inc.)
Main-Class: com.javahowto.test.HelloWorld
Main-Class entry in MANIFEST.MF. So I don't have to create one beforehand, or have Apache Ant generate one.java:comp/env when looking up ejb/resource in the current naming environment. Equally important is to know where/when not to use it.java:comp/env in standard deployment descriptors, such as web.xml, ejb-jar.xml, and application-client.xml. I can't think of any elements in these descriptors that contain java:comp/env.java:comp/env in appserver-specific deployment plan files.java:comp/env in any fields of resource and/or ejb injection, whether it's field or method injection.java:comp/env when looking up resource/ejb using javax.ejb.EJBContext.lookup(String name). This is a new method in javax.ejb.EJBContext in EJB 3. The lookup name in this case is always relative to java:comp/env. For more details, please see 5 Ways to Get Resources in EJB 3.java:comp/env when looking up certain standard J2EE and JavaEE resources. They reside directly under java:comp/, with no /env. For instance:java:comp/env when looking up global resources in a server-dependent way. Some application servers let you look up resources by their global JNDI name. In such case, their lookup name should not contain java:comp/env. For example, java:/defaultDS in jboss. In JavaEE SDK 5/Glassfish/Sun Java System Application Server 9, I can also directly look up jdbc/__default (the default datasource) without configuring it in any descriptors. Note that this style of lookup is not portable. It ties your apps to specifc runtime server environment, and should really be avoided.java:comp/env in the name of any physical resources inside an application server, like jdbc-resource, jdbc-pool, JMS queue or topic, EJB JNDI name, persistence manager, etc.package hello.ejb;Application client main class:
import javax.ejb.Remote;
@Remote
public interface HelloEJBRemote {
void hello();
}
package hello.ejb;
import javax.ejb.Stateless;
@Stateless
public class HelloEJBBean implements HelloEJBRemote {
public void hello() { }
}
package hello;For the above sample app to work, we do not need any deployment descriptors or deployment plan. Why? because all metadata have been provided with annotations, or have defaults, or can be figured out by appserver one way or another.
import hello.ejb.HelloEJBRemote;
import javax.ejb.EJB;
public class Main {
@EJB(beanName="HelloEJBBean")
private static HelloEJBRemote helloEJB;
public static void main(String[] args) {
helloEJB.hello();
}
}
<?xml version="1.0" encoding="UTF-8"?>Both the ejb reference name and ejb JNDI name are wrong. If the IDE really thinks a sun-application-client.xml is helpful for whatever reason, the ejb-ref element should be:
<!DOCTYPE sun-application-client PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Application Client 5.0//EN"
"http://www.sun.com/software/appserver/dtds/sun-application-client_5_0-0.dtd">
<sun-application-client>
<ejb-ref>
<ejb-ref-name>helloEJB</ejb-ref-name>
<jndi-name>ejb/helloEJB</jndi-name>
</ejb-ref>
</sun-application-client>
<ejb-ref>because the default ejb reference name for an injected ejb is the of the format: <fully-qualified-class-name of the injection target class>/field-name. The default ejb JNDI name depends on appserver implementation, and for EJB3 in JavaEE SDK 5/Glassfish/Sun Java System Application Server, it's the fully qualified class name of the remote business interface.
<ejb-ref-name>hello.Main/helloEJB</ejb-ref-name>
<jndi-name>hello.ejb.HelloEJBRemote</jndi-name>
</ejb-ref>
public class HelloServlet extends HttpServlet {
protected void processRequest(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = null;
try {
out = response.getWriter();
Context ic = new InitialContext();
DataSource dataSource = (DataSource) ic.lookup("java:comp/env/jdbc/__default");
Connection connection = dataSource.getConnection();
out.println("Successfully looked up the default datasource: " + dataSource +
", and got the connection: " + connection);
} catch (NamingException e) {
throw new ServletException(e);
} catch (SQLException e) {
throw new ServletException(e);
}
}Any portable applications must also declare a resource-ref in web.xml:<?xml version="1.0" encoding="UTF-8"?>Without this resource-ref element in web.xml, the app fails with this error in JavaEE SDK 5/Glassfish/Sun Java System Application Server:
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>com.foo.servlet.HelloServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/HelloServlet</url-pattern>
</servlet-mapping>
<resource-ref>
<res-ref-name>jdbc/__default</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>
javax.naming.NameNotFoundException: No object bound to name java:comp/env/jdbc/__defaultWe are not done yet. We also need to map the resource reference name (jdbc/__default) to the global JNDI name of the target resource (jdbc/__default). This step is appserver-dependent, usually editing an appserver-specific deployment plan file. For example, sun-ejb-jar.xml, sun-web.xml, sun-application-client.xml, or jboss.xml. The following shows how this is mapped in sun-web.xml:
at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:751)
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:156)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:307)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.foo.servlet.HelloServlet.processRequest(HelloServlet.java:30)
<?xml version="1.0" encoding="UTF-8"?>When the local reference name and the global JNDI name are the same, some application servers may also have some default mapping rules to eliminate this step. For instance, in JavaEE SDK 5 and Sun Java System Application Server 9, this step is not needed when the two names are the same.
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="">
<context-root>/webapp14</context-root>
<resource-ref>
<res-ref-name>jdbc/__default</res-ref-name>
<jndi-name>jdbc/__default</jndi-name>
</resource-ref>
<class-loader delegate="true"/>
</sun-web-app>