I was wondering if any of the Merlin-experts out there could offer an opinion, or some guidance, regarding the implementation scenario outlined below.
* Merlin is running "embedded" (how embedding is achieved changes often to follow the latest best practices harnessed from the CVS code ;-)
* One of the main services, exposed practically to all loaded components, is a persistence service, based on Hibernate. Initialization of the persistence service requires that the persistence layer is "aware" of all persistable classes to be served by the unique instance of the corresponding session factory.
* The application is capable of loading plug-ins. This is currently being handled by a dedicated component, which knows how to find the plug-in files, load them, etc. and is, in Avalon terms, nothing more than a component, much like any other.
* Now to the challenging part: There exists a requirement that plug-ins access the persistence service. This means, in Hibernate terms, that the persistence configuration files for (each of these) plug-ins must be made available to Hibernate, before it can "configure" itself. In other words, the configuration files (known to the "Plug-in Manager" component mentioned above) should be handed over to the persistence service's initialization code, thus resulting in the instantiation of session factories that "know" how to handle persistent classes in the plug-ins.
The obvious (?) solution of having a one-way dependency from the persistence service to the plug-in manager service would not work, because the plug-in manager itself needs to use the persistence service to save information about the current state of plug-ins.
I have looked at lifecycle extensions, but have come up empty-handed, with my main stumbling blocks being: how can I ensure any kind of order between the "execution" of extension handlers? how can handlers "pass back" information that gets generated in the process of "handling" a component. (Note: The way in which I envisaged using the extensions, is to create one that must then be used for all components that need to "collect" persistence configuration information; the collected information would then somehow be fed into the initialization of Hibernate)
The set-up I am describing is not "cast in stone" - if I cannot achieve what I want this way, I would readily switch to an alternative, more promising approach. I could also add more details to the above descriptions if necessary.
I would be grateful for any feedback,
Alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
