I ran into some hassle this morning attempting to apply a hotfix configuration change through the Portlet Manager UI to a portlet publication that had just been updated by an entities import job.
Use case was that for silly reasons the entity data in source control was wrong in a known way and I needed to tweak a group-subscribe-permission-on-portlet-grant after the import job ran to import a portlet definition that granted SUBSCRIBE to the wrong group. Since the current import process runs directly against the database (as mediated by a local uPortal ApplicationContext, a local JPA entity manager, etc.), rather than through the live portal application context / JPA entity manager, etc., apparently it can put the portal into a state where the objects in the running portal will fail Hibernate optimistic locking checks when you try to save changes to them. This is annoying, and probably could be lessened through more careful error handling, and anyway it apparently goes away after sufficient cache timeouts or something. No doubt tactical gains could be made in looking into that more deeply and tweaking. But this also yields some strategic thoughts: it seems to me that import would be better off actuating web services against the "real" uPortal application context / entity manager / etc., rather than spinning up a separate local ApplicationContext for this purpose -- and that moving to such a model might help make viable simplifying the uPortal build tooling, since the task of import tooling would become a tighter matter of invoking the right web services with the right data and credentials rather than spinning up local services, connections to the database, etc. That thought backlogged as https://issues.jasig.org/browse/UP-4336 Andrew -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
