I have used InternalProfileFormHandler
to add an item InternalProfileRepository
. It has successfully added the item(user:iuser310002) to the intended repository. Once added, I have accessed dyn/admin to open the repository and removed item I have just added by using <remove-item item-descriptor="user" id="iuser310002" />
. Then I have used invoked InternalProfileFormHandler again to add one more item. However this time, I have got an atg.repository.RemovedItemException
saying that Attempt to use an item which has been removed: user:iuser310002.
I'm not sure why it is trying to create a new user with same id as before and even if I did, why an item which is removed should cause this issue. I'm using default idGenerator /atg/dynamo/service/IdGenerator
for InternalProfileRepository so I don't think I would be generating same id.
Here is the code that succesfully created item once and failing from second time...
FormHandlerInvoker invoker = new FormHandlerInvoker("/atg/userprofiling/InternalProfileFormHandler", Nucleus.getSystemNucleus());
try {
String paramName;
int paramCounter = 1;
while((paramName = (String) getCurrentTestParams().get("param" + paramCounter)) != null)
{
invoker.addInput(paramName, (String) getCurrentTestParams().get("value" + paramCounter));
paramCounter++;
}
} catch (ServletException e) {
e.printStackTrace();
}
FormHandlerInvocationResult result;
ProfileFormHandler formHandler = null;
try {
result = invoker.invoke();
formHandler =
(ProfileFormHandler)result.getDefaultFormHandler();
formHandler.handleCreate(result.getRequest(), result.getResponse());
}
Following is the exception log... which is caused by formHandler.handleCreate method invocation.
atg.repository.RemovedItemException: Attempt to use an item which has been removed: user:iuser310002
at atg.adapter.gsa.ItemTransactionState.<init>(ItemTransactionState.java:385)
at atg.adapter.gsa.GSAItem.getItemTransactionState(GSAItem.java:2421)
at atg.adapter.gsa.GSAItem.getItemTransactionState(GSAItem.java:2364)
at atg.adapter.gsa.GSAItem.getItemTransactionStateUnchecked(GSAItem.java:2600)
at atg.adapter.gsa.GSAItem.getPropertyValue(GSAItem.java:1511)
at atg.repository.RepositoryItemImpl.getPropertyValue(RepositoryItemImpl.java:151)
at atg.adapter.composite.CompositeItem.createPropertyQuery(CompositeItem.java:739)
at atg.adapter.composite.CompositeItem.getPropertyLinkedItem(CompositeItem.java:630)
at atg.adapter.composite.CompositeItem.getContributingItem(CompositeItem.java:577)
at atg.adapter.composite.CompositeItem.findContributingItem(CompositeItem.java:561)
at atg.adapter.composite.MutableCompositeItem.findContributingItem(MutableCompositeItem.java:971)
at atg.adapter.composite.MutableCompositeItem.getOrCreateContributingItem(MutableCompositeItem.java:985)
at atg.adapter.composite.MutableCompositeItem.setPropertyValue(MutableCompositeItem.java:210)
at atg.userprofiling.ProfileForm.updateProfileAttributes(ProfileForm.java:3761)
at atg.userprofiling.ProfileForm.updateProfileAttributes(ProfileForm.java:3528)
at atg.userprofiling.ProfileForm.createUser(ProfileForm.java:1507)
at atg.userprofiling.ProfileForm.handleCreate(ProfileForm.java:1214)
at atg.userprofiling.ProfileFormHandler.handleCreate(ProfileFormHandler.java:402)
at atg.scenario.userprofiling.ScenarioProfileFormHandler.handleCreate(ScenarioProfileFormHandler.java:599)
at atg.test.steps.CreateInternalUserStep.runTest(CreateInternalUserStep.java:45)
After some digging around, I figured out the reason. Along with creating user, a session is also being created for the same user automatically. The user could be found by going to this path in dyn/admin.
/atg/dynamo/servlet/sessiontracking/GenericSessionManager/notdefined/atg/userprofiling/Profile/
Next time when I'm deleting the item in InternalProfileRepository, the item is being deleted successfully but the session object still exists.
When I call the formhandler.handleCreate again, it is checking if the profile object exists. When it found the user, it is trying to update the same user instead of creating a new one. Hence I'm getting the RemovedItemException.
However, I'm not quite sure if that is what is expected.