8 Replies Latest reply on May 19, 2015 4:43 PM by Patrick Wolf-Oracle

    Run Apex 4.2.6 and APEX 5 on same database parallel

    hafferl

      Hi,

       

      Is it possible to install Apex 4.2.6 and Apex 5.0 on the same database? If Apex Listener is used as Application Server, do I have to install two different Listener Instances as well?

       

      Thanks

        • 1. Re: Run Apex 4.2.6 and APEX 5 on same database parallel
          TexasApexDeveloper

          In 12c, you can do this if you license the proper database options.  Re: Multiple listener's, not needed if you configure ORDS properly..:

           

          12c Multiple instances of APEX : http://docs.oracle.com/database/121/HTMIG/db_pluggable.htm#HTMIG29169

          ORDS with multiple APEX instances: http://blog.smartdogservices.com/single-ords-install-multiple-instances/

           

          Thank you,

           

          Tony Miller
          LuvMuffin Software
          Ruckersville, VA

          • 2. Re: Run Apex 4.2.6 and APEX 5 on same database parallel
            Kiran Pawar

            Hi 1060959,

            1060959 wrote:

                Please change your user handle from "1060959" to something meaningful. Refer : Video tutorial how to change nickname available

            Is it possible to install Apex 4.2.6 and Apex 5.0 on the same database? If Apex Listener is used as Application Server, do I have to install two different Listener Instances as well?

                Please provide your environment details. This helps the forum members to give a more appropriate reply.

                I agree with Tony's reply. This is possible in Oracle Database 12c, when you have PDB Based Oracle APEX Installation. By default Oracle Database 12c comes with CDB Based Oracle APEX Installation. You have to remove it first using the apxremov_con.sql script.

                Once you have removed CDB Based installation, you can install multiple versions of Oracle APEX in different PDBs.

                Then you can go with Tony's link above regarding configuring Oracle REST Data Services(formerly APEX Listener) for multiple versions of APEX.

                This link also might help you : Dimitri Gielis Blog (Oracle Application Express - APEX): Preparing architecture for APEX 5.0 upgrade

             

                 Installation Notes:

            • You should have two PDBs created/cloned(as mentioned in the Dimitri's blog above)
            • By default PDBs are in MOUNTED state. Be sure that they are opened before starting the installation.
            • Verify in which container you are in first, if your container is not the required PDB, then switch to the required PDB before going for installation.

             

                Hope this helps!

             

            Regards,

            Kiran

            • 3. Re: Run Apex 4.2.6 and APEX 5 on same database parallel
              hafferl

              Hi,

               

              Thanks for the answer.

               

              Unfortunately I use Oracle 11g so I guess I can't use both APEX versions on the same database. I guess we'll set up a new DEV environment to get started with APEX 5.0.

               

              Thanks

               

              • APEX version: 4.2.6
              • DB version, edition and host OS: 11g
              • Web server architecture (EPG, OHS or APEX listener), server platform, and host OS: Tomcat 7
              • 4. Re: Run Apex 4.2.6 and APEX 5 on same database parallel
                Billy~Verreynne

                12c is not the solution either - multiple PDBs running different Apex versions are equivalent to running separate 11g databases with different Apex versions. It is not different Apex versions in the same database by any stretch of the imagination.

                 

                Fact. Apex (at this stage) does not allow 2 (or more) different version runtimes in a database as it uses global objects (created as SYS). This means that installing a specific Apex version, creates SYS objects for that version. Installing a new version will destroy the previous version's SYS objects, invalidating the runtime of that version.

                 

                Of course, it boggles the mind as to why on sweet blue earth Apex creates application objects in the holiest of schemas, SYS.

                 

                If Apex objects were not created in SYS, but in a unique app schema for that purpose, one would easily be able to run different versions of Apex in the same database.

                • 5. Re: Run Apex 4.2.6 and APEX 5 on same database parallel
                  Kiran Pawar

                  Hi 1060959,

                  1060959 wrote:

                   

                  Unfortunately I use Oracle 11g so I guess I can't use both APEX versions on the same database. I guess we'll set up a new DEV environment to get started with APEX 5.0.

                       In Oracle Database 11g as well you can two versions of Oracle APEX, but on different database instances(not on the same database instance, hence Oracle Database 12c is preferred).

                       Using DBCA create a new database instance, configure database listener and install Oracle APEX 5.0 on that instance.

                       Then you can configure the new database and Oracle APEX 5.0 with Oracle REST Data Services as mentioned in the links above.

                   

                       NOTE : If you want that both APEX versions should run in parallel then, you should have both database instances(and database listeners) up and running.(If it is not too much to handle for your hardware configuration)

                   

                       Hope this helps!

                   

                  Regards,

                  Kiran

                  • 6. Re: Re: Run Apex 4.2.6 and APEX 5 on same database parallel
                    Patrick Wolf-Oracle

                    Hi Billy,

                    Of course, it boggles the mind as to why on sweet blue earth Apex creates application objects in the holiest of schemas, SYS.

                    If Apex objects were not created in SYS, but in a unique app schema for that purpose, one would easily be able to run different versions of Apex in the same database.

                    the reason for this is security considerations. Only in the SYS schema, objects are protected against being replaced if a user/schema does have the CREATE ANY PROCEDURE privilege.

                     

                    Also keep in mind that some of our APIs do have to be public with public synonyms (like V, APEX_UTIL, APEX_APPLICATION, ...) so that they can be used by the different workspace schemas without having to create private synonyms. That's another issue which makes it hard to run different versions of APEX. Creating private synonyms to different APEX versions would also not be the final solution because many customers actually ask to install two different versions of APEX and run the same application (same workspace schema) with the old APEX version and in parallel test it with the new APEX version. So the problem is a little bit more complex as it looks.

                     

                    But we are aware of the request to run multiple versions and might come up with a manageable solution in a future release.

                     

                    Regards

                    Patrick


                    Member of the APEX development team

                    • 7. Re: Re: Run Apex 4.2.6 and APEX 5 on same database parallel
                      Billy~Verreynne

                      Thanks Patrick.

                       

                      However I still view SYS as forbidden territory for application objects. And especially when it comes to security as NO user code should EVER be allowed to execute in system space. Even when that user code is written by Oracle.

                       

                      A fundamental principle I am not prepared to compromise upon. Even for an excellent product like Apex.

                       

                      Do not have an issue with public synonyms though - understandable from a scope resolution perspective. For multiple versions though, scope should be able to be dealt with using the Oracle logon schema (as configured on web server side) and private synonyms?

                       

                      The reason my Apex dev team and I would like multiple versions to coexists, is to deal with explicit runtime upgrades to an app. I.e. install new Apex version, import app into it, test and port, and then make the new Apex version the default version.

                       

                      Apex automated upgrades are great - but management is severely risk averse. And we have modified Apex apps (use a lot of Jquery inside regions, etc). So it is always an issue when wanting to upgrade Apex and convincing management that the risk of an app not working afterwards is low.

                       

                      Nor can we upgrade dev environments easily as when you do, and with prod at a lower version, you loose all ability to deploy app patches to prod, until it is the same (or later) version.

                      • 8. Re: Re: Re: Run Apex 4.2.6 and APEX 5 on same database parallel
                        Patrick Wolf-Oracle

                        Hi,

                         

                        I do understand your argument that there should be no custom code in SYS. But in the case of the APEX engine it's a must have to guarantee security. You might know or not know, but APEX is using SYS.DBMS_SQL_SYS package (a more powerful version of the DBMS_SQL package) to execute application code/DML statements with the privileges of the parsing schema of the executed application. Obviously you don't want to grant execute to that package to another schema than SYS because of the power of package to run code in the name of another schema/user.

                        Do not have an issue with public synonyms though - understandable from a scope resolution perspective. For multiple versions though, scope should be able to be dealt with using the Oracle logon schema (as configured on web server side) and private synonyms?

                         

                        Unfortunately this would not be sufficient because the Oracle Logon Schema (most of the time called APEX_PUBLIC_USER) specified for mod_plsql/ORDS is only used to call the entry points of the APEX Engine like the F procedure or WWV_FLOW.SHOW and WWV_FLOW.ACCEPT. This would work fine until custom PL/SQL code or SQL/DML statements of your application have to be executed. This is not done with the privileges / scope of APEX_PUBLIC_USER, instead the code will be executed with the Parsing Schema specified for your application (that's where the above described SYS package comes into play). Otherwise APEX_PUBLIC_USER would have to be a super highly privileged user with access to any schema, which isn't the case. Instead it's a super low privileged user.

                         

                        Let's continue our example. If the application PL/SQL code / SQL or DML statement references one of our public APIs like V, APEX_APPLICATION, APEX_UTIL, ... or an APEX view we are in the the situation that the application schema has to resolve those references. But a schema can just point to one APEX version.

                         

                        How could that be solved?

                         

                        When copying the application to the new APEX version, the application parsing schema would have to be changed to a new 'proxy' application schema with access to the original application schema. The 'proxy' schema would point it's private synonyms to the new APEX version. But even then it's getting tricky if the original application schema has definer rights packages which do reference APEX apis, because those would still point to the public synonyms. As I said, it's not so easy and there are many traps customers could fall into ending up with a situation where it's hard to diagnose if an application is trying to call different versions of APEX in the same runtime session.

                         

                        But as I said, we are totally aware of the situation that customers would like to do a slower one by one application upgrade of their APEX installations to avoid breaking apps.

                         

                        Regards

                        Patrick


                        Member of the APEX development team