Is The Extension Deployed? How Can I Redeploy?

This is a question that comes up every so often in the forums. Unfortunately there is no place, I am aware of, where this really gets explained and it seems to require the knowledge of mysterious URL’s. Is there an easy way?

I wanted to always blog this, but somehow I just never did. Let’s unveil it now.

Just Starting With Extending RTC?

If you just get started with extending Rational Team Concert, or create API based automation, start with the post Learning To Fly: Getting Started with the RTC Java API’s and follow the linked resources.

You should be able to use the following code in this environment and get your own automation or extension working.

Differences between Tomcat and WebSphere Application Server

The deployment process on Tomcat and WebSphere Application Server (WAS) is basically the same. The folders where you deploy the extension are the same within server/conf/ccm . The mechanisms described below work the same for WAS, except the location of the file built-on.txt.

Internal Tools

The best way to check if a server extension is deployed on a server is to use some Internal Tools. These hidden Internal Tools are also the easiest way to enforce redeployment of the applications and added extensions.

The internal tools can be accessed by injecting the string ?internal=true into the server administration URL for a Jazz application. This makes it available on the Server Administration page. It is possible to append the string above behind the URL for the main administration pages and then open the server administration. If the server administration page is already open and it contains an action the string needs to be injected before the # (hash tag) separating the action from the base URL.

The image below shows the injected string in the server administration page before the action.

The image below shows the URL when just appending the string before opening a specific server administration page.

An URL like

 https://<server>:<port>/jazz/admin?internal=true#action=jazz.viewPage&id=com.ibm.team.repository.server

shows the internal tools menu that can then be used to look at data that is usually not revealed.

Use the Component Status menu action to check if an extension is deployed. It opens the Component Status page with all components that are deployed. You can then use the browsers find functionality to search for your extension, or rather the name of the component you chose. If you followed my advice and chose a unique and easy naming schema, you should be able to find it. The image below shows the example of the RTC Extensions Workshop at the end of the list. Searching for rtcext revealed this in no time.

If your component does not show up, fix your deployment and try again.

Use the Server Reset menu action to trigger a re-provisioning of all extensions. Reboot the server after pressing the button. If a new version of an extension is deployed, this makes sure that the cache gets deleted and all the features, including the new version, are re-read.

Server Patch Extension

** Update ** Eric suggests another way to be able to see your extension in the comments below. Use the Server Patch Extension – https://jazz.net/wiki/bin/view/Main/ServerPatchExtension so that your plugin is listed on the CCM Admin Page

“Undeploy” or Deploy a Fix or New Version

To get rid of custom extensions, it is necessary to remove the files that belong to the deployed extension and then you have to force a server reset and redeploy. The files that typically belong to a server extension are

1. The provision profile file. This is a file with extension *.ini  located in the  server\conf\ccm\provision_profiles folder, created for the extension that specifies the feature and its site location
2. The extension specific site folder usually located in the folder server\conf\ccm\sites  that contains the site.xml and the plug-ins and features in sub folders

To update or deploy a new version you can:

1. Deploy the new version (overwrite the existing files mentioned above)
2. Force a server reset and restart the server

This works if the file names and the structure does not change. If you are not sure and you don’t want to leave any remnants you can

1. Undeploy the old version by removing all deployed files and folders
2. Deploy the new version
3. Force a server reset and restart the server

This is the most secure approach.

Force Server Reset and Redeploying using Internal Tools

The runtime of the Jazz servers caches information about deployed applications. If a new version of an application is deployed, the server would not pick that up and would not redeploy it. To enforce redeploying, it is necessary to request a server reset. There are several ways to do that.

One way is to use the Internal Tools and click on the Server Reset menu action. On the page displayed, click the Request Server Reset button. Next time the server is started, all plugins are redeployed.

Force Server Reset and Redeploying – Alternative Approach

If your server is not up, another way to enforce a server reset is to search for the file built-on.txt in the work folder of your application server. If this file is deleted, a server reset is performed the next time the server starts. For Tomcat you can find the file in the work folder of the application.

For the traditional WebSphere Application Server you should find the file located somewhere underneath the profile folder.

For the WebSphere Liberty Profile application server, you should find the file located somewhere underneath the workarea folder. E.g. in [Install Dir]\JazzTeamServer\server\liberty\servers\clm\workarea\.

Please note that the built-on.txt file is also located in WEB-INF folder in the WAR file and in the WEB-INF folder of the deflated war file. Don’t delete these files.

Summary

The Internal Tools provide an easy way to find out if a custom component is deployed and to request a server reset.

As always I hope this helps practitioners out there to be more effective.

Advertisement

JMX Monitoring of a CLM Tomcat Server only with the CLM Webinterface

Stefan is doing some amazing work here and I think you might be interested. This is an example for server monitoring in a dashboard.

Steve Blog

[Update: Source Code now with Garbacollector]
Sometimes it is necessary to tackle down CLM performance issues. To monitor the OS resources like CPU, IO, Memory etc. is not really helpful, because Java is like a black box for an OS like LINUX. With JMX you can look “behind the scene”.

You can monitor the Heap, Threads, Memory and other things from a CLM  Tomcat Server. With the help of some JMX settings you can access this information with jconsole. jconsole is include in every Java JDK (not JRE) since 1.5.

But JMX has some disadvantages:

• Only Java
• Problems with firewalls. Especially Productive CLM server are in a protected environment, so it is nearly impossible to get access with your jconsole.
• “All or nothing” protection

Today we will create a Open Social Widget that will show the amount of running Threads, Heapsize, CCM Requests and Garbage Collector with the help of JMX…

View original post 105 more words

Impacts of having Multiple CCMs in your RTC deployment

Tim and I would be really interested in any feedback you could provide on Tim’s blog post.

Tim Feeney's Blog on Jazz

My colleague Ralph Schoon (rsjazz.wordpress.com) and I are working on documenting the motivations, tradeoffs, pros and cons when deploying multiple instances of the same Jazz application. That is, cases where you have more than one CCM server and/or more than one QM server registered to the same JTS.

Our findings and guidance will eventually make its way to the Rational Deployment Wiki and an Innovate 2014 presentation. I wanted to begin to surface some of the findings now to perhaps uncover some things we haven’t yet.

Jazz allows Multiple CLM Applications

It is possible to deploy multiple instances of the same application each registered to the same JTS. Today this is possible for the Change Configuration Management (CCM) and Quality Management (QM) applications. The Requirements Management application does not yet support multiple instances yet, however, follow RM Plan Item 76315 to track progress towards that.

There are several…

View original post 379 more words

Beware of the Underscore

I ran into a funny situation today and that cost me a lot of time. Maybe this post helps other users to avoid the issue.

This has nothing to do with extending RTC, but it shows that the devil is in the details, so I wanted to share it.

Do you know which characters you can use in host names? I obviously didn’t and that cost me 2 hours.

While trying to finalize a workshop, I was blocked by an odd error message during the  setup. I have never seen this error before and I installed the same version last week – several times. The error said: “An unspecified server error has occurred”.

When I continued to the next page of the wizard, no public URI was visible. I was very confused. I looked into the jts log file and there was an exception that complained about an illegal host name. The host name I used was prod_a. I am relatively sure that I had used the same name in the past, without issues. It was still in my hosts file on my machine.

So I blamed auto update, new Java versions and all other potential root causes for it. Trying to find a potential reason and work around I installed and set up RTC over and over. I tried different versions of RTC. To no avail. I even tried localhost – but the old name was in the configuration somewhere, so this did not fly either. Finally I did a full new install with localhost and that worked.

Since I had also changed the hosts file, I blamed myself for some issue with editing, tidied that up a bit and tried the original name prod_a again. Same result as before.

I finally gave in and looked at the Wikipedia entry on host names. Only a-z, 0-9 and – (hyphen) are allowed in host names. I was not aware of that fact and others might not be as well.

The disturbing issue is that browser(s) I used do not have any problem with the host name. They use it, Tomcat works with it too. It is only in the JTS server, when the name is validated, that an exception is thrown. This has nothing to do with a defect in the programming. Basic Java classes for managing URI’s throw the exception. The only thing that could be done in the application would be a better error message – and a hint to Wikipedia.

My Learning, what could I have done different?

• Trust the error messages and log files and evaluate into that direction
• Read available information on the internet, even if you think you already know all the facts
• Regardless how often you did a task, you still can run into trouble

I hope this was at least interesting to read and helps others that run into into something similar and are so smart to look into the internet for solutions.