Timothy Bennett wrote:
As I'm trying to get my head around merlin, it seems to me that a merlin
"container" definition is similar in concept and function to which known as
an application (deployed in the form of a SAR) in phoenix. Is this a fair
comparison?
Yes and no.
A phoenix "application" is a physical unit of deployment that aggregates dependent jar files, classes, component descriptors, resources, configuration, assembly and environment information.
A Merlin container is logically similar in that it aggregates *references" to jar files, component descriptorts, configuration,assembly and environment information.
The big difference is that I can take the block.xml description that Timothy Bennett recently posted to this list and execute it. Merlin takes care of the resolution of structural dependencies declared in the container classloader.
E.g.:
$ merlin hsql.xml [INFO ] (hsql.hsql-server): HypersonicSQL.compose() Hypersonic SQL listening on port 9001
Keep in mind that I didn't have all of the resources for this on my machine when I invoked the command. Merlin has taken care of that for me based on the repository directives I have in the kernel.xml file.
They both have classloaders and component definitions with configurations and assemblies.
With regard to merlin containers, is it possible to have multiple container
definitions within the same XML descriptor file?
Yes.
A <container> can contain multiple <component>, <container> and <include> directives. A <component> established a component and its services, a <container> establishes a container and simulates a component, and an <include> includes an externally defined container.
If so, under what design
circumstances would it be to deploy some components in one container, and
other components in a different container.
Two factors:
1. composition 2. isolation
For example Alexis was recently doing some work on OpenIM concerning user stores. Based on minimal effort we were able to construct a user repository facility using components declared in the james deployment descriptor. A solution was up and running in about 20 mins (and that's taking an example of component composition from a source that was not intended to be used in this manner). When you have components with good API/impl seperation, prepackaged descriptors, etc. The time taken to plug together solutions falls down to a matter of 1-2 minutes (assuming good deployment documetation is available).
The second factor, isolation - allows you to protect/isolate classes into a containment context. For example - in my top-level container I can include API jar files, and in a subcontainer I can include implementation jar files. This isolates the availability of the implementation classes to those classes colocated in the same containment context. Back at the top-level the services provided by the nested container are accessible to the top-level components.
I can assume that each container
would have its own classloader,
Correct.
which has benefits, but are there other
benefits?
More in the future - part of the roadmap deals with security and this address the policies that you declare. It makes a lot of sence to include security policy at the container level, enabling for example the control over resource authentication, addition of access controls, etc.
Can components deployed in one container access the services of
components deployed in a different container via service manager lookup?
Yes - providing the consumer component has declared a dependency, and, providing that the container contining the component capable of fulfilling the service exports this service though a container level <service> declaration. I.e. containers simulate components so a container looks like another component as far as assembly semantics are concerned. Internally a container represents an implementation strategy relative to the services it provides.
If so, is there anything special that needs to be done programmatically, or does the kernel take care of managing this for you auto-magically?
Auto-magical is the default policy but you can override this if you want. As mentioned above, the two things you need to take care of are:
1. declaration of the dependency by your component 2. exporting of a service by a component (and exporting of the service by the container if the component is nested in another branch of the containment hierachy)
Steve.
-- Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
