You're taking away all my fun;-))) OK, I won't commit anything if I happen to write it. Back to fixing bugs.
david On 2002.07.31 17:25:23 -0400 Scott M Stark wrote: > I think we need to give the purely stateless operation mode a try. This > is a 4.0 project though, no messing with the codebase until after the > 3.2 branch is made. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 31, 2002 1:54 PM > Subject: Re: [JBoss-dev] Interceptors for MBeans... TX interceptors > specifically > > > > Well, I'd like to work on it, like, now, since I need some parts of > this > to > > make xsl based deployments work better. > > > > I think it will be workable only for xmbeans or other model mbeans. > > > > Steps I forsee: > > > > 1. Make mbean interceptor stacks generated by other interceptor stack > > factory mbeans; interceptor instances generated by interceptor factory > > mbeans. There needs to be some boostrap interceptor stacks, perhaps > those > > for standard mbeans, to get this started. > > > > 2. xmbean descriptor specifies desired stack configuration via object > name > > of stack factory. > > > > 2.5?? implement a service lifecycle for mbean interceptors like the one > for > > ejb interceptors. > > > > 3. ejb interceptors are converted to be mbean interceptors. I think > this > > mostly involves including a home/remote flag on the invocation. This > might > > be useful on arbitrary mbean method calls also-- home calls being > handled > > by interceptors for the most part. > > > > 4. Answer the question of whether interceptors should have state as > they > do > > at present or be statelesss with all state info (including the > interceptor > > sequence) only in the invocation. > > > > 5. convert service lifecycle management to be done by specialized > > interceptors. > > > > Both interceptor models we have now answer (4) by having state in the > > interceptor. Maybe its time to try the other way. I propose having a > > "stack context" HashMap held in the head of the stack that the > interceptors > > can add stack-specific state to, keyed by themselves. > > > > david jencks > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
