It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,826

question asked: Nov 14 '14, 2:52 p.m.
question was seen: 3,007 times
last updated: Nov 14 '14, 4:28 p.m.

Related questions

FAQ - How this Forum works

RTC API handling ChangeSetHandles and other things

0
1
Zaid Al-Khishman (35●11●15) | asked Nov 14 '14, 2:52 p.m.
edited Nov 14 '14, 2:53 p.m.
So I'm implementing an OperationAdvisor for the Deliver operation. All I need to do is get the names of the files that are associated with the ChangeSet and the User who's checking them in.

Places I've already looked at which are relevant(which may be useful to some implementing similar things):
https://rsjazz.wordpress.com/2012/11/01/restrict-delivery-of-changesets-to-workitem-types-advisordelivery-of-changesets-associated-to-wrong-work-item-types-advisor/
I noticed that in the aforementioned blog that the class being extended is AbstractScmService (in contrast to the regular AbstractService) but this seems to be an internal class and I'm trying to avoid using it.

http://jorgediazblog.wordpress.com/2014/04/01/work-item-cross-stream-deliveries-and-promotion-a-sample-precondition/
https://jazz.net/wiki/bin/view/Main/CustomPreconditionsTable

https://www.ibm.com/developerworks/community/blogs/extendingrtc/entry/checksummaryadvisor?lang=en


I also looked at some API examples here:
https://jazz.net/wiki/pub/Main/RTCPlainJavaAPIs/
but those seem to be client-side oriented.

This is where I'm currently at: 
public class AbstractService extends

		com.ibm.team.repository.service.AbstractService implements

		IOperationAdvisor {

	@Override

	public void run(AdvisableOperation operation,

			IProcessConfigurationElement advisorConfiguration,

			IAdvisorInfoCollector collector, IProgressMonitor monitor)

			throws TeamRepositoryException {

		System.out.println("operation advisor called");

		// get the deliver data

		Object o = operation.getOperationData();

		if (!(o instanceof DeliverOperationData)) {

			System.out.println("Something went wrong");

			//return;

		} 

		

		DeliverOperationData data = (DeliverOperationData) o;

		for(IChangeSetHandle ChangeSetHandle : data.getChangeSetHandles()){

			

		}

                /* alot of generic object printfs in loops that weren't leading me anywhere here */

           }

}

I noticed that IContributorHandle and IChangeSetHandle ultimately extend IItemHandle, but how are those Handled? How do I eventually get the filenames associated with each change set? I managed to extract the files' timestamps through some light  run-time debugging, but all I was doing was simply inspecting object members during run-time without using the intended interface functions to get them (the API that I'm looking for).

Thanks,

Info:
RTC version (Server and client): 4.0.7
JDK/SDK : RTC stock 4.0.7 JDK/SDK

Accepted answer

1
permanent link
sam detweiler (12.5k●6●195●201) | answered Nov 14 '14, 3:03 p.m.
edited Nov 14 '14, 3:06 p.m. 
handles are unchangeable (immutable) objects that are stored in the database. 
they contain the linkage to reconstructing the complete object. 
(a handle can be reconstructed from its UUID)

with some item manager api request to 'load' the full (or some subset) object contents.
here is an example I use in my RTC Deliver participant. 

private static IRepositoryItemService fItemService = null;
fItemService = getService(IRepositoryItemService.class);
(this needs to be added to the plugin.xml pre-reqs for this plugin)

if(operation.getOperationData() instanceof IScmDeltaSource)
{		
   // need the project area name later
   IProjectArea projectArea = (IProjectArea) fItemService.fetchItem(operation.getProcessArea().getProjectArea(), new String[]{IProjectArea.NAME_PROPERTY_ID});

the item manager takes a handle to an object and reconstructs the in memory instance of the
object with the requested properties resolved.
Zaid Al-Khishman selected this answer as the correct answer
Comments
sam detweiler commented Nov 14 '14, 3:24 p.m.

getting to the filenames is a fun exercise.. RTC is an object oriented system so you need to work thru the object relationships..

some of which are clear, and some of which are not.

there is no design doc (or class diagram) like of old.
in addition, while the client side has SOME info documented, the server side is NOT documented at all. (other than the workshops that give you the base  mechanics on creating plugins).

eventually you will get to the IContent object containing the actual source

the best thing to do is figure this out from the client side, so you get the process down, then move the client code to the server and modify as required for the different api access


Zaid Al-Khishman commented Nov 14 '14, 3:32 p.m.

I see, how does the second arguement to fetchItem  (the properties passed as a string) affect the Item that is returned?

sam detweiler commented Nov 14 '14, 3:39 p.m.

argument 1 is the handle, argument 2 is the list of property names  of the values to populate from the repository. FOR THAT ObjectType

if you are using eclipse , 

object_name. should bring up the list of methods and visible data items.

Zaid Al-Khishman commented Nov 14 '14, 3:41 p.m.

Nevermind, I read the API documentation.

It determines how much of the item object is constructed, passing null constructs the full item.

1
sam detweiler commented Nov 14 '14, 3:46 p.m.

yes, IRepositoryItemService.COMPLETE is the null specifier


1
sam detweiler commented Nov 14 '14, 3:59 p.m.

handles are small.. objects consume more memory.  loading lots of fields takes longer than a few.  loading it all once, is probably ok,  loading all of all workitems could cause  performance issues or crash your app.

on the server side, remember you are running alongside all the other plugins and system components, sharing the same memory..

Zaid Al-Khishman commented Nov 14 '14, 4:18 p.m.

Handles themselves don't seem to be small at all (at least not the sizes that I'm used to, perhaps maybe they are relatively), or at least that's the impression that I got from debugging the plugin. I figured there would only be a hash of some sort(which was there) or a reference but there was a lot of other information (I may have been looking at what the references were referring to) which I wasn't able to make sense of, But I guess at the end of the day all of that is internal implementation details that the API hides.

Thanks for the note though, memory usage optimization is definitely something that needs to be paid attention to later in a shared run-time environment, at the moment the primary goal is to achieve correct functionality.

1
sam detweiler commented Nov 14 '14, 4:28 p.m.

small is indeed a relative term.

loading the comments for all workitems could get you megabytes of data.
i you didn't NEED that as part of your processing, then you could cause issues.

just food for thought..  (as you are just learning about the rtc data storage model)

showing 5 of 8 show 3 more comments

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.