[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.
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 addressablecomponent type
a description of a component, including its class,
deployment and runtime dependencies and associated
attributesservice
a functional interface exposed by an identifiable
component typeIn 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: [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]
--
|------------------------------------------------| | 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]
