Composer’s out-of-the box DFS integration is currently aimed at the Developer with simple, as opposed to advanced, requirements for DFS. Specifically, we’re talking about developers that only care about the services themselves (the basic developer) and don’t care about the package that the services come in (the advanced developer). And for a lot of use cases this out-of-the-box capability is just fine.
However, there are some other use cases where you do care about the package that the services come in. Perhaps you want to package everything in a war rather than an ear (because you use Tomcat for example). Or perhaps you want to run some additional servlets or servlet filters alongside your services (or even JSPs!). Or perhaps you have custom authentication and authorization requirements and you want to replace DFS’s authorization SOAP handler with you own.
Any of these types of requirement will mean that you care about the packaging your services come in as well as the services themselves.
Fortunately, the Java EE edition of Eclipse can help us out. It adds new projects types such as the Enterprise Application project (ear project) and the Dynamic Web project (war project). These projects will give us complete control over the contents of the ear, war & jars’s.
To compliment this it is possible to install the Composer plug-ins right into this edition of Eclipse as I talked you through here. This is a pre-requisite for this article.
With the union of these two products we can now do some cool things like create Web projects with DFS services in them. We can also significantly boost our productivity by leveraging Eclipse’s capability to deploy and test our ear and war projects on an associated application server, without having to ever leave the IDE. Eclipse supports most, if not all application servers either out of the box or via download.
To get you started I’ve created an attached a few blank templates projects which should give you the idea.
TemplateProjects1.zip contains a set of projects that will re-produce DFS’s existing packaging. It comprises an Ear project with an associated Utility project (jar project) and a War project. The utility project hosts the DFS builder and is where you would develop your services. This is also visually denoted with the Documentum logo decorator on the project icon. When exported this will produce a ear, with your service jar and an embedded war. It should look something like this:-
You’ll notice that I’ve ringed the Ear associations in red. The source file for a sample service in blue. The generated web resources for the service (the wsdl, reference web.xml, app server specific config files, etc) in green. Note these files in particular. My recommendation is that you add a custom ant-based builder that copies (or merges) these files to the relevant locations in your War file. Lastly, I’ve ringed, in pink, the DFS builder so you can see that it exists on the utility (jar) project.
TemplateProjects2.zip contains a Web project and a utility project. No ear this time. The utility project again hosts the DFS builder and is where you would do you service development. When exported this would produce a War containing a services Jar. It should look something like this:-
TemplateProjects3.zip contains a single Web project which hosts the DFS builder. This time you do everything in the Web project including develop your services. When exported this will obviously produce a single War and would contain everything DFS needs to run; the DFS runtime, JAX-WS runtime, your services, UCF, etc. It should look something like this:-
With all of these project templates you’ll notice that they are suspiciously devoid of anything DFS related at the moment; runtime, JAX-WS runtime, UCF, etc. I didn’t want to infringe any copyright’s with my employer. I like getting paid . So regrettably I will have to leave you this as a reader exercise. Another approach of course would be to import an existing DFS ear that could act as a bootstrap. It’s up to you. But obviously these files need to be applied one way or another before you can think about deploying this to a Server.
I have also left out the Documentum Core Project. Again, I didn’t want to infringe any copyright’s so before you import any of these templates make sure you have a 6.5 Documentum Core Project in your workspace. The easiest thing to do is create yourself a dummy Documentum project which will force the creation of the core project if it doesn’t exist.
Debugging a Project
OK. Assuming you have overlayed the remaining DFS files to complete your project structure. You will now want to run or debug it. First-time only you need to configure an appropriate server. In the Server’s view right-click in free space and select New->Server. Follow the wizard through to completion. Typically you will configure a new Server entry based on an existing app server installation but some of the runtimes also support installation of a new app server instance as well, Tomcat being one.
With the new Server entry created in the Servers view you now need to associate the projects you want to run with your Server. To do this you can drag them onto the Server from Package Explorer or you can right-click the project and select Run As (or Debug As)->Run On Server… or you can right-click the Server entry in the Servers view and choose Add and Remove Projects…
Once you have associated your project with your Server all that remains is to Start it or Debug it. Right-click on your server and select either Start or Debug.
Obviously if you start your Server in Debug mode (as the above screenshot shows) any breakpoints you have set in your code will cause eclipse to break into the debugger when hit.
More Details (for the Curious only!)
Eclipse is very declarative in nature and most all settings are stored in special files in the project (.project, .classpath, etc) and we have tried to carry that practice on within Composer (.dmproject, .dfsproject, template, etc). So, if you want to create one of these projects yourself then it is fairly simple process, as follows:-
1. Create your web services source tree. If you want to use the DFS Builder’s defaults you must create folders /Web Services, /Web Services/src, /Web Services/bin/gen-src & /Web Services/bin/classes/.
However it is entirely feasible, and in fact probable within the context of a War or Jar project, that you will want to modify these settings so that Eclipse builds your service in the right place for your Jar or War (as I demonstrated in the with template #3). You just have to tell DFS where you want to put your files. To do this you need to edit .dfsproject file (see #2) and add the following attributes to the root element; sourcePath=”<project-relative path to dfs service java files>” (equivalent of /Web Services/src default), generateSourcePath=”<project-relative path indicating where to store generated source>” (equivalent of /Web Services/bin/gen-src default) and outputPath=”<project-relative path to compiled output” (equivalent of /Web Services/bin/classes/). The settings used for template #3 therefore looked like this:-
<?xml version=”1.0″ encoding=”ASCII”?>
<dfsproject:Project xmi:version=”2.0″ xmlns:xmi=”http://www.omg.org/XMI” xmlns:dfsproject=”http://documentum.emc.com/infrastructure/04012008/dfsproject” version=”6.5″ sourcePath=”src” generateSourcePath=”src-dfs-gen” outputPath=”build/classes” dfsSdkVersion=”6.5″>
2. Copy in the following files from a dummy Documentum project; .dmproject, .dfsproject & template. Modify .dfsproject, if required, as outlined in step #1.
3. Next, edit .classpath adding the following lines to match your DFS settings:-
<classpathentry kind=”con” path=”com.emc.ide.external.dfs.DFS_CONTAINER”/>
<classpathentry kind=”src” output=”<outputPath>” path=”<sourcePath>”/>
<classpathentry kind=”src” output=”<outputPath>” path=”<generateSourcePath>”/>
If you are outputting your source to the project’s default output folder then you can just omit the output attribute altogether.
This file determines your Java Build Path so you should be able to see these changes if you inspect the Java Build Path tab on your project’s properties dialog.
4. Lastly, edit the .project file and add the following bolded entries:-
<?xml version=”1.0″ encoding=”UTF-8″?>
Some of the other entries may be a little different, especially the natures, depending on the type of project that you are merging into.
When you save this file you should see the Documentum logo decorator added to your project and if you inspect the Builder properties tab you should also see the DFS Builder has been added.
What we have looked at today is a technique for leveraging both Eclipse IDE for Java EE Developers, specifically its WTP features, and Composer in order to develop services within the context of enterprise & web applications. This gives you as the developer complete control over the contents of your DFS package. It also allows you to leverage the full power of WTP’s server runtimes & debugging capabilities.