> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/merlin/distributions/latest |
> |------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
