|But isn't the state that the security interceptor uses really meta-data
|about the container? Shouldn't the interceptors get all meta-data from
afaik yes, and getting that information from the invocation pointers to the
container (container here as a repository of metadata) is a way to go.
marc fleury wrote:
h you have been pushing this RDF thingy for the past months, if it does
indeed allow for a one file admin, it might be worth it. Right now we are
going exactly the opposite way with the full file split across many little
files, possibly in sars... interesting
Well,
When we talk about 'stateless' interceptors, do we really mean
stateless, or do we merely mean stateless with regard to bean instance
and client?
-danch
Scott M Stark wrote:
Any of the interceptors can be made stateless, its a question of the cost
of reassociating the state from the
danch wrote:
When we talk about 'stateless' interceptors, do we really mean
stateless, or do we merely mean stateless with regard to bean instance
and client?
Bean instance, container, and client. Yes. It may only hold state that
is relevant for the particular work it is doing, such how
|When we talk about 'stateless' interceptors, do we really mean
|stateless, or do we merely mean stateless with regard to bean instance
|and client?
bean instance and client
marcf
|-danch
|
|Scott M Stark wrote:
|
| Any of the interceptors can be made stateless, its a question of the cost
| of
|Bean instance, container, and client. Yes. It may only hold state that
|is relevant for the particular work it is doing, such how to do it. For
|example, an invocation monitor sending messages to JMS might have an
|instance variable with the name of the topic to send messages to. That
|name is
They are talking stateless with regard to any container instance.
- Original Message -
From: danch [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 7:07 AM
Subject: Re: [JBoss-dev] Invocation and MethodInvocation
When
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists.
Sourceforge. Net [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 6:59 AM
Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|But isn't the state
at this time.
david jencks
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists.
Sourceforge. Net [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 6:59 AM
Subject: RE: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote:
Whether you put the state in the interceptor instance or the head of the
chain, you need the same state info.
If you put it in the head of the chain, you either have to put instance
variables specific to the interceptors that will be in the chain if you
want any
- Original Message -
From: Rickard Öberg [EMAIL PROTECTED]
To: Jboss-Development @ Lists . Sourceforge . Net
[EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 8:55 AM
Subject: Re: [JBoss-dev] Invocation and MethodInvocation
The only feature the stateless approach gets not easily
On 2001.11.15 11:55:18 -0500 Rickard Öberg wrote:
David Jencks wrote:
Whether you put the state in the interceptor instance or the head of
the
chain, you need the same state info.
If you put it in the head of the chain, you either have to put instance
variables specific to the
Scott M Stark wrote:
This is the crux of this issue. Some interceptors are stateful and are tied
to the type of container they are being used with. The EJB security
model is completely different than the Web security model. All the security
related interceptors due is translate from the
|Seems logical to put the MBeanInfo object of the container in the thingy
|that gets passed on. The interceptors can the extract whatever metadata
|about the container they want from that.
yes, I agree.
|Also, a stateless interceptor can be used for any container. If you want
well that would
David Jencks wrote:
If you pass the head of the chain with every invocation call, obviously the
interceptor can extract whatever metadata it needs, compute whatever
derived info is necessary, and use it. But if these computations take on
the order of seconds, which is definitely a
|Its fine to support sharing of stateless interceptors, but to say this is
|the only
|way interceptors should be handled forces a refactoring of exising usage
|without sufficient justification.
Neither Rickard nor I are saying this.
We are saying, gosh, most interceptors are generic (including
marc fleury wrote:
I was planning on putting a reference to the container ie. the repository
of chain configuration, IN the invocation itself. You then have a self
describing invocation. The rugged interceptor can then come and say
alright little fella, give me the tx tag you want big
snip
I think that an application such as a rule engine dynamically scripting
the
flow of invocation *graphically* where you can see your flow, will be a
proof, but we really are far from that at this point. (Oh yeah? how far?)
OK, this is the one capability the one interceptor approach has
wowowo,
I realize I forgot to say what this is good for :)
you can now attach ANY PAYLOAD to an invocation, not just the stuff
generated at the client, so that you can pass information down the chain,
have interceptors talking to each other and pass arbitrary data around the
JMX base, VERY VERY
|Although I originally thought including an mbean-iterator in the method
|invocation, as you have done, was the way to go, after discussion with
|Scott and some experiments I changed my mind to think an approach using
|interceptor factories and interceptor chain factories (both mbeans) is a
PM
|To: David Jencks; [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
||Although I originally thought including an mbean-iterator in the method
||invocation, as you have done, was the way to go, after discussion with
||Scott and some experiments I changed my mind
Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 11:44 AM
To: marc fleury; Jboss-Development@Lists. Sourceforge. Net
Subject: RE: [JBoss-dev] Invocation and MethodInvocation
wowowo,
I realize I forgot to say what this is good for :)
you can
|-Original Message-
|From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 14, 2001 4:13 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
|This is great.
|
|This is what I wanted to do
23 matches
Mail list logo
