Phillip Green schrieb: > Andreas, > > Ahhh, that makes sense. Thanks for taking the time with my problem.
BTW, I guess the problem is that the live sitetree isn't locked. Actually you might try to include it in getObjectsToLock(); you should receive an error (object has been modified ...). If this is really the case, I see two approaches: a) Factor out the CACI publishing in a separate (non-usecase) class and call this from the CACI publishing usecase and from the CAP publishing usecase (without the UsecaseInvoker). This way, you have a single transaction for the cascaded publishing operation. b) Invoke the CACI publishing usecase before changing the live sitetree in the CAP publishing usecase. This way, the CACI changes are already committed when you start the CAP changes. We should lock the live sitetree anyway when publishing, otherwise we run into the danger of read/write conflicts for concurrent publishing actions. -- Andreas > > Thanks, > Phillip > >>>> Andreas Hartmann <[EMAIL PROTECTED]> 6/14/2007 5:25 PM >>> > Hi Phillip, > > Phillip Green schrieb: >> I created my own resource types for my publication; CAP and CACI. The >> CAP resource type is composed of CACI resource types. I created a >> publish usecase for CAP that works and a publish usecase for CACI >> which works. However whenever I change the publish usecase for CAP >> to invoke the publish usecase for CACI, I am having problems. No >> error messages are being generated anywhere that I can find. >> However, the sitetree.xml file isn't being updated for the live area. >> I can see my document in the live area when I check the content >> directory, so the document is being copied. And the workflow is >> being updated. It's just the sitetree.xml that doesn't change. Does >> anyone know any difference from me calling the usecase from the lenya >> menu and using the following code: >> >> invoker = (UsecaseInvoker) this.manager.lookup(UsecaseInvoker.ROLE); >> Map params = new HashMap(); >> invoker.invoke(caciDocument.getCanonicalWebappURL(), >> PUBLISH_CACI_USECASE, params); > > actually this looks good. > > Just a wild guess, but it sounds like a bug in the transaction system. > The sitetree is affected by both the CAP and the CACI usecase. > IIUC the CACI usecase session is committed first, then the CAP usecase > session: > > <cap start> > ... > <caci start> > ... > <caci commit> > <cap commit> > > Maybe the CAP usecase overrides the sitetree changes previously made > by the CACI usecase because of some invalid change check. If I find > the time tomorrow I'll write a test case. > > Would you mind filing a bug and, if possible, attaching a patch which > allows to reproduce the problem? Stepping through the usecase with a > debugger might also help to find the cause. > > Thanks for reporting! > > -- Andreas > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
