PAS deployment of a new ABL application in the same tomcat instance - Forum - OpenEdge Deployment - Progress Community

PAS deployment of a new ABL application in the same tomcat instance

 Forum

PAS deployment of a new ABL application in the same tomcat instance

This question is answered

I'm having trouble figuring out how to get a new ABL application running in the same instance of tomcat.

This question has come up a couple times, base on what I can tell

community.progress.com/.../21847
https://community.progress.com/community_groups/openedge_deployment/f/21/p/28199/95200#95200

There is even a brief KB: https://knowledgebase.progress.com/articles/Article/How-to-create-multiple-ABL-applications-in-one-single-PASOE-instance

However I'm not having much luck (windows, oe 11.6.3).  Here is what I see when I run the command on my tomcat instance "oepas5":

proenv>C:\OpenEdge\WRK\oepas5\bin\tcman deploy %DLC%/servers/pasoe/extras/oeabl.war another
verbose: checking for tailoring script in C:\Progress\OpenEdge\servers\pasoe\extras\oeabl.war
verbose: execution complete
Instance target directory already exists - C:\OpenEdge\WRK\oepas5\webapps/oeabl

Moreover, nothing was added or updated in the "openedge.properties" file.

I am quite convinced that we need a longer KB to understand this process of adding a new ABL application to an existing tomcat instance.  For one thing, the "tcman deploy" doesn't seem to be intended for "ABL applications" but for "ABL webapps".  If I run "tcman help deploy" then the syntax that is returned doesn't even appear to allow for the deploy command to be used in the way that is suggested by the KB:

usage: tcman deploy  [options]  -u <uid:pwd> [-a <app-name>] <war-file-path>
  general options:
      -u uid:pwd  pass uid and pwd for HTTP BASIC authentication
      -v          print verbose output
      -M url      override the CATALINA_BASE manager's URL with
                  <{http|https}://<host>:<port>/<mgr-app>
      -B          override CATALINA_BASE environment setting
                  note: incompatible with -I option
      -I <alias>  manage instance by its alias name
                  note: use the alias 'home' for the home server
                  note: incompatible with -B option
                  note: alias names may not include the characters:
                          []\/.,*$#?+={}"'`
      -n          debug run action but do not execute changes

Any feedback would be appreciated.  I'm guessing that there are individuals out there who are getting this to work, and I am doing something unusual.

Verified Answer
  • You already have a webapp named 'oeabl' deployed in the same PASOE Instance. You need to deploy a named OEABL Web Application. So, for your case it should be something as below

    tcman deploy -a oeabl2 %DLC%\servers\pasoe\extras\oeabl.war anotherABLApp

    Option "-a" just copied oeabl WebApp as 'oeabl2'.

    Regards,

    Irfan

All Replies
  • Given the wierd error ("directory already exists - C:\OpenEdge\WRK\oepas5\webapps/oeabl") I am scrambling to find workarounds.  I am still trying to work with the "tcman deploy" command from the KB (https://knowledgebase.progress.com/articles/Article/How-to-create-multiple-ABL-applications-in-one-single-PASOE-instance).

    I found if I stop tomcat, and rename the "webapps" folder to "webapps_old", then restart tomcat, I can use the KB command and get a bit further.  My openedge.properties file is modified as I would expect.

    proenv>C:\OpenEdge\WRK\oepas5\bin\tcman deploy %DLC%/servers/pasoe/extras/oeabl.war another6
    verbose: checking for tailoring script in C:\Progress\OpenEdge\servers\pasoe\extras\oeabl.war
    verbose: execution complete
    info: Tailoring arguments: 'deploy -a oeabl C:\Progress\OpenEdge/servers/pasoe/
    extras/oeabl.war another6'
    info: begin deploy tailoring ABL for the Progress Application Server
    info: deploying webapp oeabl to application name another6
    info: Creating context.xml for context name oeabl
    info: adding properties to openedge.properties for ABL instance another6
    info: applications currently set to oepas5 in openedge.properties
    info: adding another6 to applications
    info: adding oeabl to webapps in openedge.properties
    info: psc.as.security.model is developer
    info: security model is developer
    info: enabling server status pages for development server
    info: setting intitial sessions to 2 for development server
    info: enabling APSV transport for development server
    info: enabling SOAP transport for development server
    info: enabling REST transport for development server
    info: enabling WEB transport for development server
    info: setting default WEB handler to OpenEdge.Web.CompatibilityHandler
    info: updating PROPATH with webapp directory
    info: updated PROPATH to ${CATALINA_BASE}/webapps/oeabl/WEB-INF/openedge,${CATALINA_BASE}/openedge,${DLC}/tty,${DLC}/tty/netlib/OpenEdge.Net.pl
    info: copying WebSpeed static files
    info: creating welcome page
    info: using static/ServerStatus.html as welcome page static/index.html
    info: looking for property file C:\OpenEdge\WRK\oepas5\webapps\oeabl\WEB-INF\tlr\Merge.properties
    info: performing cleanup
    info: restart server to start web application
    OK - deployed C:\Progress\OpenEdge/servers/pasoe/extras/oeabl.war to local directory C:\OpenEdge\WRK\oepas5\webapps as application oeabl

    sdf

    I stop and restart tomcat and can see that there are now two "ABL Applications".

    However I think my hacking was detrimental because the webapps folder is a lot smaller than it was (ie. as compared to webapps_old).  Also OEE is not displaying anything for Description/Version.  I haven't done any client testing yet but I'm not optimistic.

    Can someone give us better instructions on how to get around the error "Instance target directory already exists" when using the suggestion in the current KB?

  • You already have a webapp named 'oeabl' deployed in the same PASOE Instance. You need to deploy a named OEABL Web Application. So, for your case it should be something as below

    tcman deploy -a oeabl2 %DLC%\servers\pasoe\extras\oeabl.war anotherABLApp

    Option "-a" just copied oeabl WebApp as 'oeabl2'.

    Regards,

    Irfan

  • OK, I'll give it a shot.  Thanks for the tip.  My end goal is this.  I have a single project "CoolAppProjectCode" with a code module in it that compiles different r-code depending on the schema.  It may connect to one version of the database or another (say coolapp_db_v1_1, and coolapp_db_v1_2).  For each of those two, there needs to be a different deployment of code, and potentially a different PROPATH, working directory, etc.

    Hope this is clear.

    I thought I would be able to deploy that project twice within the same tomcat instance but it is proving very challenging.  In the first place, PDSOE seems to be unaware of "ABL applications" and always deploys to an ABL Application with the same name as the instance, even though my "Servers" definition in PDSOE was defined using another uniquely named "ABL Application".

    The next problem with deployments from PDSOE is that my deployed modules are "flattened" into the "catalina.base" without regard to my selected "ABL Application" or even "ABL web app name".  In other words, all of the ABL code that is deployed to the same TomCat instance will co-habitate in the same folder ({catalina.base}\openedge) without any kind of *separation* that might help uniquely identify it: the project name ("CoolAppProjectCode") or "ABL Application" or "ABL WebApp".

    So to make a long story short, I can't get the same project (albeit different r-code) to be deployed into the same tomcat instance, whether I am pointing at a new "ABL Application" or not.  Based on my limited understanding of "ABL Applications", this should be one of the scenarios for using them.  

  • OK, I sort of figured out how to work with multiple "ABL applications" (with potentially multiple web apps referencing them.)  I was able to get the scenario working that I described earlier.

    It was a bit of a challenge to work thru this stuff.  First of all, when multiple ABL applications and multiple ABL webapps are in play, the PDSOE does the *least* helpful thing it can possibly do when it publishes your code modules into "catalina.base"\openedge.  Essentially this causes all code, whether related or not, to be "flattened" out into the same massive code directory without any organization.  That particular directory is shared for the entire PAS instance.

    After a bit of a struggle with PDSOE, I finally resolved to start with an initial basic deployment of my code that would simply put it out under those folders (caralina.base).  Then I'd go into Windows Explorer and moving the published results to a new home: ${CATALINA_BASE}/webapps/mytargetwebapp/WEB-INF/openedge/...

    This is quite a bit of busy-work.  It seems like there should be a checkbox or radio set to select where stuff will be published.

    Another thing that was challenging was learning how to deal with openedge.properties.  It became clear pretty quickly that the relationships between "ABL applications" and "ABL web apps" are more elaborate than what the current user interfaces are able deal with (whether in OEE or PDSOE).  So you basically need to manually edit the properties file by hand (go into the "cataline.base"\conf directory to find it) and you need to execute a lot of intermediate "pasman start/stop" commands for your changes to take effect.  This seems unfortunate and I wish the U/I was able to manage that file better.  

    The openedge.properties file has a lot of issues.  I wish Progress would use XML-based configuration with a hierarchical structure because these properties files have bits and pieces that are spread all over the place in a bit of a haphazard way.  Worse yet, if you ever do end up "touching" the properties in a U/I (either via PDSOE or via OEE), then you will regret it because it will randomly rearrange the entire file and nothing will be where you remember it.

    I do appreciate the ability to have multiple ABL applications in a PAS instance but it is somewhat of a learning curve to get things working properly and there are a LOT of pitfalls; and the crude management user interfaces don't really help us to avoid them.  One of the things I would highly recommend is checking your "openedge.properties" into version control and regularly keeping new version of it.  This way you can see the differences in the properties as you make incremental changes and, more importantly, you can revert to a previous version if anything goes awry.  (For example, at the moment I've somehow lost my "manager" and "oemanager" web apps and I'll have to go back thru my versions and see where they went.)

    The biggest challenge that I've been struggling with (by far) is not really even related to PAS but related to switching from "shared memory" connections to "client/server" over the network.  There is a substantial performance hit for certain programs and I can tell it will be a major effort to re-write some of this legacy code...

  • >It was a bit of a challenge to work thru this stuff.  First of all, when multiple ABL applications and multiple ABL webapps

    >are in play, the PDSOE does the *least* helpful thing it can possibly do when it publishes your code modules into

    > "catalina.base"\openedge.  Essentially this causes all code, whether related or not, to be "flattened" out into the same

    > massive code directory without any organization.  That particular directory is shared for the entire PAS instance.

    Agreed.  We have plans/backlog items to make this better. You can do a couple of things in the interim

    - In your instances, there should be an ablapps/<abl-app-name>/ folder already (in 11.7 something, maybe .0). I’d add an openedge/ folder to that, and add that folder to PROPATH in the instance config. Now you should have a default propath that looks something like

    ${CATALINA_BASE}/webapps/ROOT/WEB-INF/openedge,

    ${CATALINA_BASE}/ablapps/oepas1/openedge,

    ${CATALINA_BASE}/openedge,

    ${DLC}/tty

    (assuming an ablapp of oepas1 and the default ROOT webapp)

    The ${CATALINA_BASE}/openedge directory is for common libraries/code like framework code.

    The ${CATALINA_BASE}/ablapps/oepas1/openedge folder is for this-application’s code (business logic)

    The ${CATALINA_BASE}/webapps/ROOT/WEB-INF/openedge folder is for service interfaces into that business logic

    -  In PDSOE set your publish location to ${CATALINA_BASE}/ablapps/oepas1/openedge

  • I didn't know about changing the publish location with PDSOE.  I'll take a look.  Thanks for the tip.

  • It was a bit of a challenge to work thru this stuff.  First of all, when multiple ABL applications and multiple ABL webapps are in play, the PDSOE does the *least* helpful thing it can possibly do when it publishes your code modules into "catalina.base"\openedge.  Essentially this causes all code, whether related or not, to be "flattened" out into the same massive code directory without any organization.  That particular directory is shared for the entire PAS instance.

    Agreed.  We have plans/backlog items to make this better. You can do a couple of things in the interim

    - In your instances, there should be an ablapps/<abl-app-name>/ folder already (in 11.7 something, maybe .0). I’d add an openedge/ folder to that, and add that folder to PROPATH in the instance config. Now you should have a default propath that looks something like

    ${CATALINA_BASE}/webapps/ROOT/WEB-INF/openedge,
    ${CATALINA_BASE}/ablapps/oepas1/openedge,
    ${CATALINA_BASE}/openedge,
    ${DLC}/tty

    (assuming an ablapp of oepas1 and the default ROOT webapp)

    The ${CATALINA_BASE}/openedge directory is for common libraries/code like framework code.

    The ${CATALINA_BASE}/ablapps/oepas1/openedge folder is for this-application’s code (business logic)

    The ${CATALINA_BASE}/webapps/ROOT/WEB-INF/openedge folder is for service interfaces into that business logic

    -  In PDSOE set your publish location to ${CATALINA_BASE}/ablapps/oepas1/openedge for the ABL Service projects/

    - You may need to manually deploy the code into the instance’s openedge/ folder.

               

     
     
  • Hi

    What about r-code refresh and other class reload. So far if we deploy using .war file it required PAS instance restart to get new code/classes in use. Paar file as incremental update is doing (should do) r-code refresh and reload any class (actually we've been told it does trim any existing session).   I'm assuming there's nothing which will force any r-code reload (especially classes already loaded) should there be any r-code changes in ${CATALINA_BASE}/openedge or ${CATALINA_BASE}/ablapps/oepas1/openedge therefore PAS instance stop/restart required ?

    Denis

  • Do you use the -q option to cache your r-code in memory?  This is probably what is "holding onto" previous versions of your r-code.  If you remove the "-q" then it should automatically pick up changes in your programs, once you've deployed them.

    In practice I always rely on "-q" , even in development.  That is primarily because much of our PROPATH resides on network-attached file server and, without -q, the AVM will spam the network with lots of hits on the underlying program files.  As an alternative approach, I rely on a short (10-20 second) PAS timeout to trim out my unused multi-session agent after a brief moment of inactivity.  Then I can be sure that PAS will pick up new r-code.  See here for more details on those timeout variables: community.progress.com/.../36188

    Here are other options for clearing out your r-code:

    ================

    * QUIT statement - in a given pacific appserver session, this should flush the entire AVM session.  Beware it may erase the work that you've done in your session startup event procedure.

    * "r-code trick" - in any session that this is trick is done, it will flush your saved r-code.

    knowledgebase.progress.com/.../P130577

    Hope these ideas are helpful.

  • When would you like to reload your r-code ? If it is development then you have two options

    1. terminate the agent, when you run a new request then it will start a new agent and will load the new r-code.

    2. terminate all free MS-Agent sessions, this will terminate all free sessions and when the new request comes it will start a new session and it will load the r-code.

    You can do both of them using oemanager or JMX API's.

    Regards,

    Irfan

  • Hi

    I'm more talking about CI/CD. If we do eg have web app running and we should proceed with code update. So far we do mainly undeploy/deploy web app which does require a PAS restart as per documentation. Incremental update should reload everything as expected included class constructor .... I don't think it's done otherwise regardless -q set or not (??). Terminating agent is a bit scary at least using OEmanager API as I've been told until 11.7.2 it's not gracefully stopping agent (so you should be sure there's nothing running and about to run).  

    Denis

  • In 11.7.2, we do a graceful shutdown. We wait for 10 seconds for all the requests that it is running to finish. If it still runs then it just terminates all the requests that are still running.

    Regards,

    Irfan

  • I figured out where in PDSOE to set the following (referenced by Peter Judge):

    "-  In PDSOE set your publish location to ${CATALINA_BASE}...

    The reason for setting this is to allow usto deploy ABL-application-specific, or PAS-webapp-specific code.  Otherwise the code gets piled into a single directory that is common to the entire PAS instance.

    I found the directory below (highlighted ) and my publishing operations are working.  I had to stop and restart the PAS instance as well as PDSOE before things started kicking in.  I'm not quite familiar yet with how/when things are supposed to sync between PDSOE and the PAS server (via OEE).  I basically cross my fingers (and restart everything a time or two) whenever I'm making changes in PDSOE and sending them over to PAS.

    Hope this helps anyone else who is looking to change the default "publish location".

  • (openedge.properties)

    Better yet, just go to the server itself and set the publish directory in the openedge.properties file.  This seems to be more reliable and consistent than trying to set it via launch configuration in PDSOE...

  • Even without -q being set, if you use static members in OOABL you may have similar issues (since classes with static members are not unloaded from memory until the session terminates).
     
    The best approach currently may be to use a separate instance behind a load balancer; that way you know that the new instance has the new code.