Hrm, good catch, I'm on vacation for a few days but I'll see if I can collect my thoughts on this and get a good reply posted tomorrow.

On 2/9/12 12:43 AM, Drew Wills wrote:
Hey folks,

How much do we care about the fact that the uP default XML data is divided into 3 directories?

  - required_entities
  - default_entities
  - quickstart_entities

I ask because it's come to my attention that there are currently some features that aren't working correctly *in part* because the entities aren't going in all at once -- or perhaps because of the way in which they're divided.

Here's how it goes...

> uP begins importing required_entities
> it imports the entity types, stylesheets, users, portlet types, and profiles found therein
> then it imports the defaultTemplateUser & system layouts, BUT
> in doing that it hits DLM code, which causes the DLM subsystem to bootstrap > in bootstrapping DLM reads dlm.xml and tries to evaluate the objects refers to > dlm.xml refers to objects in default_entities (specifically groups), which haven't been imported yet > The DLM subsystem can't do it's job later because it's state doesn't reflect (intended) reality

I see a few ways to deal with this issue:

- (1) re-combine the three entity folders to eliminate this whole class of problems - (2) cherry pick items from default & quickstart entities (and put them in required) to solve the problems we actually observe - (3) Switch to the JPA/Hibernate ConfigurationLoader implementation (originally sponsored by Pearson), which doesn't bootstrap based on dlm.xml at all (it recognizes changes to fragment defs in real time); also (possibly) deprecate the LegacyConfigurationLoader at the same time

I think I like #3, which also has the advantage of allowing you to add/remove fragments -- or change their audiences -- while the portal is up.

Please share thoughts.

cheers,

drew wills



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to