I found this step by step instruction a long time ago from a Blog called ‘JavaYogi’
this is not my own work but I thought this is useful information and so posting-
Getting started on Repository
The ATG documentation was somewhat unsatisfying on creating a repository from scratch, because it didn’t have all of the information in the same place. So, here are notes on how to set up a bare bones repository and read from it.
This example builds on the setup from the Hello-World-How to that I wrote earlier.
Note: I’m using Oracle as a database and ATG 6.2.0 for this.
Step 1: Setting up the Database
- Before getting started, let’s create a dummy table with some data to read.
create table tf_deploy(id varchar2(30),stuff varchar2(255))
insert into tf_deploy values (0,’hero-style’);
commit;
Step 2: Setting up a Database Connection and Connection Pool
This step configures database access. If you were going to use JDBC instead of the repository API, you could lookup a reference to these components and use them to deal with the database.
For some reasons, not explained here, ATG needs XA sources, which not every database supplies. So, ATG provides a wrapper to simulate that on any database connection.
- Setting up the database connection, create a file /config/atg/dynamo/service/jdbc/devdbFakeXA.properties. Adjust the example for your database:
$class=atg.service.jdbc.FakeXADataSource
server=192.168.1.111:1521
user=wcaprod
needsSeparateUserInfo=true
URL=jdbc:oracle:thin:@192.168.1.111:1521:dev2db
readOnly=false
password=xxxxxxxxx
database=dev2db
driver=oracle.jdbc.driver.OracleDriver
2. Set up the connection pooling, /config/atg/dynamo/service/jdbc/devdb.properties. The properties are self- explanatory (if you know that you need to set them J):
$class=atg.service.jdbc.MonitoredDataSource
min=10
max=10
blocking=true
maxFree=-1
loggingSQLWarning=false
loggingSQLDebug=false
loggingSQLInfo=false
logginSQLError=false
dataSource=/atg/dynamo/service/jdbc/devdbFakeXA
Step 3: Create a Repository
The repository is a nucleus component. The OR mapping to the database tables is in a separate xml configuration file.
1. Create the bare bones repository /config/playground/dummyRepository.properties:
$class=atg.adapter.gsa.GSARepository
checkTables=false
dataSource=/atg/dynamo/service/jdbc/devdb
definitionFiles=dummy.xml
# some other properties that are needed,
# and I’m not quite sure, why ATG thinks that I
# should care enough to be forced to supply defaults.
XMLToolsFactory=/atg/dynamo/service/xml/XMLToolsFactory
idGenerator=/playground/DummyGenerator
transactionManager=/atg/dynamo/transaction/TransactionManager
2. Create the mapping xml file /config/playground/dummy.xml:
<!DOCTYPE gsa-template SYSTEM “http://www.atg.com/dtds/gsa/gsa_1.0.dtd”>
<gsa-template>
<item-descriptor name=”comments” default=”true”>
<table name=”tf_deploy” type=”primary” id-column-names=”id”>
<property name=”id” column-names=”id” data-type=”string”/>
<property name=”stuff” column-names=”stuff” data-type=”string”/>
</table>
</item-descriptor>
</gsa-template>
3. If you paid attention to the repository properties file, you’ll notice the reference to a ‘DummyGenerator’. ATG can’t deal with the unique primary keys generated by the database. It needs to generate it’s on primary keys. To make matters worse, even if our code generates the primary key (to make things easier for the how-to), it still snuffs.
- Dynamo provides a key generator. That generator requires database tables. For the sample and cleanliness of this process, we don’t want to create or mess with existing Dynamo tables. So, there is another id generator, which works only in memory. We’ll create that.Create a file called /config/playground/DummyGenerator.properties:
$class=atg.service.idgen.TransientIdGenerator
$scope=global
2. The next step is to register our repository with dynamo by creating /config/atg/registry/ContentRepositories.properties
initialRepositories+=\
/playground/dummyRepository,\
Hint: I’ve had numerous problems writing a repository file, and it not working. ATG simply returned a null pointer without detailing the problem. The following has been a helpful diagnostic tool:
- Try to open the repository in the web admin pages. It sometimes says, why it couldn’t find it.
- Try to load the file into an xml editor, like XML Spy and validate it against the DTD. That will catch a lot of typos.
Step 4: Creating the Java code to read from the Repository
If you read the ATG documentation this should be straight forward. They did document it of course, just not the setup that is needed from the previous steps.
1. Create a JSP file in the war from the hello-world example, /j2ee-apps/playground4/playground4.war/rep_test.jsp:
<%@ page import=”javax.naming.*” %>
<%@ page import=”javax.sql.*” %>
<%@ page import=”atg.adapter.gsa.*” %>
<%@ page import=”atg.repository.*” %>
<%@ page import=”atg.servlet.*” %>
<% GSARepository repository = (GSARepository) ((DynamoHttpServletRequest) request).resolveName(“/playground/CmsDeployRepository”);
RepositoryItem item0 = repository.getItem(“0″, “comments”);
out.println(“Read from the database: ” + item0.getPropertyValue(“stuff”) + “<br>”); %>
Now, you can start Dynamo. Because there were changes to the configuration files, you’ll have to re-start. If everything works, the page should come up fine. See, the hello-world how-to for starting dynamo.
Step 5: Writing to the Repository
Let’s modify the code above to write to the repository. It wasn’t obvious from the documentation that code that writes to the repository needs to be wrapped inside a transaction. If it is not done, Dynamo provides a rather peculiar error message along the lines of ‘Couldn’t end transaction, because it wasn’t ended’.
What happens is that there is a servlet in the servlet pipeline that looks for unclosed transactions. That servlet found that the transaction hadn’t been closed. If the code is not well checked with try-catch blocks, it might cause that your code to close the transaction is never called. The result is that you get this kind of exception, instead of the one that caused the problem, because that particular servlet intercepted the original exception.
1. Create a new JSP: /j2ee-apps/playground4/playground4.war/rep_write_test.jsp:
<%@ page import=”javax.naming.*” %>
<%@ page import=”javax.sql.*” %>
<%@ page import=”javax.transaction.*” %>
<%@ page import=”atg.adapter.gsa.*” %>
<%@ page import=”atg.repository.*” %>
<%@ page import=”atg.servlet.*” %>
<% // start transaction
Context c = new InitialContext();
UserTransaction trans = (UserTransaction) c.lookup(“java:comp/UserTransaction”);
trans.begin();
try {
// create a repository item
MutableRepositoryItem item = repository.createItem(“comments”);
item.setPropertyValue(“stuff”, “blasdf”);
repository.addItem(item);
out.println(“Done”);
} finally
{// end transaction
trans.commit();
} %>
Adding the JSP file doesn’t need a restart of Dynamo. Open the page in the browser. ATG should compile the JSP. Then check the database, if the new row was actually created.
Congratulation, (if it actually worked), you have been initiated in the craft of using ATG repositories
