Compiling java, building jar's locally and copy them to application container war files manually

I heard that there is a process that is been followed to build the jar files externally for custom java code and copy them to the iw-cc.war/WEB-INF/lib and iw-preview.war/WEB-INF/lib. Then restart (iwreset -a) can avoid the OOTB maketoolkit/build process .

1. Is this a recommended process inserting the jar files manually to applicaiton container war files. Are there any side affects short/long term due to this like corruption of file system/ootb files during normal build process.

2. iwreset -a vs maketoolkit which takes more time practically. I have done one practical run and it varied some times iwreset and some time maketoolkit wins the race.

3. If I have java file(s) I am aware that, I can place it under customer_src and run maketoolkit. On similar case, if I have a jar file, where I can keep this in order to run the maketoolkit. Do I have put it under customer_osrc/lib. Is this the right place.

any help with your experience is much appreciated. Thank you.

Find more posts tagged with

Comments

Rick Poulin

It most definitely is not recommended, because your customizations will be removed when you upgrade/patch or under a small set of other circumstances. The recommended process is to copy them into customer_src/lib and livesite_customer_src/lib as appropriate, and run the build. Since you're skipping the compile phase, you're still saving yourself most of the time consumed by the OOTB process.

2. iwreset -a vs maketoolkit which takes more time practically. I have done one practical run and it varied some times iwreset and some time maketoolkit wins the race.

iwreset -a resets all UI-related services, whereas the build process only restarts JBoss. Therefore, the latter is always going to be faster as far as the services reset part.

Yep. The only difference is that files under /src are compiled into a JAR called customer.jar (or livesite_customer.jar). If you compile your code externally and drop the JAR into the /lib folder, the result is equivalent. Just make sure to call your JAR something else that doesn't conflict with what's already in the classpath. I typically use "orgname-teamsite.jar" and "orgname-livesite.jar".

shameem

Thank you. All answers were right on point.

However need more details on "small set of other circumstances" due to which process mentioned is risky.

Anything on top of your mind that has caused an issue due to this backdoor process. This information will help in justifying the proper process.

Rick Poulin

The issue is that the folder structure within the ApplicationContainer is the "compiled" version. There are some circumstances that cause iw-cc.war to be deleted and rebuilt from source. In this case, "source" is the union of TeamSite/private/lib, customer_src, livesite_customer_src, and possibly a few other files. Thus, any files you place within (livesite_)customer_src are "safe" because the things that rebuild the app are written to look there, and this is explicitly supported per the UITK development guide.

Things that usually trigger a full rebuild (there may be others):

* Product upgrades through installers

* Executing the install instructions of some but not all product patches

* Running a build after changing certain files in (livesite_)customer_src (notably, web.xml and webapp.ver)

* Running a build when a previous build "broke" the app and left it in an inconsistent state

* Running a build when permissions prevent your user from reading certain files in iw-cc.war

* Running install_webapps.ipl for any number of reasons

Read: a full rebuild would not happen on its own, but sometimes you might do something on the box without realizing that it triggers a rebuild, and that's when you get into trouble.

shameem

Thank you very much. This will certainly help.