You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2002/08/06 18:52:48 UTC
Merger of Merlin/Fortress - first steps ?
Hi All,
Hope all is well.
We've been talking a lot recently about the potential merger of
Fortress and Merlin into one effort to come up with a rock-solid
replacement for ECM.
Everyone seems to think this would be a worthwhile goal, so lets
start to look at the issues involed.
What would be great, is if we could all brainstorm a little and
put together a list of the potential issues we (may?) have with
merging the 2 efforts, so we can then discuss them and work out
the solutions that will give us a path forwards.
Here's what I see to be on the list so far, it's probably far from
complete, but something we can start to work from.
(BTW - I'm still a Merlin novice, so for the Merlin guru's if I
make a mistake or mistype something feel free to correct me)
o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
Merlin's use of configuration files differs from the ECM/Fortress
model. Each component has an associated .xinfo file specifying
meta information, and a .xconfig file specifying default
configuration values. A .xprofile file specifies instances of the
specified component which are available for use (all of this can
also be specified in Merlin's higher level kernel.xml file too).
All of this is packaged up in a jar, which Merlin can search
through automatically at startup for example to locate and expose
services.
ECM/Fortress uses the RoleManager approach, which allows you to
specify a shorthand name for a role (as opposed to a particular
roles complete class name). This shorthand can then be used in the
.xconf configuration file which specifies config data for all
components that ECM/Fortress instance is managing.
What to do ?
I think Merlin's approach is really nice. The meta info specified
in the .xinfo files allows features like service dependencies,
versioning, etc, to be implemented which role manager can't yet do
without changes.
It also implicitly fixes other issues previously brought up on the
list like the separation of configuration files, default settings, etc.
The combination of Merlin's .x* files also lets us have the
ability to take jar's and expose services for clients automatically
(and perhaps in the future load/reload them dynamically).
I would advocate the adoption of Merlin's model, with the
development of a transition tool that could generate the required bits
for the .roles world, either dynamically or statically at build
time - or the development of an ECM style compatibility layer for
Merlin that would allow the use of the .roles/.xconf files. Thoughts ?
o ComponentSelector
ECM/Fortress return ComponentSelectors for lookups that end in
role name + selector. From my current understanding Merlin doesn't
do this (?). I remember Stephen proposed a solution for this in a
previous email which is quoted verbatim below:
>>This is the area I see as the "main topic" on merging - and
>>its also the source of handreds of emails. Merlin is good a "systems
>>assembly" - and it does this using those <sclasname>..xinfo files.
>>>From this information it builds up a graph that associates the
>>type/profile combinations between supply and consumption compoenents.
>>Before the start method is invoked, everyting in Merlin is ready -
>>you can request any service (started or not) and you will get back a
>>properly prepared service. However, you will never get back a
>>selector (selection is done at assembly time). In the Fortress case
>>this is hadled at runtime (i.e a combination of late service binding
>>and referral of selection to the client). How to merge these two
>>approaches? My opinion is that they are seperate concerns - imagine
>>the existence of a ServiceManager along side a ServiceLocator -
>>ServiceManager providing the assembly time services to the component
>>and ServiceLocator supplying the resolution of dynamic lookups.
o Fortress style ComponentHandlers
Fortress allows the developer to specify the usage of a particular
component, ie. whether it should be pooled, reused in all threads,
or created and destroyed per lookup/release.
Merlin currently assumes thread safe singleton components only.
Stephen told me offline that this one is on his current TODO list
- any further info there Stephen ? will it be similar to the
Fortress approach ? ie. can the developer specify how a particular
component can be handled ?
o Lifecycle Extensions
Implementation of the features discussed in Berin's email:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102830949902694&w=2
o Merlin logging management
Stephen mentioned to me that Merlin's logging management is
different than both Phoenix and ECM/Fortress. He mentioned to me
the possibility of supporting the ECM style configuration, I guess
we need to cover this one in a bit more detail.
And... there are probably others..
Also to discuss is the process of *how* we should merge the efforts
together. Ideas ?
Ok, well hopefully thats a start. Feel free to add any thoughts/issues
or comments to the above list, and we can work out solutions for them
all. Hopefully that will give us a path forward, combined our
'how' plan, to create our kick ass ECM successor. :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Stephen McConnell <mc...@apache.org>.
Marcus Crafter wrote:
>Hi Stephen,
>
>On Wed, Aug 07, 2002 at 05:41:53PM +0200, Stephen McConnell wrote:
>
>>> (BTW - I'm still a Merlin novice, so for the Merlin guru's if I
>>> make a mistake or mistype something feel free to correct me)
>>>
>>>
>>No mistakes - its a good description.
>>
>
> *relief*.. thanks, your documentation on home.osm.net helped quite
> a bit :)
>
>
>>> o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
>>>
>>>
>
><snip/>...
>
>
>>> The combination of Merlin's .x* files also lets us have the
>>> ability to take jar's and expose services for clients automatically
>>> (and perhaps in the future load/reload them dynamically).
>>>
>>Dynamic loading is already possible through dynamic addition of
>>containers. Container defintions can be created programatically (i.e.
>>the container meta-data) and used to add a subcontainer to an existing
>>container. The container defintion includes a classpath structure which
>>which is automatically applied to the container's classloader.
>>
>
> Thanks for the update.
>
> Is it also possible to specify directories of services, and be able
> to drop jar's into the directories and have them loaded during
> runtime ? I remember talking with Jason from Turbine about such a
> feature. It would also be useful for the Cocoon Block concept.
>
Let's say you write a container specilization that tracks changes to a
classpath. That container could dynamically check meta attributes for
something like a load-assembly-deploy-on-drop policy. Basically all it
would need to do is to create a sub-container using the classpath
container the updated jar file names, add the service programatically,
and its done.
>>> o ComponentSelector
>>>
>>> ECM/Fortress return ComponentSelectors for lookups that end in
>>> role name + selector. From my current understanding Merlin doesn't
>>> do this (?).
>>>
>>>
>>Correct.
>>
>
> In the Merlin documentation at home.osm.net under Assembly, it
> mentions that if multiple component profiles exist a 'service
> selector' will be instantiated - is this the same as a
> ComponentSelector in the ECM world ? or is it something different ?
>
Its about 180 degrees different. ECM supplies a selector back to a
client whereas in Merlin, the client supplies a selector (or if they
don't, a default selector is auomatically established) and Merlin
returns the result of the selection. Also, the object we are selecting
in Merlin is a Profile (instantiation criteria).
>>> o Fortress style ComponentHandlers
>>>
>
><snip/>...
>
>>What I have in mind is that the Merlin internal system provide a default
>>singleton manager, but components will be able to declare a lifestyle
>>handler and Merlin will assign a different handler based on the
>>
>
> via .xinfo ?
>
Yes.
>>lifestyle policy declaration. In priincipal this should allow the
>>plugging in of a totally ECM style handler (at least that is the
>>objective). It should possible just to add jar files containing
>>specialized lifestyle handlers to a kernel or container classpath (or
>>add it to the extensions directory) and Merlin should take of this
>>automagically.
>>
>
> sounds good.
>
>
>>> Also to discuss is the process of *how* we should merge the efforts
>>> together. Ideas ?
>>>
>>>
>>An interesting first step would be to assess the possibility for
>>implementation of the Fortress container as a specialization of the
>>Merlin's DefaultContainer (or possible a more abstract base class).
>>
>
> Yes. I've though about this too. Couldn't Fortress essentially
> become Merlin's DefaultContainer implementation ? Part of
> Fortress' code does what Merlin's Kernel code does, so not all of
> it would need to be merged. But maybe that's the way forward ?
>
It will be possible to declare the root container class when creating a
kernel and its easy to imagine a Fortress container implementation.
>>> Ok, well hopefully thats a start. Feel free to add any
>>> thoughts/issues
>>> or comments to the above list, and we can work out solutions for them
>>> all. Hopefully that will give us a path forward, combined our
>>> 'how' plan, to create our kick ass ECM successor. :)
>>>
>>>
>>Nothing dramatic to add - there are some other feature rerquests -
>>things like container suspension, reconfiguration and restarting, JMX
>>entry points, support for SAR loading (via a container specialization),
>>etc.
>>
>
> All sounds good. Do you mean dynamic reconfiguration ? what event
> would fire this ? (update of jar's, manual trigger, etc ?)
>
I was mainly thinking about Leo's scanrios - JXM management - use
updating a configuration - nice GUI that dynamically shows assembly and
deployment status, lets you disable, enable containers, re-start
containers, reassemble containers, etc.
Cheers, Steve.
>
>
> Cheers,
>
> Marcus
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Stephen,
On Wed, Aug 07, 2002 at 05:41:53PM +0200, Stephen McConnell wrote:
>
> > (BTW - I'm still a Merlin novice, so for the Merlin guru's if I
> > make a mistake or mistype something feel free to correct me)
> >
>
> No mistakes - its a good description.
*relief*.. thanks, your documentation on home.osm.net helped quite
a bit :)
> > o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
> >
<snip/>...
> > The combination of Merlin's .x* files also lets us have the
> > ability to take jar's and expose services for clients automatically
> > (and perhaps in the future load/reload them dynamically).
>
> Dynamic loading is already possible through dynamic addition of
> containers. Container defintions can be created programatically (i.e.
> the container meta-data) and used to add a subcontainer to an existing
> container. The container defintion includes a classpath structure which
> which is automatically applied to the container's classloader.
Thanks for the update.
Is it also possible to specify directories of services, and be able
to drop jar's into the directories and have them loaded during
runtime ? I remember talking with Jason from Turbine about such a
feature. It would also be useful for the Cocoon Block concept.
> > o ComponentSelector
> >
> > ECM/Fortress return ComponentSelectors for lookups that end in
> > role name + selector. From my current understanding Merlin doesn't
> > do this (?).
> >
>
> Correct.
In the Merlin documentation at home.osm.net under Assembly, it
mentions that if multiple component profiles exist a 'service
selector' will be instantiated - is this the same as a
ComponentSelector in the ECM world ? or is it something different ?
> > o Fortress style ComponentHandlers
<snip/>...
> What I have in mind is that the Merlin internal system provide a default
> singleton manager, but components will be able to declare a lifestyle
> handler and Merlin will assign a different handler based on the
via .xinfo ?
> lifestyle policy declaration. In priincipal this should allow the
> plugging in of a totally ECM style handler (at least that is the
> objective). It should possible just to add jar files containing
> specialized lifestyle handlers to a kernel or container classpath (or
> add it to the extensions directory) and Merlin should take of this
> automagically.
sounds good.
> > Also to discuss is the process of *how* we should merge the efforts
> > together. Ideas ?
> >
>
> An interesting first step would be to assess the possibility for
> implementation of the Fortress container as a specialization of the
> Merlin's DefaultContainer (or possible a more abstract base class).
Yes. I've though about this too. Couldn't Fortress essentially
become Merlin's DefaultContainer implementation ? Part of
Fortress' code does what Merlin's Kernel code does, so not all of
it would need to be merged. But maybe that's the way forward ?
> > Ok, well hopefully thats a start. Feel free to add any
> > thoughts/issues
> > or comments to the above list, and we can work out solutions for them
> > all. Hopefully that will give us a path forward, combined our
> > 'how' plan, to create our kick ass ECM successor. :)
> >
>
> Nothing dramatic to add - there are some other feature rerquests -
> things like container suspension, reconfiguration and restarting, JMX
> entry points, support for SAR loading (via a container specialization),
> etc.
All sounds good. Do you mean dynamic reconfiguration ? what event
would fire this ? (update of jar's, manual trigger, etc ?)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Stephen McConnell <mc...@apache.org>.
Marcus Crafter wrote:
>Hi All,
>
> Hope all is well.
>
> We've been talking a lot recently about the potential merger of
> Fortress and Merlin into one effort to come up with a rock-solid
> replacement for ECM.
>
> Everyone seems to think this would be a worthwhile goal, so lets
> start to look at the issues involed.
>
> What would be great, is if we could all brainstorm a little and
> put together a list of the potential issues we (may?) have with
> merging the 2 efforts, so we can then discuss them and work out
> the solutions that will give us a path forwards.
>
> Here's what I see to be on the list so far, it's probably far from
> complete, but something we can start to work from.
>
> (BTW - I'm still a Merlin novice, so for the Merlin guru's if I
> make a mistake or mistype something feel free to correct me)
>
No mistakes - its a good description.
See notes inline.
>
>
> o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
>
> Merlin's use of configuration files differs from the ECM/Fortress
> model. Each component has an associated .xinfo file specifying
> meta information, and a .xconfig file specifying default
> configuration values. A .xprofile file specifies instances of the
> specified component which are available for use (all of this can
> also be specified in Merlin's higher level kernel.xml file too).
>
> All of this is packaged up in a jar, which Merlin can search
> through automatically at startup for example to locate and expose
> services.
>
> ECM/Fortress uses the RoleManager approach, which allows you to
> specify a shorthand name for a role (as opposed to a particular
> roles complete class name). This shorthand can then be used in the
> .xconf configuration file which specifies config data for all
> components that ECM/Fortress instance is managing.
>
> What to do ?
>
> I think Merlin's approach is really nice. The meta info specified
> in the .xinfo files allows features like service dependencies,
> versioning, etc, to be implemented which role manager can't yet do
> without changes.
>
> It also implicitly fixes other issues previously brought up on the
> list like the separation of configuration files, default settings, etc.
>
> The combination of Merlin's .x* files also lets us have the
> ability to take jar's and expose services for clients automatically
> (and perhaps in the future load/reload them dynamically).
>
>
Dynamic loading is already possible through dynamic addition of
containers. Container defintions can be created programatically (i.e.
the container meta-data) and used to add a subcontainer to an existing
container. The container defintion includes a classpath structure which
which is automatically applied to the container's classloader.
>
> I would advocate the adoption of Merlin's model, with the
> development of a transition tool that could generate the required bits
> for the .roles world, either dynamically or statically at build
> time - or the development of an ECM style compatibility layer for
> Merlin that would allow the use of the .roles/.xconf files. Thoughts ?
>
>
>
> o ComponentSelector
>
> ECM/Fortress return ComponentSelectors for lookups that end in
> role name + selector. From my current understanding Merlin doesn't
> do this (?).
>
Correct.
> I remember Stephen proposed a solution for this in a
> previous email which is quoted verbatim below:
>
>
>>>This is the area I see as the "main topic" on merging - and
>>>its also the source of handreds of emails. Merlin is good a "systems
>>>assembly" - and it does this using those <sclasname>..xinfo files.
>>>>From this information it builds up a graph that associates the
>>>type/profile combinations between supply and consumption compoenents.
>>>Before the start method is invoked, everyting in Merlin is ready -
>>>you can request any service (started or not) and you will get back a
>>>properly prepared service. However, you will never get back a
>>>selector (selection is done at assembly time). In the Fortress case
>>>this is hadled at runtime (i.e a combination of late service binding
>>>and referral of selection to the client). How to merge these two
>>>approaches? My opinion is that they are seperate concerns - imagine
>>>the existence of a ServiceManager along side a ServiceLocator -
>>>ServiceManager providing the assembly time services to the component
>>>and ServiceLocator supplying the resolution of dynamic lookups.
>>>
>
>
>
> o Fortress style ComponentHandlers
>
> Fortress allows the developer to specify the usage of a particular
> component, ie. whether it should be pooled, reused in all threads,
> or created and destroyed per lookup/release.
>
> Merlin currently assumes thread safe singleton components only.
>
> Stephen told me offline that this one is on his current TODO list
> - any further info there Stephen ? will it be similar to the
> Fortress approach ? ie. can the developer specify how a particular
> component can be handled ?
>
What I have in mind is that the Merlin internal system provide a default
singleton manager, but components will be able to declare a lifestyle
handler and Merlin will assign a different handler based on the
lifestyle policy declaration. In priincipal this should allow the
plugging in of a totally ECM style handler (at least that is the
objective). It should possible just to add jar files containing
specialized lifestyle handlers to a kernel or container classpath (or
add it to the extensions directory) and Merlin should take of this
automagically.
>
>
>
>
> o Lifecycle Extensions
>
> Implementation of the features discussed in Berin's email:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=102830949902694&w=2
>
I've been doing some more thinking about this and I have some issues
that I need to raise in a seperate email. I'm not convinced that the
current approaches (in Merlin and Fortress) are completely right - but
more on that later.
>
> o Merlin logging management
>
> Stephen mentioned to me that Merlin's logging management is
> different than both Phoenix and ECM/Fortress. He mentioned to me
> the possibility of supporting the ECM style configuration, I guess
> we need to cover this one in a bit more detail.
>
>
> And... there are probably others..
>
> Also to discuss is the process of *how* we should merge the efforts
> together. Ideas ?
>
An interesting first step would be to assess the possibility for
implementation of the Fortress container as a specialization of the
Merlin's DefaultContainer (or possible a more abstract base class).
That would mean that anything running in that container will be managed
by Fortress. A little more work needs to go into the Container API
before doing this - really a case of getting it as tight as possble
before lots of peiople start doing tbings with it - its just a tounch
too volitale just at the moment but very close.
>
>
> Ok, well hopefully thats a start. Feel free to add any thoughts/issues
> or comments to the above list, and we can work out solutions for them
> all. Hopefully that will give us a path forward, combined our
> 'how' plan, to create our kick ass ECM successor. :)
>
Nothing dramatic to add - there are some other feature rerquests -
things like container suspension, reconfiguration and restarting, JMX
entry points, support for SAR loading (via a container specialization),
etc.
Cheers, Steve.
>
>
> Cheers,
>
> Marcus
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merger of Merlin/Fortress - first steps ?
Posted by Berin Loritsch <bl...@apache.org>.
Thanks for your answers, I will look at them in detail.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Thursday, August 08, 2002 7:15 AM
> To: Avalon Developers List
> Subject: Re: Merger of Merlin/Fortress - first steps ?
>
>
>
>
> Berin Loritsch wrote:
>
> >Steps that we need to take (no order implied)
> >
> >* Merging of lifecycle extension mechanisms
> >* Fortress adopting the Meta-Info model from Merlin
> >* Creation of a tool to generate the Meta-Info files
> >* Determine how Fortress and Merlin relate
> >
> >Things I would like to see Fortress maintain:
> >
> >* Asynchronous component management
> >* Hiding the creation of the ***Managers from the end user
> >* Using Context values to pass in the necessary info
> >* Automatic determination of ServiceSelector or equiv. for
> return value
> >* Separation of lookup interface and container
> >
> >Things I wold like to see Fortress change:
> >
> >* Need for the .roles file
> >* hiding the ContextManager inside the ContainerManager
> >
> >
> >Things I would like to know from Merlin:
> >
> >* How Kernel and Containers relate
> >
>
> The Kernel manages a single container hierachy whereas a
> Container is a
> node in that hierachy. A kernel's primary objective is to
> expose a set
> of Resource (a reference to a component). The kernel
> interface does not
> imply anything about how thaese resoruces are established. The
> DefaultKernel implementation uses a container hierachy as its
> management
> approach.
>
> Here is a summary of the main kernel functions:
>
> * sets up the root directory for the system under the key
> "avalon:home"
> * creates a singleton logging manager
> * builds information for managing jar file extensions
> * builds information about the kernel classpath
> * creates a Type Manager and assignes it as the context classloader
> * creates the root container
> * handles requests for initialization, startup, shutdown
> which tigger
> the same actions on the root container
> * manages veirfication of the integrity of the component
> relationships
> across the hierachy
> * manages the exporting of the aggregate set of resources
> established
> by the container hierachy
>
> Here is a summary of the container functions
>
> * is supplied with a type manager and meta-info about itself
> * establishes a new thread of execution on initialization
> * coodinates sub-container initilisation, startup, shutdown, etc.
> * manages partial failure of a sub-container
> * state and content change events to its container
> * access to sub-containers
> * access to container components (via Resource holders)
> * dynamic addition of component profiles
> * dynamic addition of sub-containers
>
> >
> >* How to programatically add and remove containers from the kernel
> >
> >
> >
> The approach dependes on if you "inside container space" or
> "outside".
> If you define a specilized container and you declare this as part of
> the container declaration in the kernel.xml file, you can intercept
> things like initialization and so forth. You could for
> example control
> the population of the container (component profiles and
> sub-containers).
> Here is the code for creating a new sub-container.
>
> ReferenceDescriptor containerInterface =
> new ReferenceDescriptor(
> "org.apache.excalibur.merlin.container.Container" );
> ContainerDescriptor descriptor =
> (ContainerDescriptor) manager.getProfile( containerInterface );
> Container container =
> createSubContainer( "my-container", descriptor, new
> ClasspathDescriptor() );
>
> Component addition is simpler - you simply create or locate a
> component
> profile and install it into the container. The container will do the
> rest of the work (validation, assembly, etc).
>
>
> >>From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> >>
> >>
> >
> >
> >
> >>Hi All,
> >>
> >> We've been talking a lot recently about the potential merger of
> >> Fortress and Merlin into one effort to come up with a rock-solid
> >> replacement for ECM.
> >>
> >> Everyone seems to think this would be a worthwhile goal, so lets
> >> start to look at the issues involed.
> >>
> >> o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
> >>
> >>
> >
> >We have been wanting to do this for a while now.
> >
> >
> >
> >
> >> ECM/Fortress uses the RoleManager approach, which allows you to
> >> specify a shorthand name for a role (as opposed to a particular
> >> roles complete class name). This shorthand can then be
> >> used in the
> >> .xconf configuration file which specifies config data for all
> >> components that ECM/Fortress instance is managing.
> >>
> >>
> >
> >I like the shortened name, and I would want to do whatever I can to
> >keep the notion, even if it is implemented in a different manner.
> >
>
> My guess is the in the majority of cases the shorthand name will
> actually be replaced by a meta-info class and accessor method. For
> example, to get the logging catagories specific to a particular
> component - I call something like:
>
> CategoriesDescriptor categories = profile.getCategories();
>
>
> >> What to do ?
> >>
> >> I would advocate the adoption of Merlin's model, with the
> >> development of a transition tool that could generate
> >> the required bits
> >> for the .roles world, either dynamically or statically at build
> >> time - or the development of an ECM style compatibility
> >> layer for
> >> Merlin that would allow the use of the .roles/.xconf
> >> files. Thoughts ?
> >>
> >>
> >
> >
> >I would really like to see an ANT task or something that will create
> >the ***.xinfo files for us. Esp. for migrating from ECM
> land. It will
> >enable a quicker migration.
> >
> >I kind of like the idea of the XDoclet concept from Phoenix,
> although I
> >am not sure if I fully understand what gets declared where
> and why. It
> >is something that I would like to get finalized.
> >
> >The attributes in XDoclet form are easier to maintain than a
> separate
> >.xinfo file.
> >
> >
> >
> >
> >> o ComponentSelector
> >>
> >> ECM/Fortress return ComponentSelectors for lookups that end in
> >> role name + selector. From my current understanding
> >> Merlin doesn't
> >> do this (?). I remember Stephen proposed a solution for
> >> this in a
> >> previous email which is quoted verbatim below:
> >>
> >>
> >>
> >>>>This is the area I see as the "main topic" on merging - and
> >>>>its also the source of handreds of emails. Merlin is good a
> >>>>"systems assembly" - and it does this using those
> <classname>.xinfo
> >>>>files. From this information it builds up a graph that associates
> >>>>the type/profile combinations between supply and consumption
> >>>>compoenents. Before the start method is invoked,
> everyting in Merlin
> >>>>is ready - you can request any service (started or not)
> and you will
> >>>>get back a properly prepared service. However, you will
> never get
> >>>>back a selector (selection is done at assembly time). In the
> >>>>Fortress case this is hadled at runtime (i.e a
> combination of late
> >>>>service binding and referral of selection to the client). How to
> >>>>merge these two approaches? My opinion is that they are seperate
> >>>>concerns - imagine the existence of a ServiceManager along side a
> >>>>ServiceLocator - ServiceManager providing the assembly
> time services
> >>>>to the component and ServiceLocator supplying the resolution of
> >>>>dynamic lookups.
> >>>>
> >>>>
> >
> >
> >At least for the Fortress branded containers, I would like
> to see the
> >**Selector pattern for something that will help in the transition.
> >Fortress is a good migration tool because you can access
> your desired
> >components either through a Selector or directly. That way, as
> >components are written they can opt out of assuming the
> existence of a
> >selector at all. As we approach A5, the generic selector can be
> >removed from the picture.
> >
> >
> >
> >
> >> o Fortress style ComponentHandlers
> >>
> >> Fortress allows the developer to specify the usage of a
> >> particular
> >> component, ie. whether it should be pooled, reused in
> >> all threads,
> >> or created and destroyed per lookup/release.
> >>
> >> Merlin currently assumes thread safe singleton components only.
> >>
> >>
> >
> >If Merlin wants to reuse those ComponentHandlers, it is free
> to do so.
> >If the existence of those handlers is only within the
> Fortress brand of
> >containers, then we need Fortress to work within a Merlin system.
> >
> >
> >
> >
> >> Stephen told me offline that this one is on his current
> >> TODO list
> >> - any further info there Stephen ? will it be similar to the
> >> Fortress approach ? ie. can the developer specify how a
> >> particular
> >> component can be handled ?
> >>
> >>
> >
> >He has an idea of how to express the meta-info, but like his
> version of
> >the Lifecycle Extensions I doubt it follows the same interfaces.
> >
>
> Before going in this direction there is more optimization needed in
> Merlin in the lifestyle area. Currently the assumptions concerning
> singleton policies are restricted to two classes and I want
> to get this
> down to only one. With that done, I will have a good idea of
> what the
> patterns of interaction are and what parameters are needed. The
> solution will not be identical to Fortress because the solution will
> involve the passing around of meta-info and meta-data to the target
> handlers.
>
> >> o Lifecycle Extensions
> >>
> >> Implementation of the features discussed in Berin's email:
> >>
> >>
> >>
> > http://marc.theaimsgroup.com/?l=avalon-dev&m=102830949902694&w=2
> >
> >
> >We need to standardize on one implementation.
> >
> > o Merlin logging management
> >
> > Stephen mentioned to me that Merlin's logging management is
> > different than both Phoenix and ECM/Fortress. He mentioned to me
> > the possibility of supporting the ECM style configuration, I
> > guess we need to cover this one in a bit more detail.
> >
> >Why does this not surprise me?
> >
>
> Ouch!
>
> >I am very curious as to what exactly is different.
> >
>
> Both Phoenix and the Excalibur Logging configuration stules
> mix together
> the logging setup for the manager with catagories for
> components. I.e.
> you are forced to declare everything in a single location. In Merlin
> components can be packagd with profiles which contain
> information about
> default priorities, and type information which declares the logging
> categories for the component type. Before putting together the Merlin
> logging model I went over the Phoenix and Excalibur Logging
> in detail.
> The good things about Phoenix 1.0 logging was simplicity. The good
> thing about Excalibur Logging was breath of coverage.
> However, both mix
> information from type, profile and system domains so
> something new was a
> necessity. Keep in mind that every <thing/> in the type and profile
> defintion in Merlin gets translated into a class of some kind
> - so its
> not just a question of using the same XML - its much more a
> question of
> achieving a clean API.
>
> Cheers, Steve.
>
> >
> >
> > And... there are probably others.
> >
> > Also to discuss is the process of *how* we should merge the
> > efforts together. Ideas ?
> >
> >Would Fortress fit within the Merlin concept? I am sure
> that Fortress
> >would be able to adopt the Meta-Info model at the very least. It is
> >important that the Lifecycle Extensions are implemented the same in
> >both systems. If Fortress doesn't fit the Merlin concept
> (i.e. in order
> >to make it fit in Merlin it would contradict the list of
> things I want
> >to maintain), then we need to look at maintaining the consistent
> >meta-info/component definition model at the very least.
> >
> >
> > Ok, well hopefully thats a start. Feel free to add any
> thoughts/issues
> > or comments to the above list, and we can work out solutions for
> >them
> > all. Hopefully that will give us a path forward, combined our
> > 'how' plan, to create our kick ass ECM successor. :)
> >
> >
> >I want to get the migration as painless as possible.
> >
> >
> >--
> >To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> >For
> additional commands,
> e-mail:
> ><ma...@jakarta.apache.org>
> >
> >
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Fri, 9 Aug 2002 05:14, Berin Loritsch wrote:
>
>>>> Stephen mentioned to me that Merlin's logging management is
>>>> different than both Phoenix and ECM/Fortress. He mentioned to me
>>>> the possibility of supporting the ECM style configuration, I
>>>> guess we need to cover this one in a bit more detail.
>>>>
>>>>Why does this not surprise me?
>>>>
>>>Ouch!
>>>
>>Please don't take offense, but you have a track record for redoing
>>everything as opposed to reusing stuff.
>>
>
>Do a diff against some of his code and some of the code I wrote. It is
>asmusing to see that some of his code differs only in package located in and
>the author tags.
>
Pete:
I guess that one of the side effects of forking the useful parts of
containerkit. Given you spending time and effort to diff this stuff -
is this a sign that you are looking into any form of synchrnoization or
are we still worlds apart?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Peter Donald <pe...@apache.org>.
On Fri, 9 Aug 2002 05:14, Berin Loritsch wrote:
> > > Stephen mentioned to me that Merlin's logging management is
> > > different than both Phoenix and ECM/Fortress. He mentioned to me
> > > the possibility of supporting the ECM style configuration, I
> > > guess we need to cover this one in a bit more detail.
> > >
> > >Why does this not surprise me?
> >
> > Ouch!
>
> Please don't take offense, but you have a track record for redoing
> everything as opposed to reusing stuff.
Do a diff against some of his code and some of the code I wrote. It is
asmusing to see that some of his code differs only in package located in and
the author tags.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>
>>>* How to programatically add and remove containers from the kernel
>>>
>>>
>>>
>>The approach dependes on if you "inside container space" or
>>"outside".
>>
>>
>
>Could you elaberate on this. My line of thinking is completely inside
>container space. That is how Fortress is meant to work, and I really
>don't see how "outside container space" is really applicable. Of course
>that might be because I view the Kernel as a container of containers.
>
A kernel is a component as a such you can create other components with
dependecies on a kernel. You could for example create a kernel
programatically to manage a hierachy of system services that you want to
use in another component. You just need to declare a new compoent that
has dependecies on a Kernel. In this scenario, the componet is outside
of contasiner space and can access and navigate the container hierachy,
add new containers, install components into the hierachy, etc.
>
>
>
>> If you define a specilized container and you declare this as part of
>>the container declaration in the kernel.xml file, you can intercept
>>things like initialization and so forth. You could for
>>example control
>>the population of the container (component profiles and
>>sub-containers).
>> Here is the code for creating a new sub-container.
>>
>> ReferenceDescriptor containerInterface =
>> new ReferenceDescriptor(
>>"org.apache.excalibur.merlin.container.Container" );
>> ContainerDescriptor descriptor =
>> (ContainerDescriptor) manager.getProfile( containerInterface );
>> Container container =
>> createSubContainer( "my-container", descriptor, new
>>ClasspathDescriptor() );
>>
>>Component addition is simpler - you simply create or locate a
>>component
>>profile and install it into the container. The container will do the
>>rest of the work (validation, assembly, etc).
>>
>>
>
>I figured Component addition is fairly simple.
>
>My view on a hierarchical container system is that a parent container
>completely manages its child containers, and if there is any central
>management, those commands are filtered through the container hierarchy.
>At least this is how I designed Fortress. I originally meant Fortress
>as a Container framework--but instead it became its own entity in its
>own rite.
>
>
Basical principals are the same in Merlin. A context object flows down
the hierachy of containers - however, this is different to the context
object supplied to components. Components onbly get context information
that declare that they need.
>>>I like the shortened name, and I would want to do whatever I can to
>>>keep the notion, even if it is implemented in a different manner.
>>>
>>>
>>>
>>My guess is the in the majority of cases the shorthand name will
>>actually be replaced by a meta-info class and accessor method. For
>>example, to get the logging catagories specific to a particular
>>component - I call something like:
>>
>> CategoriesDescriptor categories = profile.getCategories();
>>
>>
>
>
>Right. Just as long as I can do this:
>
><jdbc-datasource>
> <!-- config info -->
></jdbc-datasource>
>
>as opposed to this:
>
><component interface="......" class="......" handler="......."/>
>
>All of those are (or *should* be) handled in metadata.
>
>
You going have to expand the example before I can give you an answer on
this one.
>
>
>>>He has an idea of how to express the meta-info, but like his
>>>
>>>
>>version of
>>
>>
>>>the Lifecycle Extensions I doubt it follows the same interfaces.
>>>
>>>
>>>
>>Before going in this direction there is more optimization needed in
>>Merlin in the lifestyle area. Currently the assumptions concerning
>>singleton policies are restricted to two classes and I want
>>to get this
>>down to only one. With that done, I will have a good idea of
>>what the
>>patterns of interaction are and what parameters are needed. The
>>solution will not be identical to Fortress because the solution will
>>involve the passing around of meta-info and meta-data to the target
>>handlers.
>>
>>
>
>
>Ok. Right now, you have a "TRANSIENT" and a "SINGLETON" or something
>like that in your lifestyle declaration. All I want to do is grab that
>value and add semantics for "POOLED" and "PER-THREAD".
>
>
Merlin 1.0 has TRANSIENT and SINGELTON.
Merlin 2.0 is only SINGLETON with a plan to add add pluggable handlers.
The idea is that the core Merlin framework will never need anything
more that singleton and the ability to dynamcially load other handlers.
>
>
>>> Stephen mentioned to me that Merlin's logging management is
>>> different than both Phoenix and ECM/Fortress. He mentioned to me
>>> the possibility of supporting the ECM style configuration, I
>>> guess we need to cover this one in a bit more detail.
>>>
>>>Why does this not surprise me?
>>>
>>>
>>>
>>Ouch!
>>
>>
>
>Please don't take offense, but you have a track record for redoing
>everything as opposed to reusing stuff.
>
It's called evolution.
;-)
>>>I am very curious as to what exactly is different.
>>>
>>>
>>>
>>Both Phoenix and the Excalibur Logging configuration stules
>>mix together the logging setup for the manager with catagories for
>>components. I.e.
>>you are forced to declare everything in a single location. In Merlin
>>components can be packagd with profiles which contain
>>information about
>>default priorities, and type information which declares the logging
>>categories for the component type. Before putting together the Merlin
>>logging model I went over the Phoenix and Excalibur Logging
>>in detail.
>>The good things about Phoenix 1.0 logging was simplicity. The good
>>thing about Excalibur Logging was breath of coverage.
>>However, both mix
>>information from type, profile and system domains so
>>something new was a
>>necessity. Keep in mind that every <thing/> in the type and profile
>>defintion in Merlin gets translated into a class of some kind
>>- so its
>>not just a question of using the same XML - its much more a
>>question of
>>achieving a clean API.
>>
>>
>
>
>All that Fortress/ECM does is expose a logger="foo" attribute which is
>used to give the component a separate logging category.
>
>Currently Fortress has separate categories for all its internal systems
>so that we can tune the log files to the tightest degree.
>
>One thing that I like is the ability to have categories relative to
>a root name. For instance, something like Cocoon has a hierarchical
>container system (the sitemap) that has different instances of
>components in the different sitemaps. It would be useful to know
>which component from what sitemap is generating the information.
>
>"cocoon.root.fooapp.generator.file-generator"
>
>or something like that. Is that possible with Merlin?
>
>
>
Yes.
Logging is always relative to the container the object is created in.
If you have a container hierachy aaa/bbb/ccc and you add component xxx
you will get a logging category of aaa.bbb.ccc.xxx. Also, any logging
categories declared i the metamodel for the compoennt type will appear
as subcatagories of xxx (i.e. aaa.bbb.ccc.xxx.my-sub-catefory). All
Merlin substems are seperated out into seperate categories (type loader,
registry, assembly system, export, etc). See doc on logging for
additional information.
Cherrs, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merger of Merlin/Fortress - first steps ?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
> >* How to programatically add and remove containers from the kernel
> >
> The approach dependes on if you "inside container space" or
> "outside".
Could you elaberate on this. My line of thinking is completely inside
container space. That is how Fortress is meant to work, and I really
don't see how "outside container space" is really applicable. Of course
that might be because I view the Kernel as a container of containers.
> If you define a specilized container and you declare this as part of
> the container declaration in the kernel.xml file, you can intercept
> things like initialization and so forth. You could for
> example control
> the population of the container (component profiles and
> sub-containers).
> Here is the code for creating a new sub-container.
>
> ReferenceDescriptor containerInterface =
> new ReferenceDescriptor(
> "org.apache.excalibur.merlin.container.Container" );
> ContainerDescriptor descriptor =
> (ContainerDescriptor) manager.getProfile( containerInterface );
> Container container =
> createSubContainer( "my-container", descriptor, new
> ClasspathDescriptor() );
>
> Component addition is simpler - you simply create or locate a
> component
> profile and install it into the container. The container will do the
> rest of the work (validation, assembly, etc).
I figured Component addition is fairly simple.
My view on a hierarchical container system is that a parent container
completely manages its child containers, and if there is any central
management, those commands are filtered through the container hierarchy.
At least this is how I designed Fortress. I originally meant Fortress
as a Container framework--but instead it became its own entity in its
own rite.
> >
> >I like the shortened name, and I would want to do whatever I can to
> >keep the notion, even if it is implemented in a different manner.
> >
>
> My guess is the in the majority of cases the shorthand name will
> actually be replaced by a meta-info class and accessor method. For
> example, to get the logging catagories specific to a particular
> component - I call something like:
>
> CategoriesDescriptor categories = profile.getCategories();
Right. Just as long as I can do this:
<jdbc-datasource>
<!-- config info -->
</jdbc-datasource>
as opposed to this:
<component interface="......" class="......" handler="......."/>
All of those are (or *should* be) handled in metadata.
> >
> >He has an idea of how to express the meta-info, but like his
> version of
> >the Lifecycle Extensions I doubt it follows the same interfaces.
> >
>
> Before going in this direction there is more optimization needed in
> Merlin in the lifestyle area. Currently the assumptions concerning
> singleton policies are restricted to two classes and I want
> to get this
> down to only one. With that done, I will have a good idea of
> what the
> patterns of interaction are and what parameters are needed. The
> solution will not be identical to Fortress because the solution will
> involve the passing around of meta-info and meta-data to the target
> handlers.
Ok. Right now, you have a "TRANSIENT" and a "SINGLETON" or something
like that in your lifestyle declaration. All I want to do is grab that
value and add semantics for "POOLED" and "PER-THREAD".
> > Stephen mentioned to me that Merlin's logging management is
> > different than both Phoenix and ECM/Fortress. He mentioned to me
> > the possibility of supporting the ECM style configuration, I
> > guess we need to cover this one in a bit more detail.
> >
> >Why does this not surprise me?
> >
>
> Ouch!
Please don't take offense, but you have a track record for redoing
everything as opposed to reusing stuff.
> >I am very curious as to what exactly is different.
> >
>
> Both Phoenix and the Excalibur Logging configuration stules
> mix together
> the logging setup for the manager with catagories for
> components. I.e.
> you are forced to declare everything in a single location. In Merlin
> components can be packagd with profiles which contain
> information about
> default priorities, and type information which declares the logging
> categories for the component type. Before putting together the Merlin
> logging model I went over the Phoenix and Excalibur Logging
> in detail.
> The good things about Phoenix 1.0 logging was simplicity. The good
> thing about Excalibur Logging was breath of coverage.
> However, both mix
> information from type, profile and system domains so
> something new was a
> necessity. Keep in mind that every <thing/> in the type and profile
> defintion in Merlin gets translated into a class of some kind
> - so its
> not just a question of using the same XML - its much more a
> question of
> achieving a clean API.
All that Fortress/ECM does is expose a logger="foo" attribute which is
used to give the component a separate logging category.
Currently Fortress has separate categories for all its internal systems
so that we can tune the log files to the tightest degree.
One thing that I like is the ability to have categories relative to
a root name. For instance, something like Cocoon has a hierarchical
container system (the sitemap) that has different instances of
components in the different sitemaps. It would be useful to know
which component from what sitemap is generating the information.
"cocoon.root.fooapp.generator.file-generator"
or something like that. Is that possible with Merlin?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merger of Merlin/Fortress - first steps ?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>Steps that we need to take (no order implied)
>
>* Merging of lifecycle extension mechanisms
>* Fortress adopting the Meta-Info model from Merlin
>* Creation of a tool to generate the Meta-Info files
>* Determine how Fortress and Merlin relate
>
>Things I would like to see Fortress maintain:
>
>* Asynchronous component management
>* Hiding the creation of the ***Managers from the end user
>* Using Context values to pass in the necessary info
>* Automatic determination of ServiceSelector or equiv. for return value
>* Separation of lookup interface and container
>
>Things I wold like to see Fortress change:
>
>* Need for the .roles file
>* hiding the ContextManager inside the ContainerManager
>
>
>Things I would like to know from Merlin:
>
>* How Kernel and Containers relate
>
The Kernel manages a single container hierachy whereas a Container is a
node in that hierachy. A kernel's primary objective is to expose a set
of Resource (a reference to a component). The kernel interface does not
imply anything about how thaese resoruces are established. The
DefaultKernel implementation uses a container hierachy as its management
approach.
Here is a summary of the main kernel functions:
* sets up the root directory for the system under the key "avalon:home"
* creates a singleton logging manager
* builds information for managing jar file extensions
* builds information about the kernel classpath
* creates a Type Manager and assignes it as the context classloader
* creates the root container
* handles requests for initialization, startup, shutdown which tigger
the same actions on the root container
* manages veirfication of the integrity of the component relationships
across the hierachy
* manages the exporting of the aggregate set of resources established
by the container hierachy
Here is a summary of the container functions
* is supplied with a type manager and meta-info about itself
* establishes a new thread of execution on initialization
* coodinates sub-container initilisation, startup, shutdown, etc.
* manages partial failure of a sub-container
* state and content change events to its container
* access to sub-containers
* access to container components (via Resource holders)
* dynamic addition of component profiles
* dynamic addition of sub-containers
>
>* How to programatically add and remove containers from the kernel
>
>
>
The approach dependes on if you "inside container space" or "outside".
If you define a specilized container and you declare this as part of
the container declaration in the kernel.xml file, you can intercept
things like initialization and so forth. You could for example control
the population of the container (component profiles and sub-containers).
Here is the code for creating a new sub-container.
ReferenceDescriptor containerInterface =
new ReferenceDescriptor(
"org.apache.excalibur.merlin.container.Container" );
ContainerDescriptor descriptor =
(ContainerDescriptor) manager.getProfile( containerInterface );
Container container =
createSubContainer( "my-container", descriptor, new
ClasspathDescriptor() );
Component addition is simpler - you simply create or locate a component
profile and install it into the container. The container will do the
rest of the work (validation, assembly, etc).
>>From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
>>
>>
>
>
>
>>Hi All,
>>
>> We've been talking a lot recently about the potential merger of
>> Fortress and Merlin into one effort to come up with a rock-solid
>> replacement for ECM.
>>
>> Everyone seems to think this would be a worthwhile goal, so lets
>> start to look at the issues involed.
>>
>> o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
>>
>>
>
>We have been wanting to do this for a while now.
>
>
>
>
>> ECM/Fortress uses the RoleManager approach, which allows you to
>> specify a shorthand name for a role (as opposed to a particular
>> roles complete class name). This shorthand can then be
>> used in the
>> .xconf configuration file which specifies config data for all
>> components that ECM/Fortress instance is managing.
>>
>>
>
>I like the shortened name, and I would want to do whatever I can to keep
>the notion, even if it is implemented in a different manner.
>
My guess is the in the majority of cases the shorthand name will
actually be replaced by a meta-info class and accessor method. For
example, to get the logging catagories specific to a particular
component - I call something like:
CategoriesDescriptor categories = profile.getCategories();
>> What to do ?
>>
>> I would advocate the adoption of Merlin's model, with the
>> development of a transition tool that could generate
>> the required bits
>> for the .roles world, either dynamically or statically at build
>> time - or the development of an ECM style compatibility
>> layer for
>> Merlin that would allow the use of the .roles/.xconf
>> files. Thoughts ?
>>
>>
>
>
>I would really like to see an ANT task or something that will create
>the ***.xinfo files for us. Esp. for migrating from ECM land. It will
>enable a quicker migration.
>
>I kind of like the idea of the XDoclet concept from Phoenix, although
>I am not sure if I fully understand what gets declared where and why.
>It is something that I would like to get finalized.
>
>The attributes in XDoclet form are easier to maintain than a separate
>.xinfo file.
>
>
>
>
>> o ComponentSelector
>>
>> ECM/Fortress return ComponentSelectors for lookups that end in
>> role name + selector. From my current understanding
>> Merlin doesn't
>> do this (?). I remember Stephen proposed a solution for
>> this in a
>> previous email which is quoted verbatim below:
>>
>>
>>
>>>>This is the area I see as the "main topic" on merging - and
>>>>its also the source of handreds of emails. Merlin is good a
>>>>"systems assembly" - and it does this using those <classname>.xinfo
>>>>files. From this information it builds up a graph that associates
>>>>the type/profile combinations between supply and consumption
>>>>compoenents. Before the start method is invoked, everyting in Merlin
>>>>is ready - you can request any service (started or not) and you will
>>>>get back a properly prepared service. However, you will never get
>>>>back a selector (selection is done at assembly time). In the
>>>>Fortress case this is hadled at runtime (i.e a combination of late
>>>>service binding and referral of selection to the client). How to
>>>>merge these two approaches? My opinion is that they are seperate
>>>>concerns - imagine the existence of a ServiceManager along side a
>>>>ServiceLocator - ServiceManager providing the assembly time services
>>>>to the component and ServiceLocator supplying the resolution of
>>>>dynamic lookups.
>>>>
>>>>
>
>
>At least for the Fortress branded containers, I would like to see
>the **Selector pattern for something that will help in the transition.
>Fortress is a good migration tool because you can access your desired
>components either through a Selector or directly. That way, as
>components are written they can opt out of assuming the existence of
>a selector at all. As we approach A5, the generic selector can be
>removed from the picture.
>
>
>
>
>> o Fortress style ComponentHandlers
>>
>> Fortress allows the developer to specify the usage of a
>> particular
>> component, ie. whether it should be pooled, reused in
>> all threads,
>> or created and destroyed per lookup/release.
>>
>> Merlin currently assumes thread safe singleton components only.
>>
>>
>
>If Merlin wants to reuse those ComponentHandlers, it is free to
>do so. If the existence of those handlers is only within the
>Fortress brand of containers, then we need Fortress to work within
>a Merlin system.
>
>
>
>
>> Stephen told me offline that this one is on his current
>> TODO list
>> - any further info there Stephen ? will it be similar to the
>> Fortress approach ? ie. can the developer specify how a
>> particular
>> component can be handled ?
>>
>>
>
>He has an idea of how to express the meta-info, but like his version
>of the Lifecycle Extensions I doubt it follows the same interfaces.
>
Before going in this direction there is more optimization needed in
Merlin in the lifestyle area. Currently the assumptions concerning
singleton policies are restricted to two classes and I want to get this
down to only one. With that done, I will have a good idea of what the
patterns of interaction are and what parameters are needed. The
solution will not be identical to Fortress because the solution will
involve the passing around of meta-info and meta-data to the target
handlers.
>> o Lifecycle Extensions
>>
>> Implementation of the features discussed in Berin's email:
>>
>>
>>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=102830949902694&w=2
>
>
>We need to standardize on one implementation.
>
> o Merlin logging management
>
> Stephen mentioned to me that Merlin's logging management is
> different than both Phoenix and ECM/Fortress. He mentioned to me
> the possibility of supporting the ECM style configuration, I
> guess we need to cover this one in a bit more detail.
>
>Why does this not surprise me?
>
Ouch!
>I am very curious as to what exactly is different.
>
Both Phoenix and the Excalibur Logging configuration stules mix together
the logging setup for the manager with catagories for components. I.e.
you are forced to declare everything in a single location. In Merlin
components can be packagd with profiles which contain information about
default priorities, and type information which declares the logging
categories for the component type. Before putting together the Merlin
logging model I went over the Phoenix and Excalibur Logging in detail.
The good things about Phoenix 1.0 logging was simplicity. The good
thing about Excalibur Logging was breath of coverage. However, both mix
information from type, profile and system domains so something new was a
necessity. Keep in mind that every <thing/> in the type and profile
defintion in Merlin gets translated into a class of some kind - so its
not just a question of using the same XML - its much more a question of
achieving a clean API.
Cheers, Steve.
>
>
> And... there are probably others.
>
> Also to discuss is the process of *how* we should merge the
> efforts together. Ideas ?
>
>Would Fortress fit within the Merlin concept? I am sure that Fortress
>would be able to adopt the Meta-Info model at the very least. It is
>important that the Lifecycle Extensions are implemented the same in both
>systems. If Fortress doesn't fit the Merlin concept (i.e. in order to
>make it fit in Merlin it would contradict the list of things I want to
>maintain), then we need to look at maintaining the consistent
>meta-info/component definition model at the very least.
>
>
> Ok, well hopefully thats a start. Feel free to add any
>thoughts/issues
> or comments to the above list, and we can work out solutions for
>them
> all. Hopefully that will give us a path forward, combined our
> 'how' plan, to create our kick ass ECM successor. :)
>
>
>I want to get the migration as painless as possible.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merger of Merlin/Fortress - first steps ?
Posted by Berin Loritsch <bl...@apache.org>.
Steps that we need to take (no order implied)
* Merging of lifecycle extension mechanisms
* Fortress adopting the Meta-Info model from Merlin
* Creation of a tool to generate the Meta-Info files
* Determine how Fortress and Merlin relate
Things I would like to see Fortress maintain:
* Asynchronous component management
* Hiding the creation of the ***Managers from the end user
* Using Context values to pass in the necessary info
* Automatic determination of ServiceSelector or equiv. for return value
* Separation of lookup interface and container
Things I wold like to see Fortress change:
* Need for the .roles file
* hiding the ContextManager inside the ContainerManager
Things I would like to know from Merlin:
* How Kernel and Containers relate
* How to programatically add and remove containers from the kernel
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
>
> Hi All,
>
> We've been talking a lot recently about the potential merger of
> Fortress and Merlin into one effort to come up with a rock-solid
> replacement for ECM.
>
> Everyone seems to think this would be a worthwhile goal, so lets
> start to look at the issues involed.
>
> o use of .xinfo/.xprofile/.xconfig vs role manager/.xconf
We have been wanting to do this for a while now.
> ECM/Fortress uses the RoleManager approach, which allows you to
> specify a shorthand name for a role (as opposed to a particular
> roles complete class name). This shorthand can then be
> used in the
> .xconf configuration file which specifies config data for all
> components that ECM/Fortress instance is managing.
I like the shortened name, and I would want to do whatever I can to keep
the notion, even if it is implemented in a different manner.
> What to do ?
>
> I would advocate the adoption of Merlin's model, with the
> development of a transition tool that could generate
> the required bits
> for the .roles world, either dynamically or statically at build
> time - or the development of an ECM style compatibility
> layer for
> Merlin that would allow the use of the .roles/.xconf
> files. Thoughts ?
I would really like to see an ANT task or something that will create
the ***.xinfo files for us. Esp. for migrating from ECM land. It will
enable a quicker migration.
I kind of like the idea of the XDoclet concept from Phoenix, although
I am not sure if I fully understand what gets declared where and why.
It is something that I would like to get finalized.
The attributes in XDoclet form are easier to maintain than a separate
.xinfo file.
> o ComponentSelector
>
> ECM/Fortress return ComponentSelectors for lookups that end in
> role name + selector. From my current understanding
> Merlin doesn't
> do this (?). I remember Stephen proposed a solution for
> this in a
> previous email which is quoted verbatim below:
>
> >>This is the area I see as the "main topic" on merging - and
> its also
> >>the source of handreds of emails. Merlin is good a "systems
> assembly"
> >>- and it does this using those <sclasname>..xinfo files. From this
> >>information it builds up a graph that associates the type/profile
> >>combinations between supply and consumption compoenents.
> >>Before the start method is invoked, everyting in Merlin is
> ready -
> >>you can request any service (started or not) and you will
> get back a
> >>properly prepared service. However, you will never get back a
> >>selector (selection is done at assembly time). In the
> Fortress case
> >>this is hadled at runtime (i.e a combination of late
> service binding
> >>and referral of selection to the client). How to merge these two
> >>approaches? My opinion is that they are seperate concerns
> - imagine
> >>the existence of a ServiceManager along side a ServiceLocator -
> >>ServiceManager providing the assembly time services to the
> component
> >>and ServiceLocator supplying the resolution of dynamic lookups.
At least for the Fortress branded containers, I would like to see
the **Selector pattern for something that will help in the transition.
Fortress is a good migration tool because you can access your desired
components either through a Selector or directly. That way, as
components are written they can opt out of assuming the existence of
a selector at all. As we approach A5, the generic selector can be
removed from the picture.
> o Fortress style ComponentHandlers
>
> Fortress allows the developer to specify the usage of a
> particular
> component, ie. whether it should be pooled, reused in
> all threads,
> or created and destroyed per lookup/release.
>
> Merlin currently assumes thread safe singleton components only.
If Merlin wants to reuse those ComponentHandlers, it is free to
do so. If the existence of those handlers is only within the
Fortress brand of containers, then we need Fortress to work within
a Merlin system.
> Stephen told me offline that this one is on his current
> TODO list
> - any further info there Stephen ? will it be similar to the
> Fortress approach ? ie. can the developer specify how a
> particular
> component can be handled ?
He has an idea of how to express the meta-info, but like his version
of the Lifecycle Extensions I doubt it follows the same interfaces.
> o Lifecycle Extensions
>
> Implementation of the features discussed in Berin's email:
>
http://marc.theaimsgroup.com/?l=avalon-dev&m=102830949902694&w=2
We need to standardize on one implementation.
o Merlin logging management
Stephen mentioned to me that Merlin's logging management is
different than both Phoenix and ECM/Fortress. He mentioned to me
the possibility of supporting the ECM style configuration, I
guess
we need to cover this one in a bit more detail.
Why does this not surprise me?
I am very curious as to what exactly is different.
And... there are probably others..
Also to discuss is the process of *how* we should merge the
efforts
together. Ideas ?
Would Fortress fit within the Merlin concept? I am sure that Fortress
would
be able to adopt the Meta-Info model at the very least. It is important
that the Lifecycle Extensions are implemented the same in both systems.
If Fortress doesn't fit the Merlin concept (i.e. in order to make it fit
in
Merlin it would contradict the list of things I want to maintain), then
we
need to look at maintaining the consistent meta-info/component
definition
model at the very least.
Ok, well hopefully thats a start. Feel free to add any
thoughts/issues
or comments to the above list, and we can work out solutions for
them
all. Hopefully that will give us a path forward, combined our
'how' plan, to create our kick ass ECM successor. :)
I want to get the migration as painless as possible.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>