You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Toma, Mircea" <mi...@SierraSystems.com> on 2001/09/27 00:33:36 UTC
DeployMonitor/Manager for Phoenix
Hi,
I'm finally out of the most stressful project in my life (until now at list)
,hoping that I will have time to contribute more!
Right now I am not able to come with fresh ideas for the configuration
management using JMX but I think I can help with the hot deploy/undeploy of
.sar files. The way I see it solved is by having a DeployMonitor/Manager
(however you want to call it) that will monitor the "applications-directory"
(or a list of URL-s?) and deploy or undeploy the .sar files. These manager
will reuse the code currently located in
DefaultEmbeddor.deployDefaultApplications() and the subsequent methods and
the "monitor" package from Excalibur. Also I will implement
DefaultDeployer.undeploy() to do the cleanup on the file system and
ConfigurationRepository. I think that a Kernel.removeApplication(..) is
necessary.
....Thoughts?
Mircea
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Sunday, September 30, 2001 12:24 AM
Subject: Re: DeployMonitor/Manager for Phoenix
> On Sun, 30 Sep 2001 15:49, Mircea Toma wrote:
> > I was thinking of using multiple 'baskets' ( ./apps like directories)
and
> > monitor them all even if they are remote locations ... F.S. of course. I
> > think I know how you see the remote loading + hot deployment done: the
> > DeploymentManager will monitor only the ./apps directory and if an
> > application has to be loaded from a remote location it will be done on
> > demand using Deployer.deploy(..) downloading the application into the
> > ./apps directory thus deploying it?!
>
> I was thinking of downloading it into a ./cache directory but the ./apps
> directory works aswell - however you would have to make sure that there
was
> no name clashes (ie a remote .sar could not overide a local .sar). And you
> would also want to make it possible to clean the cached versions out every
> now and again.
Hmmm ....
>
> Hmmm ... I just had another thought. See what you think of this. In the
other
> JMX and redux thread I mentioned that one option was
>
> > 7. Enhance BlockContext and/or assembly descriptor so that Blocks can be
> > marked as "privlidged" which means they get access to the kernel
interfaces
> > ... including MBeanServer
>
> Now lets say we had a Block that had access to the Deployer interface. In
> this case the Monitor could actually be implemented as a .sar because it
> could monitor the directory and then call the Deployer kernel component.
... ahhh, moving towards the microkernel architecture by pushing services
outside the core ;-)
Ok, I will try and see what comes out!
Mircea
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "Only two things are infinite, the universe and
> human stupidity, and I'm not sure about the
> former." -Albert Einstein
> -----------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Peter Donald <do...@apache.org>.
On Sun, 30 Sep 2001 15:49, Mircea Toma wrote:
> I was thinking of using multiple 'baskets' ( ./apps like directories) and
> monitor them all even if they are remote locations ... F.S. of course. I
> think I know how you see the remote loading + hot deployment done: the
> DeploymentManager will monitor only the ./apps directory and if an
> application has to be loaded from a remote location it will be done on
> demand using Deployer.deploy(..) downloading the application into the
> ./apps directory thus deploying it?!
I was thinking of downloading it into a ./cache directory but the ./apps
directory works aswell - however you would have to make sure that there was
no name clashes (ie a remote .sar could not overide a local .sar). And you
would also want to make it possible to clean the cached versions out every
now and again.
Hmmm ... I just had another thought. See what you think of this. In the other
JMX and redux thread I mentioned that one option was
> 7. Enhance BlockContext and/or assembly descriptor so that Blocks can be
> marked as "privlidged" which means they get access to the kernel interfaces
> ... including MBeanServer
Now lets say we had a Block that had access to the Deployer interface. In
this case the Monitor could actually be implemented as a .sar because it
could monitor the directory and then call the Deployer kernel component.
--
Cheers,
Pete
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Saturday, September 29, 2001 10:11 PM
Subject: Re: DeployMonitor/Manager for Phoenix
> On Sun, 30 Sep 2001 11:56, Mircea Toma wrote:
> > Hi Peter,
> >
> > I have done some coding but I want to confirm with you if this is the
> > direction you want to go?!
>
> Looks good. One question though - wouldn't be easier to have the interface
> use file objects directly rather than using URL objects that are required
to
> be files?
I was thinking of using multiple 'baskets' ( ./apps like directories) and
monitor them all even if they are remote locations ... F.S. of course. I
think I know how you see the remote loading + hot deployment done: the
DeploymentManager will monitor only the ./apps directory and if an
application has to be loaded from a remote location it will be done on
demand using Deployer.deploy(..) downloading the application into the ./apps
directory thus deploying it?!
Mircea
> > I attached the new classes to give you an idea
> > about what I've done. It seems that having a basic implementation for
> > "org.apache.avalon.excalibur.vfs" package would make the code much
cleaner!
>
> Yup. I actually have a basic implementation somewhere around ... I will
try
> to finish fixing it up and check it in ... though it could be a while
before
> I get a chance ;/
>
> --
> Cheers,
>
> Pete
>
> Duct tape is like the force. It has a light side, and a dark side, and
> it binds the universe together ...
> -- Carl Zwanzig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Peter Donald <do...@apache.org>.
On Sun, 30 Sep 2001 11:56, Mircea Toma wrote:
> Hi Peter,
>
> I have done some coding but I want to confirm with you if this is the
> direction you want to go?!
Looks good. One question though - wouldn't be easier to have the interface
use file objects directly rather than using URL objects that are required to
be files?
> I attached the new classes to give you an idea
> about what I've done. It seems that having a basic implementation for
> "org.apache.avalon.excalibur.vfs" package would make the code much cleaner!
Yup. I actually have a basic implementation somewhere around ... I will try
to finish fixing it up and check it in ... though it could be a while before
I get a chance ;/
--
Cheers,
Pete
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Mircea Toma <mi...@home.com>.
Hi Peter,
I have done some coding but I want to confirm with you if this is the
direction you want to go?! I attached the new classes to give you an idea
about what I've done. It seems that having a basic implementation for
"org.apache.avalon.excalibur.vfs" package would make the code much cleaner!
Mircea
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, September 26, 2001 11:35 PM
Subject: Re: DeployMonitor/Manager for Phoenix
> On Thu, 27 Sep 2001 12:28, Mircea Toma wrote:
> > > If you need any other changes to stuff about there I am mucking about
> > > with that stuff atm so just say ;)
> >
> > Wow, lots of changes ...
>
> yep. I just made the final set of massive changes that could effect you.
So
> you should be able to hack at it easily now. The one section that I still
> aren't done with is the manager stuff so if you want to make modes there
give
> me a heads first so we don't step on each others toes.
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------
> "If people are good only because they fear punishment,
> and hope for reward, then we are a sorry lot indeed."
> -Albert Einstein
> ------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
Re: DeployMonitor/Manager for Phoenix
Posted by Peter Donald <do...@apache.org>.
On Thu, 27 Sep 2001 12:28, Mircea Toma wrote:
> > If you need any other changes to stuff about there I am mucking about
> > with that stuff atm so just say ;)
>
> Wow, lots of changes ...
yep. I just made the final set of massive changes that could effect you. So
you should be able to hack at it easily now. The one section that I still
aren't done with is the manager stuff so if you want to make modes there give
me a heads first so we don't step on each others toes.
--
Cheers,
Pete
------------------------------------------------------
"If people are good only because they fear punishment,
and hope for reward, then we are a sorry lot indeed."
-Albert Einstein
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, September 26, 2001 8:01 PM
Subject: Re: DeployMonitor/Manager for Phoenix
> On Thu, 27 Sep 2001 08:33, Toma, Mircea wrote:
> > I'm finally out of the most stressful project in my life (until now at
> > list) ,hoping that I will have time to contribute more!
> > Right now I am not able to come with fresh ideas for the configuration
> > management using JMX but I think I can help with the hot deploy/undeploy
of
> > .sar files. The way I see it solved is by having a DeployMonitor/Manager
> > (however you want to call it) that will monitor the
> > "applications-directory" (or a list of URL-s?) and deploy or undeploy
the
> > .sar files. These manager will reuse the code currently located in
> > DefaultEmbeddor.deployDefaultApplications() and the subsequent methods
and
> > the "monitor" package from Excalibur. Also I will implement
> > DefaultDeployer.undeploy() to do the cleanup on the file system and
> > ConfigurationRepository. I think that a Kernel.removeApplication(..) is
> > necessary.
> >
> > ....Thoughts?
>
> +10000 ;)
>
> They were the next thing on my list todo (I have recently reworked a lot
of
> that stuff to make such thhings easier). The only real issue with undeploy
is
> whether or not you uninstall (ie remove all files from filesystem) aswell.
In
> this case you are probably going to need an install.log file that lists
all
> the files that were extracted and only remove those.
>
> If you need any other changes to stuff about there I am mucking about with
> that stuff atm so just say ;)
Wow, lots of changes ...
Mircea
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------------------
> Don't take life too seriously --
> you'll never get out of it alive.
> -----------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: DeployMonitor/Manager for Phoenix
Posted by Peter Donald <do...@apache.org>.
On Thu, 27 Sep 2001 08:33, Toma, Mircea wrote:
> I'm finally out of the most stressful project in my life (until now at
> list) ,hoping that I will have time to contribute more!
> Right now I am not able to come with fresh ideas for the configuration
> management using JMX but I think I can help with the hot deploy/undeploy of
> .sar files. The way I see it solved is by having a DeployMonitor/Manager
> (however you want to call it) that will monitor the
> "applications-directory" (or a list of URL-s?) and deploy or undeploy the
> .sar files. These manager will reuse the code currently located in
> DefaultEmbeddor.deployDefaultApplications() and the subsequent methods and
> the "monitor" package from Excalibur. Also I will implement
> DefaultDeployer.undeploy() to do the cleanup on the file system and
> ConfigurationRepository. I think that a Kernel.removeApplication(..) is
> necessary.
>
> ....Thoughts?
+10000 ;)
They were the next thing on my list todo (I have recently reworked a lot of
that stuff to make such thhings easier). The only real issue with undeploy is
whether or not you uninstall (ie remove all files from filesystem) aswell. In
this case you are probably going to need an install.log file that lists all
the files that were extracted and only remove those.
If you need any other changes to stuff about there I am mucking about with
that stuff atm so just say ;)
--
Cheers,
Pete
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org