Yes
I am aware of the performance issue introduced by RMI calls, but that could be sorted out �by cashing data in both directions and update manually or on a scheduled basis.
My idea is to develop my components locally (on a local Merlin environment configured to dock to a parent merlin environment).
That way I would transfer my tree transparently without being concerned about transitions from remote to local calls.
Is like a CVS for running entities.
... and that's what I am trying to fish ... just development ... no deployment
the difference?
in deployment you need at least two main steps a) put the component on place b) run it
in docking: just transfer when you are done. And if your component happens to be a web service (as it is usual today) we dont need to bother about RMI (because that is coming from a design decision)
I can give you a long list of benefits if this feature is added ... but let me learn more about the great Merlin.
Cheers //Maquina
From: Niclas Hedhman <[EMAIL PROTECTED]> Reply-To: "Avalon framework users" <[EMAIL PROTECTED]> To: "Avalon framework users" <[EMAIL PROTECTED]> Subject: Re: Working from home and docking Date: Tue, 19 Oct 2004 00:11:10 +0800
On Monday 18 October 2004 23:49, Samuel Ferrer wrote:
> Guys
> I wander if is possible to have a Merlin tree running in my machine and
> have it as a remote child of a leaf at some other Merling tree (on another
> machine).
>
> The idea would be to develop locally but still follow a global structure.
>
> That would give the oportunity to deploy and test locally and then just
> transfer a ready solution to the global solution ... no need for config
> deployment because like I said the local solution would be ready and the
> global solution would have knowledge of my modules all along.
Not sure exactly what you are fishing for...
But,
1. As it is now, it is not possible to reach out and lookup/access components
in other JVMs without some serious implementation of your own behalf. A
generic solution is not likely to occur "soon", and you would probably also
have issues with RMI delays in your application.
2. But I have the feeling that you only want you component/block to work in
the local context without accessing the 'larger' context in your local
runtime.
That is indeed what Metro is all about. Any block can be deployed in a larger
context, without much trouble. Meaning to say, if it works in your local
context, it will work in a larger application (except for conflict on global
resources, and stuff like that). The opposite may not be true, since the
smaller block may be dependent on services that you don't provide in the
local context. For that, you can create small mock-components that does
"enough", and rely on Metro to resolve the dependency automatically (i.e. no
assembly changes) in its larger context.
Please provide more information if that answer wasn't clear enough.
Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
