NPE using IProcessAreaWorkingCopy
Version 6.0.3 (also had same problem with Version 5.0.2)
Hi I am using the plain client java api to automate adding users to a team area. However I am getting an intermittent NPE which seems to be related to instantiating the working copy. I get the NPE most times but sometimes not, seems related to the amount of times I instatiate the IProcessAreaWorkingCopy class. Stack trace below
IWorkingCopyManager copyManager = processItem.getWorkingCopyManager();
IProcessAreaWorkingCopy workingCopy
...
//loop through each team area{
...
workingCopy = (IProcessAreaWorkingCopy)copyManager.getWorkingCopy(teamArea);
//add or remove members
...
workingCopy.save(null);
copyManager.disconnect(teamArea);
//adding next line doesn't seem to make a difference
workingCopy.dispose();
}
Error:
java.lang.NullPointerException
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy.handleProcessAreaChanged(ProcessAreaWorkingCopy.java:978)
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy.access$1(ProcessAreaWorkingCopy.java:968)
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy$SharedItemChangeListener.itemsChanged(ProcessAreaWorkingCopy.java:139)
at com.ibm.team.repository.client.internal.ItemManager.dispatchEvents(ItemManager.java:1395)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$2.run(EventSource.java:739)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:732)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Mar 07, 2017 12:50:52 PM com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$2 handleException
SEVERE: Exception occured in process
java.lang.NullPointerException
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy.handleProcessAreaChanged(ProcessAreaWorkingCopy.java:978)
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy.access$1(ProcessAreaWorkingCopy.java:968)
at com.ibm.team.process.internal.client.workingcopies.ProcessAreaWorkingCopy$SharedItemChangeListener.itemsChanged(ProcessAreaWorkingCopy.java:139)
at com.ibm.team.repository.client.internal.ItemManager.dispatchEvents(ItemManager.java:1395)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$2.run(EventSource.java:739)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:732)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$3.run(EventSource.java:771)
at com.ibm.team.repository.client.util.ThreadCheck.runProhibitingLongOps(ThreadCheck.java:174)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher.process(EventSource.java:756)
at com.ibm.team.repository.client.util.EventSource$BackgroundEventDispatcher$4.run(EventSource.java:790)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Accepted answer
In Snippet3 of the plain Java client Libraries there is no disconnect or dispose:
I use this code and it does not disconnect eitherIRole role = getRole(area); teamArea = (ITeamArea) items[1]; IProcessAreaWorkingCopy areaWc = (IProcessAreaWorkingCopy)service.getWorkingCopyManager().createPrivateWorkingCopy(teamArea); areaWc.getTeam().addContributorsSettingRoleCast( new IContributor[] {repo.loggedInContributor()}, new IRole[] {role}); areaWc.save(monitor); monitor.subTask("Created project and team called " + area.getName()); return teamArea;
/*
* Adds a user as a member with a specific role to a process area
*
* @param user
* @param role
* @param processArea
* @param itemService
* @param monitor
* @throws TeamRepositoryException
/
public static void addMemberToProcessArea(IContributor user, IRole role,
IProcessArea processArea, IProcessItemService itemService,
IProgressMonitor monitor) throws TeamRepositoryException {
IProcessAreaWorkingCopy areaWc = (IProcessAreaWorkingCopy) itemService
.getWorkingCopyManager().createPrivateWorkingCopy(
processArea);
areaWc.getTeam().addContributorsSettingRoleCast(
new IContributor[] { user }, new IRole[] { role });
areaWc.save(monitor);
}
Comments
thanks but I also tried using .createPrivateWorkingCopy(teamArea) instead of .getWorkingCopy(teamArea)
I only see the null pointer exception when I have to update multiple teams so in my loop I set areaWc each time.....
sorry I misunderstood! I had tried using .createPrivateWorkingCopy(teamArea) but had left in the copyManager.connect(teamArea)
This seems to be working fine now, thanks for your help!
I have not used it for multiple project areas/team areas, sorry. There might be more effective API that can do more in parallel, but I have not looked that deep. This was sufficient for my needs.
Comments
Sian O'Briain
Mar 07 '17, 8:09 a.m.Previously I was using the ProcessAreaWorkingCopy class before I found this IProcessAreaWorkingCopy class. Previously I saw this error when deleting members but now it only seems to come up when adding roles. I have tried to use both methods
workingCopy.getTeam().addContributorsSettingRoleCast(userObjectArray,new IRole[]{teamMemberRole});
and also adding contributors and then setting role:
workingCopy.getTeam().setRoleCast(contrib, teamMemberRoleArray);
Sian O'Briain
Mar 07 '17, 8:32 a.m.actually no, a red herring, seeing again for deletes: