ADF - Tomcat
ADF - Tomcat
ADF - Tomcat
Essentials
is likely to disappear. The productivity and quite advanced functionality are likely to quickly bring in many
more developers from the Java/JEE arena.
I expect Oracle to make a lot of noise about ADF Essentials during JavaOne 2012 next week in San
Francisco. I for one think that they should. Note: ADF Essentials is not open source. The ADF sources are
available to customers with an ADF license. There is no community process around further evolving ADF. ADF
is and stays Oracles strategic development framework for its enterprise applications. It has no intention
whatsoever to relinquish control over one of its most important technologies. However, it is interested in
sharing that technology with a much wider audience.
For more details on ADF Essentials visit: http://www.oracle.com/technetwork/developertools/adf/overview/adfessentials-1719844.html.
The framework overview for ADF Essentials is as stated above just a subset of the full ADF framework.
The architecture is the same in terms of tiers just a little bit more limited in terms of components.
The most important Data Controls are still there. That means that the largely declarative way of exposing
business services database, URL (REST), EJB and POJO (which means anything Java can call) to UI
developers is in tact in ADF Essentials.
The extensions in ADF to JSF (JavaServer Faces) are all there: for example taskflows and contextual events.
The ADF Library mechanism for packaging, sharing and reusing taskflows and other components is fully
supported in ADF Essentials.
Development of ADF Essentials applications can be done using JDeveloper (11.1.2.3 for now) or Eclipse with
the free OEPE (Oracle Enterprise Pack for Eclipse) extension.
Note: there is not distinction (none whatsoever) between the IDE used for ADF Essentials and the one used for
full ADF. It is your own responsibility to ensure that if you want to work under the free ADF Essentials license,
that you do not inadvertently use any feature not included in that license. (this may sound more ominous than it
will be in real life, but still that is the situation).
Deployment can be done to a fairly wide range of platforms that each in their own way needs to be prepared
for ADF application deployment including JBoss, GlassFish, Tomcat, WebSphere, WebLogic and OC4J
(which means iAS/OAS):
Note: I am assuming that deployment is not restricted to the release numbers in this list and that for example
Tomcat 7 is supported as well; I am not sure about that though. The Essentials license does not restrict
deployment in any way: if we can make it work on a server, then it is allowed.
And interesting question that just occurs to me: will there be JHeadstart Essentials as well?
Why?
A fair question might be at this point: why is Oracle doing this? It is not a move to gracefully get rid of some
technology as many donations to the open source community turned out to be. Through this move I believe
Oracle wants to strengthen Java provide Java developers with a framework that in many aspects competes
with .Net in terms of productivity and functionality out of the box. It also wants to bolster the existing ADF
developer community. While ADF is doing well and has been growing quite a bit over the last few years, the
number of ADF developers around the world is hardly enough to take on the existing workload. Given the sharp
increase in ADF projects expected around Oracle FMW (WebCenter, BPM, BI,) and Fusion Applications in
the very near future, it is in Oracles best interest that the pool of ADF developers grows rapidly. One good way
of growing that pool is by attracting developers to work with ADF Essentials given that required skills for any
ADF engagement are the same as those for ADF Essentials.
Resources
ADF Essentials FAQ http://www.oracle.com/technetwork/developer-tools/adf/overview/adfessentialsfaq1837249.pdf
Initial ADF Essentials thread on ADF EMG: https://groups.google.com/forum/?fromgroups=#!topic/adfmethodology/EYWOnFgMNg0
Announcement on DZone:
http://www.dzone.com/links/oracle_adf_core_functionality_now_available_for_f.html
List of ADF Components and their support in ADF Essentials: http://www.oracle.com/technetwork/developertools/adf/overview/components-1844931.html
Introduction demo movie (13 mins) of ADF Essentials:
http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/ADFEssentials/adfEssentialsFull.html
Java/JEE developers interested in getting training on ADF (Essentials) can send an email to info-at-amis-nl for
information about focused training-material and events.
Andrejus published an article: http://andrejusb.blogspot.nl/2012/09/adf-essentials-quick-technical-review.html
Quick technical review of ADF Essentials with his first impressions with deploying ADF Essentials on
GlassFish. Very instructive!
Recently I gotinvolved in a project where the customer requirement was to deploy an ADF application on
Apache Tomcat 6.x. This ADF application would be rolled out with ADF Essentials. Which OTN describes as
following: Oracle ADF Essentials is a free packaging of key technologies from the Oracle Application
Development Framework that can be used to develop and deploy applications without licensing costs. Thus
tremendously decreasing operational costs.
The plan of action was to install and configure Tomcat on a test environment and verify that the application
would be successfully deployed and work as designed. The following steps were taken to install Tomcat:
1. Download and configure Tomcat
2. Application specific configuration
Tomcat Web Application Manager application provides the user with functionality to upload, deploy and
undeploy applications through the Web.Also once deployed, to stop and start applications. One can access the
Tomcat Web Application Manager on the Tomcat server on the following URL: http://[serverhostname]:[server-port]/manager.
You will be asked for username and password. Out of box Tomcat is not shipped with any users. To create an
user that can execute deployments, add the following snippet to $CATALINA_BASE/conf/tomcat-users.xml:
<user username=admin password=admin roles=standard,manager-gui/>
There are several shell scripts that need to be executable. We need to adjust the file permissions of these files,
execute the following commands at the terminal:
cd $CATALINA_BASE/bin
chmod +x *.sh
factory=oracle.jdbc.pool.OracleDataSourceFactory
url=jdbc:oracle:thin:@server:1521:xe
user=scott password=tiger maxActive=20 maxIdle=10 maxWait=300/>
The developer of the application to be deployed and I realized that it would help us preventing class loading
issues if we copied all our java libraries to the server. This would be the lib directory in the
$CATALINA_BASE. The following files were placed in the $CATALINA_BASE/lib:
adfbcsvc-client.jar
adfbcsvc.jar
adfbcsvc-registration.jar
adfbcsvc-share.jar
adf-businesseditor.jar
adf-businesseditor-model.jar
adf-businesseditor-settings.jar
adf-controller-api.jar
adf-controller.jar
adf-controller-rt-common.jar
adf-controller-schema.jar
adf-controller-security.jar
adf-dt-at-rt.jar
adfdt_common.jar
adf-dynamic-faces.jar
adf-faces-changemanager-rt.jar
adf-faces-databinding-dt-core.jar
adf-faces-databinding-rt.jar
adf-faces-registration.jar
adf-faces-templating-dt-core.jar
adf-faces-templating-dtrt.jar
adflibfilter.jar
adflibrary.jar
adf-loc.jar
adflogginghandler.jar
adfm-debugger.jar
adfm.jar
adfmportlet.jar
adfm-sqldc.jar
adfmweb.jar
adf-pageflow-dtrt.jar
adf-pageflow-fwk.jar
adf-pageflow-impl.jar
adf-pageflow-rc.jar
adf-richclient-api-11.jar
adf-richclient-automation-11.jar
adf-richclient-impl-11.jar
adf-runtime-mbean.jar
adf-sec-idm-dc.jar
adf-share-base.jar
adf-share-ca.jar
adf-share-glassfish.jar
adfsharembean.jar
adf-share-security.jar
adf-share-support.jar
adf-share-web.jar
adftags.jar
adftransactionsdt.jar
adf-view-databinding-dt-core.jar
annotations-api.jar
bc4jhtml.jar
bc4jimdomains.jar
bc4j-mbeans.jar
bc4jsyscat.jar
bundleresolver.jar
cache.jar
catalina-ant.jar
catalina-ha.jar
catalina.jar
catalina-tribes.jar
com.bea.core.apache.commons.collections_3.2.0.jar
commons-el.jar
datatags.jar
db-ca.jar
dms.jar
dvt-databinding-dt-core.jar
dvt-databindings.jar
dvt-databindings-mds.jar
dvt-facesbindings.jar
dvt-faces.jar
dvt-jclient.jar
dvt-trinidad.jar
dvt-utils.jar
ecj-3.7.2.jar
el-api.jar
facesconfigmodel.jar
glassfish.jstl_1.2.0.1.jar
groovy-all-1.6.4.jar
inspect4.jar
jasper-el.jar
jasper.jar
javamodel-rt.jar
javatools-nodeps.jar
javax.mail_1.1.0.0_1-4-1.jar
javax.transaction_1.0.0.0_1-1.jar
jdev-cm.jar
jewt4.jar
jmxdc.jar
jr_dav.jar
jrf-api.jar
jsf-api.jar
jsf-impl.jar
jsp-api.jar
jsp-el-api.jar
mds-dc.jar
mdsrt.jar
oc4j-ws-support.jar
oicons.jar
ojdbc6dms.jar
ojdl2.jar
ojdl.jar
ojsp.jar
oracle.classloader_11.1.1.jar
oracle-el.jar
oracle.http_client_11.1.1.jar
oracle.logging-utils_11.1.1.jar
oracle-page-templates.jar
oracle.web-common_11.1.1.jar
oracle.xdb_11.1.0.jar
orai18n-mapping.jar
ordhttp.jar
ordim.jar
org.apache.bcel_5.1.jar
org.apache.commons.beanutils_1.6.jar
org.apache.commons.beanutils_1.8.3.jar
org.apache.commons.logging_1.0.4.jar
org.apache.commons.logging_1.1.1.jar
prefuse.jar
rcs-adflib-rt.jar
rcsrt.jar
regexp.jar
resourcebundle.jar
servlet-api.jar
share.jar
taglib.jar
tomcat-coyote.jar
tomcat-dbcp.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar
trinidad-api.jar
trinidad-impl.jar
velocity-dep-1.4.jar
weld-integration.jar
xmlef.jar
xmlparserv2_sans_jaxp_services.jar
Now we will adjust the memory settings. This is to accommodate all the jar files that may be referenced later
on. Edit the $CATALINA_BASE/bin/catalina.sh and add the following line above the alreay existing text #OS
specific support..
CATALINA_OPTS=-Xms1024m -Xmx1024m -XX:MaxPermSize=512m
At this point the application server is configured and prepared for the application deployment.
Make sure that there are no libraries in the deployment war file, otherwise weird class loading issues may occur.
The application should be exported to use the datasource/JDBC resource on the application server, and no hard
coded jDBC URL. You can launch Tomcat by executing the following shell script:
$CATALINA_HOME/bin/startup.sh
Login to the manager application and drag and drop the application on the Choose file button inside the
War file to deploy section. After a successful deployment the application will be started and the Running
column for your application will have the status true.
When facing problems analyze the log files that can be found in the server directory: $CATALINA_BASE/logs.
In our situation the log file localhost had the most accurate logging for the exceptions we had.
In one of the projects Im involved in we have to make use of specific Oracle JDBC features. The application
runs on Tomcat 5.0.27 and connects to the database using a JNDI datasource setup to use connection pooling .
When setting this up based on info I found in Steve Muench sBC4J Toy Story example I ran into some
problems .
For some reason I got the following error:
java.sql.SQLException: User credentials doesnt match the existing ones.
It really drove me nuts. Checking parameternames over and over, checking username and password But
together with Martijn Hinten of Cumquat I managed to track down the problem. This error only occurs if you
specify the minLimit parameter, used to specify the minimum number of pooled connections the pool should
have. If you ommit it everythings fine .. This is the minimum context file we needed to get the
OracleConnectionCacheImpl working
<?xml version='1.0' encoding='utf-8'?>
<Context displayName="udo" docBase="C:/development/appservers/jakarta-tomcat5.0.27/webapps/myContext" path="/myContext" workDir="workCatalinalocalhostmyContext">
<Resource name="jdbc/myDataSource"
type="oracle.jdbc.pool.OracleConnectionCacheImpl"/>
<ResourceParams name="jdbc/myDataSource">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>password</name>
<value>****</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:thin:@localhost:1521:***</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>local_user</value>
</parameter>
</ResourceParams>
</Context>
Place this file under the name myContext.xml in tomcat_home/conf/Catalina/localhost. Now you should be able
to use this Datasource from within the myContext web -application using the following code
InitialContext context = new InitialContext();
envContext = (Context) context.lookup("java:comp/env");
ds = (DataSource) envContext.lookup("jdbc/myDataSource");
When working on a project I like to precompile my JSPs just to test if havent made any (syntax) errors or
forgot any resources, without having to deploy them on the appserver and testing them one by one.
In a project we are working using Tomcat we use Ant to build the application and package it in war, which is
subsequently deployed on the Tomcat server.
This ant build copies all necessary resources to a build directory and starts compilition and war building from
there.
I added an extra target to precompile the JSP as follows following the instructions found here.
<target name="jspc" depends="init,copy-and-filter-web-content,copy-meta,make-libdir">
<taskdef classname="org.apache.jasper.JspC" name="jasper2">
<classpath id="jspc.classpath">
<pathelement location="${java.home}/../lib/tools.jar" />
<fileset dir="${env.CATALINA_HOME}/bin">
<include name="*.jar" />
</fileset>
<fileset dir="${env.CATALINA_HOME}/server/lib">
<include name="*.jar" />
</fileset>
<fileset dir="${env.CATALINA_HOME}/common/lib">
<include name="*.jar" />
</fileset>
</classpath>
</taskdef>
<jasper2 validateXml="false"
uriroot="${build.dir}"
outputDir="${build.dir.precompiledJSP}" />
</target>
In this case I do not deploy the compiled JSPs on the server, I just compile them to test them. So the outputDir
is just there for temporary storage.
If I for example put the following line in my JSP:
If you follow the instructions in the document mentioned above, you can also deploy the compiled JSP to the
tomcat.
But I think the solution with mapping the individual jsp patterns to classes in the web.xml might be somewhat
confusing.