Hey David,
I'm going to make an assumption that you are using 6.2. I've had similar issues before and it all traced back (for me) to the service context ultimately not being what I expected it to be. When you use the factory to create a service context, you get a lot of the fields on the object. For example, the company id and the scope group id are set for you because Liferay knows how to find them based on things like the url (attaching the host to a company id, and the group friendly url to the scope group id). When the scheduled job runs, there is no such context because it doesn't come from an inbound request object that contains that kind of information. The null pointer, according to your stack trace originates with this method --
protected long getDefaultFileEntryTypeId(
ServiceContext serviceContext, long folderId)
throws PortalException, SystemException {
folderId = dlFolderLocalService.getFolderId(
serviceContext.getCompanyId(), folderId);
return dlFileEntryTypeLocalService.getDefaultFileEntryTypeId(folderId);
}
The thread locals are awesome, but they are set based on one of the filters in the request chain being executed -- so I don't think that it is complete when you use it in a scheduled job. I faced something along these lines recently with a startup action that I wrote where all you have is the companyId. In the end I wrote a utility class that, based on some configs I added to the portal-ext uses Liferay's API to look up the data points I need to have in the service context and then I created a utility to generate the service context for me.
I'm not sure if you have the same issue or not, but I would set a breakpoint in my listener and check to see if the ServiceContextThreadLocal is actually returning an object, or if you are getting a null.
