Hello,
For the redeploy thing, I agree with Jules: it is very important to have such a
semantic. And as David said, to be properly done, it must be handled at the
MBEAN-interceptor level because the redeploy may change the list of interceptors =>
setting this in a container interceptor is not a definitive option.
Nevertheless, Just for your information, I've implemented (for the clustering),
yesterday, a CleanShutdownInterceptor that, at least, allows for clean shutdown of a
containers by making wait the stop call until all running invocations are done (all
new invocations are redirected to another node of the cluster.)
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Larry Sanderson
> Envoy� : lundi, 15 avril 2002 02:44
> � : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] Deployer design
>
>
> > Perhaps you can take an initial stab on a requirements list for the
> deployment
> > systen, based on the existing proposals (specifically david's, mine &
> yours +
> > comments by jules and such).
> >
> > If you have time it would be helpful to move this work forward.
>
> I can find the time, but I think I am the least experienced JBoss user /
> developer on this thread. Once I have something to post, I will
> need a lot
> of feedback. I'll let you know when I have something.
>
> -Larry
>
> >
> > --jason
> >
> >
> > Quoting Larry Sanderson <[EMAIL PROTECTED]>:
> >
> > > > YADD (Yet Another Deployer Design)... comments below.
> > > >
> > > > > I see two major problems with the current usage: 1)
> MainDeployer is
> a
> > > > > bootstrapped class, with no way to provide an alternate
> implementation,
> > > 2)
> > > > > All SubDeployers rely on a concrete implementation of deployer:
> > > MainDeployer,
> > > >
> > > > Why do you need another impl of MainDeployer. This component serves
> to
> > > > aggregate SubDeployers and to provide a common interface for clients
> into
> > > the
> > > > deployment system.
> > > >
> > > > It might be doing a little much at the moment (I haven't looked at
> what
> > > the
> > > > code looks like this week), but from a concept pov there is
> no reason
> to
> > > make
> > > > this pluggable.
> > >
> > > I don't know... perhaps someone would like to add a custom layer of
> > > security
> > > on all deployments. Perhaps they would like to get an email when new
> > > deployments occur. Who knows? The point is I can see no down-side to
> > > making this pluggable, and it is a very easy patch. More important,
> though,
> > > is to prevent SubDeployers from accessing MainDeployer specific
> > > functionality. That is just bad design.
> > >
> > > > Note, that this change will invalidate the Deployer usage which is
> needed
> > > for
> > > > DeploymentScanner (including NetBoot caching components). That
> doesn't
> > > mean
> > > > those components can not change to adapt to new designs,
> but it seems
> > > like
> > > > your design is not taking this into account.
> > >
> > > I'm not sure what you mean here. By Deployer usage do you mean
> > > lastDeployed
> > > and lastModified? I had planned on leaving these in the
> DeploymentInfo
> > > object. What are NetBoot caching components?
> > > >
> > > > > Let me know if you have any comments. I would like to get started
> on
> > > this
> > > > > soon.
> > > >
> > > > I think we need to think hard about the requirements of the
> deployment
> > > > system... look at the current use cases and those we
> invision for the
> > > future
> > > > before we start redesigning this critical subsystem again.
> > > >
> > > > This is definetly not going to happen for 3.0, perhaps 3.1-3.2.
> > > >
> > > > We really need to get this crap down right... we seem to change this
> > > every
> > > few
> > > > weeks, which just causes trouble for those who rely on how it works,
> > > those
> > > who
> > > > write documentation for it & those who provide components around it.
> > > >
> > > > Let us take some time to get this done right... then leave it alone.
> > >
> > > I agree. Thanks for your feedback.
> > >
> > > -Larry
> > >
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> >
> >
> > -------------------------------------------------
> > This mail sent through IMP: http://horde.org/imp/
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
