It's all about the answers!

Ask a question

Extend Jetty by DOORS Next and Global Config?

Thomas Noack (6028) | asked Feb 21, 5:10 p.m.


we have to develop the following:
  • Server Extension which ...
  • ... listens on Save button of EWM work item.
  • ... reads linked ERM changesets.
  • ... gets DOORS Next links from ERM changeset.
  • ... does something with Requirements.

So here is our issue: Our current setup uses a jetty-based debug server as suggested in IBM Rational Team Concert 7.x Extensibility Workshop.
The jetty-based debug server has ...
  • ... jazz context only (e.g., https://my.jetty:9443/jazz)
  • ... /rm, /gc, /qm are missing
  • ... hence, no cross-domain plugin testing and debugging is possible

Any ideas, how the debugging setup could look like when developing cross-domain plugins?
  • E.g., Jetty could be extended by ERM DOORS Next and Global Config?
  • E.g., Tomcat could be used for debugging and testing with full ELM installation?
  • E.g., Liberty could be used for debugging and testing with full ELM installation?

Thanks in advance for any hints :)
-- Kerstin and Thomas

3 answers

permanent link
Ralph Schoon (61.4k33643) | answered Feb 22, 2:18 a.m.

 The RTC Extensions Workshop is based on the EWM/RTC SDK. There are no SDK's available for any application other than EWM/RTC. The availability of the SDK and the ability to set up the plugin development environment in Eclipse with the SDK and the contained target platform make it possible to

  • To run the EWM server on Jetty and debug your extension code 
  • To run the EWM server on any other supported application server and debug your extension code 
"Jetty could be extended by....." makes no sense. 

As far as I can tell, you should be able to install a full ELM on Liberty following the the extensions workshop, run the WorkshopSetup and follow the extensions workshop. You can setup your test data on that system. You can debug the RTC Extension on Liberty as shown in the Extensions Workshop 1.5__32 . This depends on the availability and the setup of the SDK. You can not debug DNG or any other of the applications because you do not have an SDK.

In a setup like the one above, or if you create a friends relationship from your Jetty EWM server to a DNG etc. server you can only debug RTC. The system however should be complete enough to test e.g. linking to DNG.

K. Hartig commented Mar 01, 9:44 a.m. | edited Mar 02, 2:12 a.m.
Thanks a lot for your response.
We have a full ELM on Liberty. In our case, debugging as shown in the Extensions Workshop 1.5__32 on Liberty works in general.
However, at the moment we can not debug and test as we wish because our code to be tested/debugged should be triggered by saving a work item.
For that we have an operation participant (similar to the BuildOnStateChangeParticipant in the Workshop) that we'd  like to add as follow-up action on Save Work Item (server) in the process configuration.
But on Liberty, this follow-up action can not be selected because it is unknown.
For Jetty, the bundles would be provided in the run configurations, so the follow-up action can be selected. I guess, the participant needs to be introduced somehow to Liberty as well.

Do we miss something obvious here?
The goal would be to start Liberty in debug mode, go to our ccm/admin and select our operation participant as follow-up action in the process configuration. After that it should be possible to modifiy a work item and test if the actions that we implemented work correctly.

Thanks in advance for any advices on that topic.

permanent link
Ralph Schoon (61.4k33643) | answered Mar 01, 10:00 a.m.
edited Mar 01, 10:00 a.m.

If an follow up action works on Jetty and it does not on Liberty, it is 99% due to a deployment issue. Plugin.xml missing, meta-inf missing. Generated with wrong Java, Plugin.xml incorrect, dependencies to client or not existing API. The CCM server log might provide hints.

You have client API in the server development workspace, if you are not careful, you pick that up in your dependencies. It would work in Jetty, but not in liberty. In Jetty it is surfaced by the workspace. In liberty it is unavailable. I found an old example of mine recently and discovered that I had such a case and did not realize since I did not test deploying that in liberty. Client API usually has .client. in the package name.

As explained in the extensions workshop you should be able to connect the Eclipse development client with the extension, connect debug to the liberty server, search for the server extension class and debug. Make sure your extension is correct and correctly deployed first.

K. Hartig commented Mar 01, 6:22 p.m. | edited Mar 02, 2:12 a.m.

I tried to do the same with the Workshop example, because this setup should work, everything is configured as suggested, no missing plugin.xml, no dependencies to client etc.
Starting liberty in debug mode leads to the same result. The Build on State Change Operation Participant can not be selected as a follow-up action. With Jetty it is possible.
It seems to me that the only difference is in the debug configuration of Jetty and Liberty.

I can add the two bundles for the participant (extensions.common and extensions.service) to Jetty but in the Liberty configuration there are no options for introducing the bundles. I guess I need to find an answer to the question: How can the participant be introduced to Liberty?

Ralph Schoon commented Mar 02, 2:13 a.m.

 You Do Not Use Bundles on liberty. You create the required features, the update site and the provision profile. If you follow the workshop, this is explained in detail in the last lab. Once the extension is built, it is deployed (copied into) the ccm folder. You have to perform all the labs of the extensions workshop to be able to deploy it on liberty.  

permanent link
K. Hartig (11) | answered Mar 03, 1:56 p.m.
Thanks a lot for the advices. Deployment on liberty works and our operation participant can be selected and tested.
However, when we started this thread we were hoping that there is another solution to debug/test on Liberty without going through the entire deployment process because this is very time-consuming during development. We were hoping for a debug/test solution similar to the Jetty approach but on our full ELM on liberty.

Ralph Schoon commented Mar 07, 10:22 a.m.

As far as I am aware there is not. Develop on Jetty as long as you can. Avoid to debug on Liberty. Once everything works on Jetty, deploy on Liberty and do final testing of deployment and function. 

Your answer

Register or to post your answer.