!
>
>
> 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 :
ions 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 PROT
ions 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 PROT
What? How does JBoss.NET get in there? Really, I don't get how you come up
with these things sometimes.
JBoss.NET is not accessable from this component... since JBoss.NET is itself
deployed here.
I would have to be a JMX notification, which you could then install an
JBoss.NET adapter or wh
> I think you misunderstand me. I am as cocky and arragant as the next Java
> programmer, and I'm possitive I can design it better than every one else
> out there ;-)
Well, we shall see about that... you could be right... or not.
> It's the JBoss experience I lack, so my use cases will not ha
> Don't underestimate yourself ;)
>
> I am just asking for a list of requirements right now, not a design... and
of
> course we will give you feedback.
I think you misunderstand me. I am as cocky and arragant as the next Java
programmer, and I'm possitive I can design it better than every one el
on 15-04-2 02.10, David Jencks at [EMAIL PROTECTED] wrote:
> On 2002.04.14 19:44:06 -0400 Peter Fagerlund wrote:
>> on 15-04-2 01.24, Larry Sanderson at [EMAIL PROTECTED] wrote:
>>
>>> I don't know... perhaps someone would like to add a custom layer of
>> security
>>> on all deployments. Perhap
Don't underestimate yourself ;)
I am just asking for a list of requirements right now, not a design... and of
course we will give you feedback.
--jason
Quoting Larry Sanderson <[EMAIL PROTECTED]>:
> > Perhaps you can take an initial stab on a requirements list for the
> deployment
> > systen
> I have been planning for a long time and hope to be able to work on very
> soon another major change to deployment.
>
> My plan is to divide deployment up into:
>
> 1. add all the classes to the classloader
>
> 2. Transform all the dd's into mbean configuration (using xslt mostly)
>
> 3. Deploy
> 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
I would have thought this was related.
I think I remember remarking that JSR 88 had deploy/start/stop/undeploy
and redeploy, but no restart...
I think for completeness we should probably support restart as well.
No-one should be forced to implement these extensions. They should
simply be avai
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.
--jason
Quoting Larry Sanderson <[EMAIL PR
I agree. redeploy is different, or could be different and in some cases (like
yours) should be different than undeploy/deploy.
--jason
Quoting Jules Gosnell <[EMAIL PROTECTED]>:
> Jason Dillon wrote:
> > Yes perhaps... would not hurt to add the method to the interface... though
> in
> > mos
On 2002.04.14 19:44:06 -0400 Peter Fagerlund wrote:
> on 15-04-2 01.24, Larry Sanderson at [EMAIL PROTECTED] wrote:
>
> > 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.
> > 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
The redeploy idea is similar to the idea of making mbean invocations (such
as on an ejb container) wait during service lifecycle operations -- so if
you stop and restart an mbean, calls are blocked until the start is done.
We were thinking of doing this in (model) mbean interceptors. Would
somet
Jason Dillon wrote:
> Yes perhaps... would not hurt to add the method to the interface... though in
> most cases undeploy/deploy works fine. It is possible that we might want to
> have redploy specific behavior... but we need to make sure that
> undeploy/deploy also works in the same fashion.
on 15-04-2 01.24, Larry Sanderson at [EMAIL PROTECTED] wrote:
> 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 th
> 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,
>
> W
> I'm not entirely sure what you mean by the subdeployer's lifecycle. If
you
> mbean the sequence of init, create, start calls, note that these are not
> done all at once per package, but each step is run through every
subpackage
> before the next is started. Keeping the functionality in MainDep
Yes perhaps... would not hurt to add the method to the interface... though in
most cases undeploy/deploy works fine. It is possible that we might want to
have redploy specific behavior... but we need to make sure that
undeploy/deploy also works in the same fashion. I think that if the
underl
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 ne
I have been planning for a long time and hope to be able to work on very
soon another major change to deployment.
My plan is to divide deployment up into:
1. add all the classes to the classloader
2. Transform all the dd's into mbean configuration (using xslt mostly)
3. Deploy the resulting mb
My penniesworth:
I think it important that at some stage we introduce a concept of
'redeploy()'.
From a quick glance at JSR 88, this looks to be an optional extension,
but from an enterprise point of view I think that this is important.
The default implementation could just 'undeploy(); depl
I have been working with the deployers for the last week or so, and I have been
thinking about some design changes that would help clean it up.
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 Su
25 matches
Mail list logo
