topic Re: Are there any known issues using P1W as a time duration? in Alfresco Forum

Are there any known issues using P1W as a time duration?

kch0313 — Fri, 24 Feb 2017 16:38:24 GMT

We have been using time duration with ISO 8601 durations, but have recently tried testing more variations. Today we received this error, that by the stack trace seems to indicate a problem with resolving the duration, and possibly related to the default business calendar. Is there some configurati

Re: Are there any known issues using P1W as a time duration?

jearles — Fri, 24 Feb 2017 23:05:19 GMT

Not that I am aware of, but I'll check and follow up with you.

If you could provide any other related information, that would be awesome. Particularly a snippet of the code that triggers this stack trace.

-JEarles

Re: Are there any known issues using P1W as a time duration?

kch0313 — Sun, 26 Feb 2017 23:30:09 GMT

I added attachments to my original post, one with the BPMN model you can import and execute. Basically, it sets a process variable, and the wait intermediate timer activity uses the variable in a JUEL expression in the duration. Doing this with other ISO 8601 durations worked, but P1W didn't. I used Activiti Explorer to import this model, deploy, and start an instance to generate the error. The other attachment added to my original post is the log snippet from Tomcat showing the error reported in Activiti Explorer with errors similar to my original stack trace (with a fragment below).

Caused by: org.activiti.engine.ActivitiException: couldn't resolve duedate: P1W
at org.activiti.engine.impl.calendar.DurationBusinessCalendar.resolveDuedate(DurationBusinessCalendar.java:37)
at org.activiti.engine.impl.calendar.BusinessCalendarImpl.resolveDuedate(BusinessCalendarImpl.java:22)
at org.activiti.engine.impl.jobexecutor.TimerDeclarationImpl.prepareTimerEntity(TimerDeclarationImpl.java:165)
at org.activiti.engine.impl.persistence.entity.ExecutionEntity.initialize(ExecutionEntity.java:351)
at org.activiti.engine.impl.pvm.runtime.AtomicOperationTransitionCreateScope.execute(AtomicOperationTransitionCreateScope.java:43)
at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:96)

... ommitted for brevity

Caused by: java.lang.IllegalArgumentException: P1W
at com.sun.org.apache.xerces.internal.jaxp.datatype.DurationImpl.organizeParts(DurationImpl.java:612)
at com.sun.org.apache.xerces.internal.jaxp.datatype.DurationImpl.<init>(DurationImpl.java:524)
at com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl.newDuration(DatatypeFactoryImpl.java:104)
at org.activiti.engine.impl.calendar.DurationHelper.parsePeriod(DurationHelper.java:169)
at org.activiti.engine.impl.calendar.DurationHelper.<init>(DurationHelper.java:89)
at org.activiti.engine.impl.calendar.DurationHelper.<init>(DurationHelper.java:107)
at org.activiti.engine.impl.calendar.DurationBusinessCalendar.resolveDuedate(DurationBusinessCalendar.java:34)
... 138 more

Re: Are there any known issues using P1W as a time duration?

gdharley — Mon, 27 Feb 2017 00:53:23 GMT

Based on the code I see in the DurationHelper class below:

private Calendar add(Calendar date, Duration duration) {
Calendar calendar = (Calendar) date.clone();
// duration.addTo does not account for daylight saving time (xerces),
// reversing order of addition fixes the problem
calendar.add(Calendar.SECOND, duration.getSeconds() * duration.getSign());
calendar.add(Calendar.MINUTE, duration.getMinutes() * duration.getSign());
calendar.add(Calendar.HOUR, duration.getHours() * duration.getSign());
calendar.add(Calendar.DAY_OF_MONTH, duration.getDays() * duration.getSign());
calendar.add(Calendar.MONTH, duration.getMonths() * duration.getSign());
calendar.add(Calendar.YEAR, duration.getYears() * duration.getSign());
return calendar;
}

It doesn't appear as though "W" or week is supported.

I have not run a debugger against this to verify, but this would explain your symptoms.

Greg

‌

Re: Are there any known issues using P1W as a time duration?

jearles — Mon, 27 Feb 2017 18:08:59 GMT

For a little bit more context on this:

The code that creates the DueDate based on what is entered in the model editor uses the DatatypeFactory API, calling the method: newDuration(String lexicalRepresentation) - which creates the calendar object based on the string format "PnYnMnDTnHnMnS", which does not include weeks (as defined in the XML Schema 1.0 Section 3.2.6.1).

So the behavior you're seeing is expected and caused by the libraries being used.

-JEarles

Re: Are there any known issues using P1W as a time duration?

kch0313 — Tue, 28 Feb 2017 04:11:26 GMT

the obvious work-around for this is to use 7 days (P7D), which for most is an equivalent operation.

thanks both for your immediate attention and helpful information.