You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by fi...@cirquedigital.com on 2004/04/08 20:16:05 UTC
Fortress to Merlin howto ?
Hi,
Is there any documentation so far on the migration from Fortress
to Merlin ? I think even a quick howto describing some of the pitfalls
would be very helpful..
Thanks,
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by Stephen McConnell <mc...@apache.org>.
filipdef@cirquedigital.com wrote:
>>filipdef@cirquedigital.com wrote:
>>
>>>Hi,
>>>
>>>Is there any documentation so far on the migration from Fortress
>>>to Merlin ? I think even a quick howto describing some of the pitfalls
>>>would be very helpful..
>>
>>This subject is largely a work in progress. So far I have not dealt
>>with any Fortress to Merlin migration scenarios, only ECM to Fortress.
>>However - in principal a Fortress to Merlin migration should be easier
>>than a ECM to Merlin migration.
>
>
> that's a relief ;-)
>
>
>>Important points:
>>
>> * merlin will do a lot of the work for you - in merlin land
>> less information is better - merlin will do the grunt work
>> for you
>>
>> * pooled lifestyle are not supported in native merlin -
>> basically the best approach is to declare a component that
>> provides the pool and service interface to access a pooled
>> instance (lots of technical reasons backing this)
>
>
> n/a in my use case.
>
>
>> * selectors are not supported - but if you need selection
>> semantics then solutions are available using the finder
>> facility - post some details about your scenario and we
>> will help with the migration
>
>
> that is an issue for me: GUIApp uses selectors to get to specific
> screen instances and my app does as well; basically lots of times
> I have a component that has a number of instances with different
> configurations, sometimes different implementations that all need
> to work together.
>
> E.g.
> InfoProvider --> DiskInfoProvider
> --> JDBCInfoProvider
> --> FtpInfoProvider
>
> All these do the same thing (provide info about my nodes), but
> use a different transport for each case.
OK - here is some terminology:
deployment scenario
the description of a request for the deployment
of a component type with a particular configuration,
content, parameters, service binding, etc. that is
uniquely addressable
component type
a description of a component, including its class,
deployment and runtime dependencies and associated
attributes
service
a functional interface exposed by an identifiable
component type
In you case InfoProvider is a common service. You have multiple
deployment scenarios (DiskInfoProvider, JDBCInfoProvider,
FtpInfoProvider, etc.) .. and you need to be able to declare that your
service dependency is more than just the interface - its also the
functionality delivered by the service.
We can setup a test case that leverages parameterized service
definitions as the selection reference. What this means is that at a
code level you should be able to publish not only the service interface
that a component supports, but also associate attributes with the
exported service definition. This is real important because it means
that we can separate the component implementation declarations from the
deployment declarations - which means your components become reusable.
However .. you go on to say:
> Now, the use case is that multiple of these guys are loaded and
> that they can be activated in sets. E.g. you can have 5 info
> providers and declare 2 sets, set 1 has info providers 1,2,3,4
> and set 2 has info providers 3,4,5.
>
> The output of the info providers gets aggregated by the container
> and the container answers the questions from the user (custom
> container in fortress).
>
> The actual implementation of this typically does the following
>
> Info Provider Other Provider
>
> | |
>
> DiskInfoProvider DiskOtherProvider
>
> \ |
>
> DiskProviderBase
>
>
> So the actual DiskXXX implementations share a common base component
> that deals with e.g. the root directory that those particular DiskXXX
> components share.. (you can have more than one DiskXXX set of components
> that have a different base). So, I declare these things as:
>
> <disk-base id="base1" root="C:/bla" />
> <disk-index id="index1" base="base1" />
>
> <disk-base id="base2" root="//SERVER/disk" />
> <disk-index id="index2" base="base2" />
> <disk-index id="index2b" base="base2" />
This is deployment level differentiation (as distinct for
differentiation of the semantics underlying a particular service). For
example in the above case you qualifying a particular deployment
scenario (with a configuration or context). In effect what you are
doing is describing the implementation of a sub-system that is capable
of providing a set of features where features are keyed by an id.
To maintain the overall component model integrity we need to encapsulate
this into either (a) a specific component deployment scenario, or (b) a
distinct service. This is what we'll sort out with the avalon-finder
facility.
> The index components then do serviceManager.lookup( Base.ROLE+"/"+
> conf.getAttribute("base")) to get to the base component..
Which is where the problems lies. This introduced semantics to an
generic operation that cross a boundary between component type
information and component deployment information.
Instead we should be doing:
MyFinder finder =
(MyFinder) serviceManager.lookup( "myFinder" );
Object wiget = finder.locate( conf.getAttribute("base") );
> Just doing a generic serviceManager.lookup( Base.ROLE ) won't work
> in this case, I need to find a specific base rather than just any
> base.
>
> (this kindof scenario happens a couple of times)
>
>
>>Take a tour of the tutorials .. they provide a good insight into how
>>merlin works and from that your should get a good idea of transition
>>overhead. Normally a transition should be relatively easy. But there
>>are special cases that require attention - and for the time being that
>>means posting info to the list about your scenario.
>
>
> will do, thanks.. Started looking at it a while ago, but then
> got sidetracked in delivery stuff..
>
> Another concern I have is the startup speed of Merlin. One of my
> applications is a GUI application (if you didn't get this by now ;-) )
> and obviously for these things startup time is crucial, and needs to
> be in the order of 3-4 seconds on a fast computer -- any ideas on
> how merlin will behave in this respect ?
I think we can deal with this via something inside the kernel.
Basically what I'm thinking of is some properties that tell the kernel
its running in an interactive mode together with sufficient info to
generate the splash screen during kernel deployment.
Cheers, Stephen.
> Thanks a lot,
>
> - Filip
>
>
>
>>Cheers, Stephen.
>>
>>
>>>Thanks,
>>>- Filip
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>>For additional commands, e-mail: dev-help@avalon.apache.org
>>>
>>>
>>
>>
>>--
>>
>>|------------------------------------------------|
>>| Magic by Merlin |
>>| Production by Avalon |
>>| |
>>| http://avalon.apache.org/merlin |
>>| http://dpml.net/merlin/distributions/latest |
>>|------------------------------------------------|
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by fi...@cirquedigital.com.
> filipdef@cirquedigital.com wrote:
>> Hi,
>>
>> Is there any documentation so far on the migration from Fortress
>> to Merlin ? I think even a quick howto describing some of the pitfalls
>> would be very helpful..
>
> This subject is largely a work in progress. So far I have not dealt
> with any Fortress to Merlin migration scenarios, only ECM to Fortress.
> However - in principal a Fortress to Merlin migration should be easier
> than a ECM to Merlin migration.
that's a relief ;-)
>
> Important points:
>
> * merlin will do a lot of the work for you - in merlin land
> less information is better - merlin will do the grunt work
> for you
>
> * pooled lifestyle are not supported in native merlin -
> basically the best approach is to declare a component that
> provides the pool and service interface to access a pooled
> instance (lots of technical reasons backing this)
n/a in my use case.
>
> * selectors are not supported - but if you need selection
> semantics then solutions are available using the finder
> facility - post some details about your scenario and we
> will help with the migration
that is an issue for me: GUIApp uses selectors to get to specific
screen instances and my app does as well; basically lots of times
I have a component that has a number of instances with different
configurations, sometimes different implementations that all need
to work together.
E.g.
InfoProvider --> DiskInfoProvider
--> JDBCInfoProvider
--> FtpInfoProvider
All these do the same thing (provide info about my nodes), but
use a different transport for each case.
Now, the use case is that multiple of these guys are loaded and
that they can be activated in sets. E.g. you can have 5 info
providers and declare 2 sets, set 1 has info providers 1,2,3,4
and set 2 has info providers 3,4,5.
The output of the info providers gets aggregated by the container
and the container answers the questions from the user (custom
container in fortress).
The actual implementation of this typically does the following
Info Provider Other Provider
| |
DiskInfoProvider DiskOtherProvider
\ |
DiskProviderBase
So the actual DiskXXX implementations share a common base component
that deals with e.g. the root directory that those particular DiskXXX
components share.. (you can have more than one DiskXXX set of components
that have a different base). So, I declare these things as:
<disk-base id="base1" root="C:/bla" />
<disk-index id="index1" base="base1" />
<disk-base id="base2" root="//SERVER/disk" />
<disk-index id="index2" base="base2" />
<disk-index id="index2b" base="base2" />
The index components then do serviceManager.lookup( Base.ROLE+"/"+
conf.getAttribute("base")) to get to the base component..
Just doing a generic serviceManager.lookup( Base.ROLE ) won't work
in this case, I need to find a specific base rather than just any
base.
(this kindof scenario happens a couple of times)
>
> Take a tour of the tutorials .. they provide a good insight into how
> merlin works and from that your should get a good idea of transition
> overhead. Normally a transition should be relatively easy. But there
> are special cases that require attention - and for the time being that
> means posting info to the list about your scenario.
will do, thanks.. Started looking at it a while ago, but then
got sidetracked in delivery stuff..
Another concern I have is the startup speed of Merlin. One of my
applications is a GUI application (if you didn't get this by now ;-) )
and obviously for these things startup time is crucial, and needs to
be in the order of 3-4 seconds on a fast computer -- any ideas on
how merlin will behave in this respect ?
Thanks a lot,
- Filip
>
> Cheers, Stephen.
>
>>
>> Thanks,
>> - Filip
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>> For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>
>
>
> --
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/merlin/distributions/latest |
> |------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fortress to Merlin howto ?
Posted by Stephen McConnell <mc...@apache.org>.
filipdef@cirquedigital.com wrote:
> Hi,
>
> Is there any documentation so far on the migration from Fortress
> to Merlin ? I think even a quick howto describing some of the pitfalls
> would be very helpful..
This subject is largely a work in progress. So far I have not dealt
with any Fortress to Merlin migration scenarios, only ECM to Fortress.
However - in principal a Fortress to Merlin migration should be easier
than a ECM to Merlin migration.
Important points:
* merlin will do a lot of the work for you - in merlin land
less information is better - merlin will do the grunt work
for you
* pooled lifestyle are not supported in native merlin -
basically the best approach is to declare a component that
provides the pool and service interface to access a pooled
instance (lots of technical reasons backing this)
* selectors are not supported - but if you need selection
semantics then solutions are available using the finder
facility - post some details about your scenario and we
will help with the migration
Take a tour of the tutorials .. they provide a good insight into how
merlin works and from that your should get a good idea of transition
overhead. Normally a transition should be relatively easy. But there
are special cases that require attention - and for the time being that
means posting info to the list about your scenario.
Cheers, Stephen.
>
> Thanks,
> - Filip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org