Recently I was working on a port of an application entitled the Sample RTE (Run-Time Environment) 1.2.2. This application is a SCORM (Sharable Content Object Reference Model) 1.2 compliant LMS (Learning Management System), originally built by the open source community Of ADL (Advanced Distributed Learning). It is a J2EE application built on Tomcat 5.0, and which uses a Microsoft Access database. Porting this to SAP WebAS was quite a chore, but I got it going after much effort. Firstly, I had to figure out a way to ensure that all library references within the JSP and Java classes and libraries were referenced properly and available in the applications class path. This way it would work properly under SAP’s J2EE engine. Next, I needed to figure out a way to build this as a EAR file deployable using either SDM or the dreaded Deploy Tool. Well, once I figured out how to build the EAR file, using the sample Calculator application, I had to figure out the process of actually deploying it. The deploy process was quite interesting, to say the least. I first attempted to use the recommended SDM application, that was quite strict with what the contents of the EAR would be, and how the XML files that contain all sorts of information should be layed out. As I found out, based on the design of my EAR file, it wasn’t going to work through SDM, so I had to fall back to the Deploy Tool, something I’m highly regretting now. So, I used the deploy tool and deployed my application to my personal portal (we’ve dedicated development server environments for each developer – ‘makes for a very efficient programming environment). It deployed nicely and created the necessary folders with JSP, html and whatever was part of the EAR file. So, I could now use my J2EE application. Now, everything was fine, until after about the 40th or 50th time I redeployed the EAR based on updates and modifications to the application code. I suddenly got Java errors indicating the deployment failed, and with not very much information to indicate why. Of course I didn’t bother to read the entire message and just closed the deployment tool. I then re-ran the deployment tool, reloaded my EAR and deployed it once again. Yet again I got the error, and closed the deployment tool. Now, I was a bit worried. So, I navigated the folder structure of the J2EE engine and could barely believe my eyes when I found that the entire sap.com folder and its contents were deleted, as well as several other folders under the instance folder (ie. in our case the server name is PD0, and instance name is JC00, so content under the R:\SAP\usr\sap\PD0\JC00 was affected). So, I pretty much rendered my environment useless, thanks to the wonderful Deploy Tool. Fortunately, I had access to a colleague’s development environment so I logged in there and re-deployed the code to his server, but this time making sure to do a few things differently. For instance, once I created the deployment project and deployed the EAR, I’d delete that project and next time I’d do a deployment, I’d create a brand new project, and deploy the EAR from there. But, to my dismay I encountered the same error again, after about the 15th time (number of times has nothing to do with this, at least not directly). Yet, this time I made sure to properly read the error message which indicated to me that the failure was due to lack of sufficient drive space. So, I did a bit of research and found that every time you do a EAR deploy, an extracted version of the EAR contents are placed in a specific folder in the J2EE folder structure. But, that content is never deleted after a deploy, so you have to manually go in and delete that content (I think you have to shut down the J2EE server to do this – but am not quite sure). This path would be similar to: R:\usr\sap\PD0\JC00\j2ee\cluster\server0\temp\deploy\work\deploying Where PDO is your server name, and JC00 is the instance name (correct me if I’m wrong here). Here you’ll see a bunch of folders that start with the text ‘reader’ in them. These are all the extracted versions of each deploymment to that server. They are never re-used, so you should be able to delete each of these folders to save space. Once I did this I regained the necessary disk space, started a new deployment project in the Deploy Tool, loaded my new EAR package and deployed it without any problems. Although I was able to solve this problem by taking a few careful steps and ensuring there was sufficient space on the J2EE server’s R:\ partition, I’m sure there is more to this problem than what I’ve discovered. Otherwise, how did the tool randomly delete a whole series of folders and their contents if it could not proceed due to space constraints? I recently got my development server re-imaged and am back in business. Phew! All I know is I’m either going to opt to build my applications in .NET or build them as Portal Web Components rather than building a J2EE application, especially if that application is only going to be used in the Portal. It’ll save me a lot of grief. If anyone else out there has experienced a similar scenario or has some insight on this, I’d love your feedback. I enjoy J2EE development, but this EAR deployment process sure got me scared, considering its destructive results if you don’t know exactly what you are doing. ‘Hope you found this little blog of interest. Happy SDN’ing!!!