4 Replies Latest reply on Jun 26, 2019 1:13 PM by jewellgm

    Migrate old jsp website/app from jboss 3.0.8 to wildfly 17 final

    drpatso

      Hi,

       

      Is this possible, will the old jsp website code be compatible? I am just hoping someone can set me off on the right track. I have found what I believe to be some old .ear files of the webapp in a backup folder. The webapp uses mysql and apache tomcat, login pages etc are all .jsp.

       

      extra details: This is running on a dying unsecure build of centos 5 and I have wildfly stood up on a new centos 7 server.

        • 1. Re: Migrate old jsp website/app from jboss 3.0.8 to wildfly 17 final
          drpatso

          Found out apache tomcat runs just the reports engine but the main app is jboss.

           

          I found a list of CentOS RPMs for the jboss webapp. My theory is I get these, connect wildfly to the local mysql database and deploy the .ear file in wildfly and see what is broken or what errors I have on import. My first time working with a java app server.

           

          compat-libstdc++-33-3.2.3-47.3.x86_64.rpm

          libXau-devel-1.0.1-3.1.x86_64.rpm

          libXmu-1.0.2-5.x86_64.rpm

          libXp-1.0.0-8.1.el5.x86_64.rpm

          libXp-devel-1.0.0-8.1.el5.x86_64.rpm

          xorg-x11-deprecated-libs-6.8.2-1.EL.52.x86_64.rpm

          xorg-x11-libs-6.8.2-1.EL.52.x86_64.rpm

          xorg-x11-Mesa-libGL-6.8.2-1.EL.33.0.4.x86_64.rpm

          xorg-x11-xauth-6.8.2-1.EL.52.x86_64.rpm

          • 2. Re: Migrate old jsp website/app from jboss 3.0.8 to wildfly 17 final
            jewellgm

            I don't know anything about CenOS, so can't help you with that.  With that out of the way, it's unlikely that the application will deploy or work properly on even a relatively recent version of wildfly without modification.  Based on the limited information you provided, I am guessing you'll have at least the following issues:

            1.  You don't say whether there's any sort of authentication to access the web pages.  The authentication mechanism has changed since that older version of jboss.  (Tomcat is no longer used in jboss at all, and the "Tomcat Authentication" class doesn't exist.)

            2.  JNDI names (names that are used to look up things like data sources and EJBs) have changed due to Java EE spec changes.

            3.  If Entity Beans are used to represent the data in the DB, there's a good chance that the app is using an older spec that wildfly no longer supports.  If the app is making direct JDBC calls, then it may work, but you also may need to update the JDBC driver that's being used.

             

            There are other potential issues, of course, but those immediately jump into mind.

            • 3. Re: Migrate old jsp website/app from jboss 3.0.8 to wildfly 17 final
              drpatso

              Thanks Greg for the insight, I really appreciate it. The only option appears to be migrate to a new platform or somehow get jboss 3 and an older java version to run on a new platform, which doesn't resolve the inevitable complete death of this application. The jboss webapp definitely has authentication, sorry for my ignorance with java app servers. I see a lot of bean references so I think your point in number 3 would be a giant road block in migration. This is not surprising with java application server software released in 2003.

               

              Some examples of the hundreds of errors I get trying to deploy the backup .ear file.

               

              "jboss.naming.context.java.comp.oss.inventoryListEJB.InvSearchItemItrBean.ValidatorFactory is missing [jboss.naming.context.java.comp.oss.inventoryListEJB.InvSearchItemItrBean]",

               

              "jboss.naming.context.java.comp.oss.SecurityEJB.SecurityBean.ValidatorFactory is missing [jboss.naming.context.java.comp.oss.SecurityEJB.SecurityBean]",

              • 4. Re: Migrate old jsp website/app from jboss 3.0.8 to wildfly 17 final
                jewellgm

                Those particular error messages can be somewhat misleading.  Basically, something in your deployment bombed out, and something else in your deployment depended on the thing that bombed out, which in turn causes the second thing to bomb out.

                 

                You did specify on your initial post that there are login pages -- I just missed that part of it.  Login pages definitely imply some sort of authentication is occurring.