Skip to Content
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!!!
To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Divakar Salla
    I generally use the Visual Administrator -> Server -> Services -> Deploy, but am not sure if this is the best way…

    Am sure you that you must have seen a lot of exceptions.. One common exception which i face is

    “The system cannot find the file specified; nested exception is:      java.util.zip.ZipException: The system cannot find the file specified”

    Am unable to find the resolution to this…

    (0) 
    1. Viswanath Naidu Post author
      Yup, I got the same exception.  It must be due to the fact that the zip extraction failed, and the xml file(s) that contain(s) the info to where each component should be stored, is not available in the anticipated path.  And, possibly, there is a default set of deployment instructions that get executed, and somehow blow away your sap.com folder – which is primarily for the Portal, so you end up with a vanilla J2EE setup, or worse.  Again, these are my assumptions.  Bottom line, if you can avoid building a J2EE app, by building a portal application or .NET application, consider the latter options.  That’s my two cents worth!
      (0) 
  2. Anonymous
    Hi viswanath,

    I had a portal with  a lot of errors.. when i tried to solve it by deploying some important files manually thru SDM…

    my pcdContent folder got deleted… phew ! gettting it back to the original state was hardwork.. but i am still not able to link the reasons behind this …

    Regards
    Bharathwaj

    (0) 
    1. Viswanath Naidu Post author
      I’m not sure either.  I can only go by the error messages and it must be some strange logic in the deploy tool that says if there is no space on the logical drive to which your application is being deployed, delete everything in site 😉  Just joking.  It’s kinda left me with a bad taste for J2EE development using SAP’s J2EE engine.  I think I’ll stick to .NET – it is not as destructive when it comes to application deployment 😉
      (0) 
  3. Jonathan Urfalino
    I never got an exception about drive space but I do get many other exception, for example
    javax.naming.NoPermissionException: ID003605
    or others about not having bind/unbind permissions, not valid user id, tealeaf exceptions, etc etc. after a few tries the deployment usually goes fine without having to delete or change anything.. but some other times I spend more than half an hour unsuccesfully trying to deploy an application.
    Any suggestions? jonatan.urfalino -at- kcc.com
    (0) 
    1. Viswanath Naidu Post author
      I’m not sure, Jonathan.  Again, I could not accurately remember the exact messages.  It is quite possible the errors I was getting in certain instances were the same as you.  And, the workaround I’ve indicated in my weblog, would work just the same.  Please try the steps in the weblog and let me know if you’ve any luck.  If not I’ll see if I can dig up anything to offer some assistance.  But, I am by means no expert, but I can certainly give it my best shot.  Please do let me know.  Best of luck!

      -Vis-

      (0) 
  4. Madhavi Bollepalli
    I was able to figure out how to deploy a J2ee app the 30th time around. The document that SAP published is useless. You cannot get the interface to comeback without an error. There is a bug in the deployment tool. Do not user a war but manually add the class filea nad their libraries. once you create the ear and deploy check the folders and files on the deploy folder. I have had to manually change the web.xml several times. the tool does not create this xml file in the correct format.
    Hope this helps.
    We have deployed a J2EE application on SAP and have been using it without issues for the past two years.
    (0) 
    1. Viswanath Naidu Post author
      Hi Madhavi,

      Thanks for the feedback.  It is quite possible we will encounter this problem again as we are looking to implement SAP’s ICSS (a J2EE) application.  Should we experience the same problems, we’ll try and use your approach.  ‘Much appreciated.

      (0) 

Leave a Reply