Ant Task: Init

Ant Task: Init

 

Creates and initializes the metadata table in the schema.

Usage:

 

<flyway:init />

Configuration:

Driver = flyway.driver: The fully qualified classname of the jdbc driver to use to connect to the database , Required=YES,

URL = flyway.url: The jdbc url to use to connect to the database,

User = flyway.user: The user to use to connect to the database,

Password = flyway.password: The password to use to connect to the database, Required=NO, Default       Value=blank,

Schemas = flyway.schemas: Comma-separated list of schemas managed by Flyway. The first schema in the list will be the one containing the metadata table,Required=NO, Default Value= default schema of the connection,

Table =  flyway.table: The name of Flyway's metadata table.By default (single-schema mode) the metadata table is placed in the default schema for the connection provided by the     datasource.When the flyway.schemas property is set (multi-schema mode), the metadata table is placed in the first schema of the list,Required=No,Default Value = schema_version,

InitialVersion = flyway.initialVersion: The initial version to put in the database, Required=NO, Default Value=0,

InitialDescription = flyway.initialDescription: The description of the initial version, Required=NO, Default Value=<< Flyway Init >>,

ClassPath = flyway.classpath: The Ant classpath used to load the JDBC driver and the migrations, Required=NO,

ClassPathref = flyway.classpathref: The Ant classpath reference used to load the JDBC driver and the migrations, Required=NO.

Sample configuration;

<property name="flyway.driver" value="org.hsqldb.jdbcDriver"/>
<property name="flyway.url" value="jdbc:hsqldb:file:/db/flyway_sample"/>
<property name="flyway.user" value="SA"/>
<property name="flyway.password" value="mySecretPwd"/>
<property name="flyway.schemas" value="schema1,schema2,schema3"/>
<property name="flyway.table" value="schema_history"/>
<property name="flyway.initialVersion" value="1.0"/>
<property name="flyway.initialDescription" value="Base Migration"/>

Sample output

 

 

Port Registry in ATG servers

One of the more confusing aspects of server-side applications is the number of TCP servers that might
start up. The standard configuration for an ATG application, for example, starts between four and six
separate TCP servers. To help organize these servers, ATG includes a service called
atg.service.portregistry.PortRegistry that keeps track of which services started servers on
which ports. The PortRegistry has a Nucleus address of /atg/dynamo/server/PortRegistry. This
component’s page in the Component Browser lists which services are using which ports.
The PortRegistry does not automatically find server components. Instead, individual server
components are expected to register themselves with the PortRegistry.
Every subclass of RequestServer already has the ability to automatically register with a PortRegistry
when it starts up. To do this, the component must be configured with a property that points to the
PortRegistry.
For example, the HTTP server might be configured like this:

portRegistry=/atg/dynamo/server/PortRegistry

If you create a server component that does not extend RequestServer, your component should define a
portRegistry property to be set in the configuration file. When it starts, it should register itself with the
PortRegistry like this:

if (getPortRegistry () != null) { 
  getPortRegistry ().addEntry (getPort (), getAbsoluteName ()); 
}

Note: This assumes that port is available as a property. The getAbsoluteName method is available only
if your server component extends atg.nucleus.GenericService. If you extend GenericService, this
code most likely appears inside your doStartService method. Also, your doStopService method
should include the following code:

if (getPortRegistry () != null) { 
  getPortRegistry ().removeEntry (getPort (), getAbsoluteName ()); 
}

Deploy Java code/ ATG components on JBoss

Pretty simple, on a production environment you start JBoss with its run file and a series of commands, which then picks up your EAR file from the deployment directory. Which is a fine process to go through, but what if you’re developing code and you don’t want to wait the several minutes for a build and deployment – on a windows system this can take well over 20 minutes to achieve if you’re running things locally.

We want to do hot deployment so that when you make small changes in your java class/ ATG component you don’t have to rebuild and restart JBoss each time and you save yourself a lot of time.

We can do this by starting JBoss in the following way:

To avoid building an EAR file each time rather than using JBoss’s run file (/JBoss/bin/run.bat or run.sh) ATG provides a way to start JBoss and build the EAR on the fly from your working directory. This means that you can make changes to JSP’s etc… and see the changes instantly. To do this from your command prompt/shell go to your ATG home directory (/ATG/ATG22007.1/home/bin/) and in the bin run this file: StartDynamoOnJBoss.

In order for this to work and hot deployments to work we need to pass in a few parameters for this to work. Firstly the dynamo server to use – if you’re using one. Next set the name of the jBoss server using the -c flag. Then set the modules you want to load so your projects bin/ code source directory, ATG modules etc… and finally set the most important command -f -run-in-place which tells jBoss to compile and run the code from your projects directory rather than look for an EAR file in its deploy directory. So the start command looks like this:

startDynamoOnJBoss MY_DYNAMO_SERVER_NAME -c MY_JBOSS_SERVER_NAME -m MYPROJECT.core -f -run-in-place

And thats it. Now you can make changes to your files in Eclipse and you won’t need to restart jBoss. But there is one last thing – make sure to set your project in Eclipse to build automatically – you can set this under the project menu at the top.

Setting Database Connections in JBoss from ATG

ATG communicates to a database via JBoss via a dynamo server setup or in your home/localconfig directory if you’re not using specific dynamo servers. In this setup you specify the JNDI connection name which will then refer to an XML file which makes up part of your JBoss server. So to summarise ATG connects via its own JNDI config file which maps to an XML file on the JBoss server. JBoss then handles the connection out to the data source via a JDBC call – this can be any type of database or repository potentially.

Here’s how to set the database connections for something like Oracle. For MySQL etc… the procedure is pretty much the same and you can find example XML configs for these in your JBoss install the only real difference is the driver used for the connection.

First start with JBoss and setup the XML. Go to your servers deploy directory: \jboss\server\MY_SERVER_NAME\deploy. If you haven’t setup a server then this will be called default – if you’ve installed ATG then there will be a server called ATG. In your deploy directory there will be XML files normally with the mention of ‘ds’ in the file name, to let us know its for a data Source. If you go to:  \jboss\docs\examples\jca you should find example XML connection files here.

Alternatively using the below code we can create one for Oracle called something like ATG-Oracle-DS.xml.

In this XML file we basically set the JNDI reference name, the JDBC connection URL which is the database server IP/name along with the port and the SID (Service Identifier). We then set the schema that we want to connect to and it’s password. It’s the same for any database connection, although you’ll also see that we set the driver to use for the connection (more on this after the below XML)…

<?xml version="1.0" encoding="UTF-8"?>

<datasources>

<local-tx-datasource>

<!-- The jndi name of the DataSource, it is prefixed with java:/ -->

<!-- Datasources are not available outside the virtual machine -->

<jndi-name>ATGOracleDS</jndi-name>

<!-- The jdbc url -->

<connection-url>jdbc:oracle:thin:@MY_ORACLE_DB_URL:1521:MY_SID</connection-url>

<!-- The driver class -->

<driver-class>oracle.jdbc.OracleDriver</driver-class>

<!-- The login and password -->

<user-name>SCHEMA_NAME</user-name>

<password>PASSWORD</password>

<!-- The minimum connections in a pool/sub-pool.

Pools are lazily constructed on first use -->

<min-pool-size>10</min-pool-size>

<!-- The maximum connections in a pool/sub-pool -->

<max-pool-size>10</max-pool-size>

</local-tx-datasource>

</datasources>

OK so the XML is pretty simple – you can have as many connections in one XML file as you need but sometimes it’s easier to keep them in separate files to identify connections. You can also MIX connections, so I can have a schema on Oracle, another on MsSQL and a third on MySQL and ATG can read and use data from all of these as part of its data anywhere architecture.

Here’s the gotcha – you MUST make sure the driver/ libary jar file is installed for your server to connect to your database. So go to your server’s lib directory e.g. \jboss\server\MY_SERVER_NAME\lib and for Oracle you will need a jar called ojdbc14.jar which contains the necessary classes for JBoss to connect to your database – generally JBoss does come with most database library jars but you may need to hunt this one down on Oracles website.

So We’ve set an XML file that specifies a connection for JBoss to use, we’ve added the necessary libary files to our JBoss server so it can make the connection. Finally we need ATG to be configured to use this connection, this is the really easy part!

In ATG the sources are referenced via the Dynamo servers localconfig, so for example in: \ATG\ATG2007.1\home\servers\MY_SERVER_NAME\localconfig\atg\dynamo\service\jdbc or if you’re not using Dynamo servers then just look in home\localconfig\atg\dynamo\service\jdbc.

If you’re building an external EAR file for your deployment then include this  in your Dynamo servers that you export with your EAR file. Anyway in this config directory you need to make a .properties file to set the JNDI connection to use. Just add the below 2 lines – the JNDIName variable should reference the JNDI name in your XML file.

$class=atg.nucleus.JNDIReference

JNDIName=java:/ATGOracleDS

And thats it! You should be able to map any database for use with ATG replacing the Solid database that comes with ATG.

Now a word of warning – it’s fine using additional databases for ATG but if you want to completely replace the Solid database, and in a production environment this is a must, you will need to load in the tables to your database for ATG to use, but I’ll write this up in a separate post – It’s pretty easy as ATG ships with various SQL setup scripts for you to use to achieve this.

Sample Ant Build File - WAR

Sample Ant Build File - WAR I am using the Spring SimpleFormController example to illustrate the build process. The figure below shows the structure of the web application. All the classes inside the src directory should be compiled and placed in a separatebuild/classes directory. The created war file will be placed inside the dist directory. So first we create the build/classes and the dist directory. The init target does this job. 1.<target name="init"> 2.<mkdir dir="build/classes"/> 3.<mkdir dir="dist" /> 4.</target> The next step is to compile all the classes in the src directory and place them in thebuild/classes directory. To do this first you need to add all the lib files inside the "WebContent/WEB-INF/lib" directory to the classpath. 1.<path id="compile.classpath"> 2.<fileset dir="WebContent/WEB-INF/lib"> 3.<include name="*.jar"/> 4.</fileset> 5.</path> The target compile uses the javac task to compile the java classes and it depends on the target init, because only when you have the directory ready you can place the classes inside them. 1.<target name="compile" depends="init" > 2.<javac destdir="build/classes" debug="true" srcdir="src"> 3.<classpath refid="compile.classpath"/> 4.</javac> 5.</target> The path we created earlier will be refered here using the <classpath> element. Now we can create the war file using the war task. To create the war file you need to specify the web directory, lib directory and the classes directory. The destfile attribute specifies the war file location and the webxml attribute specifies the web.xml file location. 1.<target name="war" depends="compile"> 2.<war destfile="dist/AntExample.war" webxml="WebContent/WEB-INF/web.xml"> 3.<fileset dir="WebContent"/> 4.<lib dir="WebContent/WEB-INF/lib"/> 5.<classes dir="build/classes"/> 6.</war> 7.</target> You can use the clean target to clean the project. The clean target deletes the build and the dist directory. 1.<target name="clean"> 2.<delete dir="dist" /> 3.<delete dir="build" /> 4.</target> The complete build.xml file is shown below. 01.<?xml version="1.0" ?> 02.<project name="AntExample1" default="war"> 03.  04.<path id="compile.classpath"> 05.<fileset dir="WebContent/WEB-INF/lib"> 06.<include name="*.jar"/> 07.</fileset> 08.</path> 09.  10.<target name="init"> 11.<mkdir dir="build/classes"/> 12.<mkdir dir="dist" /> 13.</target> 14.  15.<target name="compile" depends="init" > 16.<javac destdir="build/classes" debug="true" srcdir="src"> 17.<classpath refid="compile.classpath"/> 18.</javac> 19.</target> 20.  21.<target name="war" depends="compile"> 22.<war destfile="dist/AntExample.war" webxml="WebContent/WEB-INF/web.xml"> 23.<fileset dir="WebContent"/> 24.<lib dir="WebContent/WEB-INF/lib"/> 25.<classes dir="build/classes"/> 26.</war> 27.</target> 28.  29.<target name="clean"> 30.<delete dir="dist" /> 31.<delete dir="build" /> 32.</target> 33.  34.</project>