Those of you still with me have successfully navigated my series on the document repository with only one last and mysterious segment to go: Utilizing the Repository. Why the mysterious title? I was hoping not to explicitly give away the fun part of this series: writing unsupported Java code.
For a preview of things to come, take a look at the output of my sample application:
****************************************** A simple document repository test application. by H. Ross Brodbeck, BEA Systems Inc No warranty is provided with this application. It is not even guaranteed to function. I am sure there are bugs. Use it at your own risk. ****************************************** A test of DR encryption: Password is: password Encrypted password is: RDQyMzUxNjYwRDQ0OTI4QQ== Decrypted password is: password Testing document upload: (uploading C:/sandbox/drtest/dummy_text.txt) Binding to service at - http://localhost:8020/dr Uploaded ID is: F0321F33/D027E5FA.ACT Archiving document... Archived ID is: F01768DC/D02B4333.ARK Deleting archive...Success! Deleting document...Success! Document repository test completed. Exiting...
If you've been following part 1 and part 2, then you already know, theoretically, what this application is doing. Perhaps if you're the adventurous type you already know how to write this application. If not, that's what the final segment of this series is for.
In this post I'll take you on a tour of a toy Java application which creates its own document repository and exposes the upload/download/archive capabilities of the repository. Essentially, this is what every embedded application server that uses the document repository does.
Setup
To get started, you're going to need to either edit or create the following files on your client (I put them all in the same directory):
- dr.xml - I copied the one from the content upload service ($PT_HOME/ptupload/6.1/settings/config/dr.xml) and modified it, as per the below instructions.
- dr.jar - the meat and potatoes of the DR remote client
- hessian-3.0.12.jar (or whatever version of the repository you're using has) - This is needed for the file transfer part of the application
- a test file to upload (could be anything -- be creative)
You can find a copy of the jar files in a number of war files (use a zip file editor or the jar utility to extract them), including the knowledge directory upload and document repository war files ($PT_HOME/ptupload/6.1/webapp/). They will need to be added to the classpath of the sample application.
The repository itself must be made aware of our application, unless we are planning on using an existing repository. Since this is a new entity, I need to configure a new repository. I'm going to call my application PTHack (due to the hacked up nature of the code). As I explained in part 1, I'm going to set up an application and provider element in settings/config/dr-server.xml. Under the applications node:
<application>
<name>pthack</name>
<enabled>true</enabled>
<password>RDQyMzUxNjYwRDQ0OTI4QQ==</password>
<provider>filesystem</provider>
</application>
Under the file system provider:
<application>
<name>pthack</name>
<paths>
<active>C:\sandbox\bea/ptdr/documents/PTHack/Active</active>
<archived>C:\sandbox\bea/ptdr/documents/PTHack/Archived</archived>
</paths>
</application>
Finally, I need a dr.xml for my client application. For the purposes of this application I modified the one from PTUpload (see above for location). I could have changed the password for the application if I had edited the <application> node above and the relevant segment of dr.xml. The sample code I provided has examples of the DR's encrypt/decrypt methods, in case you want to change the password. I'm lazy, so I kept the default. Here is what my dr.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<dr>
<application>
<name>pthack</name>
<password>RDQyMzUxNjYwRDQ0OTI4QQ==</password>
</application>
<transport>glue</transport>
<transports>
<transport>
<name>local</name>
<factory>com.plumtree.dr.transport.local.client.LocalClientFactory</factory>
</transport>
<transport>
<name>glue</name>
<factory>com.plumtree.dr.transport.glue.client.GlueClientFactory</factory>
<startup>
<url>http://localhost:8020/dr</url>
<home>@ELECTRIC_INSTALL_PATH@</home>
</startup>
</transport>
</transports>
</dr>
The Sample Application
The sample application I've provided below is fairly straightforward. It contains methods for creating a remote repository object, as well as methods for uploading and downloading files from that object. It wouldn't take much imagination to adapt this into a back end repository for whatever applicaiton you might decide to write. A few highlights:
- The main method has an example of using the encrypt/decrypt methods in the repository. I didn't bother deciphering the encryption scheme.
- You'll notice the need to specify an application name, password, and configuration directory twice: once in your config file (dr.xml) and once in the application itself (see the static strings at the top of the attached source). This is kind of... annoying. If you look at the content upload service, you'll see these same properties specified twice as well: once in dr.xml and once in the application.conf file in the same directory (settings/config). I suppose at some deep level before transport this is unnecessary, but I didn't bother going far enough to find it.
- The rest of the methods use simple method calls and a stream for uploading/downloading the file. That's pretty much it.
None of this is supported, of course, but that doesn't mean it isn't a fun or interesting exercise. Click here for the full source to the application (RepositoryDemo.java).
Leave a comment