search

ibm-cloud-architecture / refarch-jee

This project provides a Reference Implementation for migrating existing Java EE applications from on-premise to cloud-based deployments, as well as migration to a microservices-based architecture.
Apache License 2.0
17 stars 21 forks source link

Removing Feature Packs #9

Open dhvines opened 7 years ago

dhvines commented 7 years ago

You may be right on this, but I would wait on taking this action until testing showed that is was a real not an imagined. In fact, I would continue to include those jars in the application so long as it does not violate the license agreement. Once again, remember that the app worked with that set of libraries so keep it unless you absolutely know or determine that the app will not work with that jar.

In addition to this, you should also remove old WebSphere Application Server specific libraries. In our case, we should remove the reference to the IBM WebSphere Application Server traditional V7.0 JAX-RS Library which was installed as a Feature pack:

So I would keep it at this point and simply note that this is a potential problem. .

jesusmah commented 7 years ago

@dhvines I am confused here... The IBM WebSphere Application Server traditional V7.0 JAX-RS Library was installed as a Feature Pack for WAS 7 since it does not come with such features by default. As a result, we did not only have to point RAD/eclipse to those libraries in order to get the code to compile but also had to define those libraries in WAS admin console as shared libraries too so that WAS could use them at runtime.

I would agree with what you say above if the lifted and shifted app was to run on the same machine as the WAS 7 app is running since we could always define those libraries in WAS 9 as shared libraries too.

However, the app is going to be shifted to a WASaaS instance where we can not point to the WAS 7 feature pack libraries since they are not in that environment at all... So that was the main idea behind removing old WAS 7 "external" libraries. That is, if we are lifting and shifting our apps to run a box with a WAS 9 installation only, should we not adequate our app with intermediate steps like this one to the environment it will live on in the future?

Am I mistaken here? Am I missing something?

dhvines commented 7 years ago

The key to remember is that the app worked "as is" using the "as is" jar's and the "as is" packaging. So "the main idea" in the "lift and shift" pattern and any "like for like" migration strategy is to maintain the existing packaging/libraries.

As mentioned in my earlier comment. Getting "the import cannot be resolved" error in eclipse is the first error that you want to resolve when you start the "source code migration" (WAMT). It is not something that you want to do as part of the "assessment" (binary scanner).

As well, the reason for these "import cannot be resolved" errors in eclipse are generally two fold:

  1. The app is using some open source library from WAS 7. The solution is to get that library from WAS 7 or download the exact same version from the internet and add it to the WAR (web-inf/lib). This will resolve the "import cannot be resolved error".

  2. The app is using some library from a shared library that is not packaged with the WAS. Again, the solution is to find that library and add it to the WAR (web-inf/lib folder). This will also resolve the "import cannot be resolved" error in eclipse.

Of course, you will still need to test the app to make sure it works. But so long as the app is loading the same classes and libraries is "should work" or it will have a much better chance of working. The more you replace jar with different jars or change the packaging the greater change you have of the app not loading the same set of classes that used to work