RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

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 VERY useful for your custom advanced interceptors.

(was it the motorola kids in the Las Vegas training that mentioned they
needed this?)

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Wednesday, November 14, 2001 12:08 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: [JBoss-dev] Invocation and MethodInvocation
|
|
|Ok,
|
|[FOR RECORD, ARCH CHANGE]
|
|we discussed some time ago the possible extension of the "MethodInvocation"
|to be a more generic and powerful entity.
|
|Basically I have added the invocation directory and the Invocation.java, as
|well as changed the MethodInvocation.
|
|The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
|entity that travels inside our JMX bus is the "Invocation" that I just
|introduced.  The invocation basically takes the transaction and security
|information as its basis.  You are always doing stuff as part of
|transaction
|context (maybe empty meaning no transaction) and as someone authenticated
|(if you set it up) but these are the building blocks.  Then everything else
|is in a "payload" of possibly serialized byte[] data that we can carry
|around as such (avoiding cl madness).  We extend this for the
|methodinvocation which is more EJB'ish in that it knows about the
|EnterpriseContext (more on that later).
|
|The other new thing in there is the presence of the mbean list of objects
|this Invocation is supposed to go through.  It will identify the MBean
|interface of the Container for the EJBs, thereby really finalizing the
|detaching of the invokers from the invocation, both from the bus (which is
|already done) and the rmi impl (to be done next).
|
|The Invocation is not using the mbean list as yet, but possibly will, since
|what would come next is a self standing "invocation" in our JMX base, going
|through the bus from mbean to mbean, which would really give us a possibly
|dynamic way of maintaining the path that our invocation takes in the base.
|The stuff is there, will use a little bit to hook up the EJB container, we
|will see.
|
|I will also probably don't externalize the interceptors as yet, no good
|reason except it would be less disruptive a view from what we have now and
|it would be lindfors recommendation.
|
|I was going to talk about the "EnterpriseContext" thing but this is already
|a long mail. I will do so in a forthcoming email.
|
|Finally I will say that for legacy reasons I have kept the old constructors
|and allowed the Invocation to carry no MBean association.  The 2 legacy are
|1- the invocation chain is not fully generic yet, it knows the target, this
|is detached already (going JMX bus) but will move next 2- the CMR
|stuff from
|Dain that uses the invocation chain to invoke stuff on itself, this assumes
|that you know the container (which it does) and calls it directly (which it
|does) withouth the intermission of the JMX bus (which is ok), so this is
|likely to remain as is for now. Moving it to the bus would be trivial but
|not a priority right now.
|
|The testsuite testbean runs fine afaict, so this should not disrupt the
|existing RH codebase, fully backward compatible (again afaict)
|
|just warming up
|
|marcf
|
|Marc Fleury
|President
|JBoss Group, LLC
|
|
|
|___
|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

Re: [JBoss-dev] Invocation and MethodInvocation

[David Jencks]

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
better idea.  

There are 2 problems I know of with the mbean-iterator approach.
1. It requires the interceptors to be stateless.  All state info has to be
carried in the invocation object.  Any setup information the interceptor
may need has to be stored in the head-of-the-chain object and sent with
each MI.  IMHO this is _really_ not where this info belongs.  The head
should not need to know or store the interceptor-specific state info for
its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack. 
In particular, this conflicts directly with the security proxy interceptor.

2. (possibly an implementation issue, but real at the moment).  Calling
mbeanserver.invoke is _wa_ slower than a direct method call.  On my
machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
will be a significant performance problem.

There is one possible advantage:
1. The Invocation might be able to recompute its mbean-list on the fly. 
However, I'm less than convinced that supporting this is a good idea.  I
think if someone tried to use it they would just get confused for no good
reason.


The interceptor chain methodology I cureently think will work best involves
2 mbeans:

Interceptor factories:

takes Interceptor class name as an attribute, has an mbean method
newInterceptor returning a copy of the Interceptor.

This is a dynamic mbean, it could be made to expose the get/set properties
of the interceptor as attributes in the InterceptorFactory mbean.

InterceptorChainFactory:
takes an mbean-ref-list of the mbeans you want in the chain.  Has a
newInterceptorChain method taking the head and tail of the chain as
parameters, returns a new chain with the interceptors specified in the
list.  Calls init(head) on each interceptor. (the head is an object that is
assumed to contain the info needed for initialization, such as the info for
the SecurityProxy setup.)  The supplied tail is setup as the last element.

I have this much written.

I have been wondering how to fit this into the ContainerFactory: I think
one approach might be to make the Containers into MBeans that can be
configured as any other mbeans in a service-xml file, and include an
mbean-ref to the InterceptorChainFactory needed.  The ContainerFactory
could have mbean-refs to the default chains for each type of bean.  I
haven't looked into this extensively yet.

Thanks
david jencks

On 2001.11.14 12:08:00 -0500 marc fleury wrote:
> Ok,
> 
> [FOR RECORD, ARCH CHANGE]
> 
> we discussed some time ago the possible extension of the
> "MethodInvocation"
> to be a more generic and powerful entity.
> 
> Basically I have added the invocation directory and the Invocation.java,
> as
> well as changed the MethodInvocation.
> 
> The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
> entity that travels inside our JMX bus is the "Invocation" that I just
> introduced.  The invocation basically takes the transaction and security
> information as its basis.  You are always doing stuff as part of
> transaction
> context (maybe empty meaning no transaction) and as someone authenticated
> (if you set it up) but these are the building blocks.  Then everything
> else
> is in a "payload" of possibly serialized byte[] data that we can carry
> around as such (avoiding cl madness).  We extend this for the
> methodinvocation which is more EJB'ish in that it knows about the
> EnterpriseContext (more on that later).
> 
> The other new thing in there is the presence of the mbean list of objects
> this Invocation is supposed to go through.  It will identify the MBean
> interface of the Container for the EJBs, thereby really finalizing the
> detaching of the invokers from the invocation, both from the bus (which
> is
> already done) and the rmi impl (to be done next).
> 
> The Invocation is not using the mbean list as yet, but possibly will,
> since
> what would come next is a self standing "invocation" in our JMX base,
> going
> through the bus from mbean to mbean, which would really give us a
> possibly
> dynamic way of maintaining the path that our invocation takes in the
> base.
> The stuff is there, will use a little bit to hook up the EJB container,
> we
> will see.
> 
> I will also probably don't externalize the interceptors as yet, no good
> reason except it would be less disruptive a view from what we have now
> and
> it would be lindfors recommendation.
> 
> I was going to talk about the "EnterpriseContext" thing but this is
> already
> a long mail. I will do so in a forthcoming email.
> 
> Finally I will say that for legacy reasons I have kept the old
> constructors
> and allowed the Invocation to carry no MBean association.  The 2 legacy
> are
> 1- the

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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
|better idea.

The mbean is there to identify the target MBean for now.  Whether or not we
go to the "fully stateless" design might be down the road.

Reread my email, for now (today's todo) it is going to point to the
container. The String[] could be a String (no []) this is how I am going to
use it this afternoon with the detaching of the connector (see if it works
well).

|There are 2 problems I know of with the mbean-iterator approach.
|1. It requires the interceptors to be stateless.  All state info has to be
|carried in the invocation object.  Any setup information the interceptor

You are mixing 2 issues, one is making the chain of interceptors fully
stateless (which they are afaict I still have to see the example you are
refering to).  The other is list of mbeans you go through, since the
interceptors AREN'T MBEANS yet, we would have to make that first wouldn't
we?

|may need has to be stored in the head-of-the-chain object and sent with
|each MI.  IMHO this is _really_ not where this info belongs.  The head

??? the invocation is the only one that uses the information.

|should not need to know or store the interceptor-specific state info for
|its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack.
|In particular, this conflicts directly with the security proxy interceptor.
|
|2. (possibly an implementation issue, but real at the moment).  Calling
|mbeanserver.invoke is _wa_ slower than a direct method call.  On my
|machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
|will be a significant performance problem.

are you benching dynamic mbeans or standard mbeans? the dynamic mbean *is* a
direct method call (plus a lookup in a map, big deal).  The standard mbean
is a reflection call which is slow but we aren't using that as the bus.

|The interceptor chain methodology I cureently think will work best involves
|2 mbeans:

We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking about a list
of MBeans. right now the only mbean is the container that was added by Scott
and I wired the other day...

|Interceptor factories:
|
|takes Interceptor class name as an attribute, has an mbean method
|newInterceptor returning a copy of the Interceptor.
|
|This is a dynamic mbean, it could be made to expose the get/set properties
|of the interceptor as attributes in the InterceptorFactory mbean.
|
|InterceptorChainFactory:
|takes an mbean-ref-list of the mbeans you want in the chain.  Has a
|newInterceptorChain method taking the head and tail of the chain as
|parameters, returns a new chain with the interceptors specified in the
|list.  Calls init(head) on each interceptor. (the head is an object that is
|assumed to contain the info needed for initialization, such as the info for
|the SecurityProxy setup.)  The supplied tail is setup as the last element.
|
|I have this much written.
|
|I have been wondering how to fit this into the ContainerFactory: I think
|one approach might be to make the Containers into MBeans that can be
|configured as any other mbeans in a service-xml file, and include an

I prefer the lindfors/oberg approach to this with model mbeans.  The beans
will probably point to an ejb that has a persistence engine that reads xml
files like the ones we have.  With that you have clustered mbean
configurations.

I am going back to my linux box, over and out, will read stuff
tomorrow/tonight, give me some time with this, we will deal with the
interceptor chain when we really need to... down the road, one step at a
time, professor, one step at a time.

marcf

|mbean-ref to the InterceptorChainFactory needed.  The ContainerFactory
|could have mbean-refs to the default chains for each type of bean.  I
|haven't looked into this extensively yet.
|
|Thanks
|david jencks
|
|On 2001.11.14 12:08:00 -0500 marc fleury wrote:
|> Ok,
|>
|> [FOR RECORD, ARCH CHANGE]
|>
|> we discussed some time ago the possible extension of the
|> "MethodInvocation"
|> to be a more generic and powerful entity.
|>
|> Basically I have added the invocation directory and the Invocation.java,
|> as
|> well as changed the MethodInvocation.
|>
|> The 10,000 ft is that the new RH JMX view puts the mbeans in front.  The
|> entity that travels inside our JMX bus is the "Invocation" that I just
|> introduced.  The invocation basically takes the transaction and security
|> information as its basis.  You are always doing stuff as part of
|> transaction
|> context (maybe empty meaning no transaction) and as someone authenticated
|> (if you set it up) but these are the building blocks.  Then everything
|> else
|> is in a "payload" of possibly serialized byte[] data that we can carry
|> around as such (avoiding cl 

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

actually scratch all this discussion,

I think I have a better idea for the MI/Invocation

I will keep the payload and just put different "readers" on it, the basic
one will be the Invocation, the extended one will be the MI but essentially
we can create a MI and set the "payload" from the incoming invocation and
then read a "typed" invocation (ejb in this case) only when we reach the
valid stacks, this allows for something truly powerful: byte[] messages
until we reach the stack that knows how to read them, but the fact that they
are serialized or not is transparent to the MI, which is truly not the case
...

the basic "invocation" is thus the payload, the readers are just typed
conveniences in the stacks.

Will make sense when I commit this.



|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Wednesday, November 14, 2001 1:54 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 to think an approach using
||interceptor factories and interceptor chain factories (both mbeans) is a
||better idea.
|
|The mbean is there to identify the target MBean for now.  Whether or not we
|go to the "fully stateless" design might be down the road.
|
|Reread my email, for now (today's todo) it is going to point to the
|container. The String[] could be a String (no []) this is how I am going to
|use it this afternoon with the detaching of the connector (see if it works
|well).
|
||There are 2 problems I know of with the mbean-iterator approach.
||1. It requires the interceptors to be stateless.  All state info has to be
||carried in the invocation object.  Any setup information the interceptor
|
|You are mixing 2 issues, one is making the chain of interceptors fully
|stateless (which they are afaict I still have to see the example you are
|refering to).  The other is list of mbeans you go through, since the
|interceptors AREN'T MBEANS yet, we would have to make that first wouldn't
|we?
|
||may need has to be stored in the head-of-the-chain object and sent with
||each MI.  IMHO this is _really_ not where this info belongs.  The head
|
|??? the invocation is the only one that uses the information.
|
||should not need to know or store the interceptor-specific state info for
||its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack.
||In particular, this conflicts directly with the security proxy
|interceptor.
||
||2. (possibly an implementation issue, but real at the moment).  Calling
||mbeanserver.invoke is _wa_ slower than a direct method call.  On my
||machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
||will be a significant performance problem.
|
|are you benching dynamic mbeans or standard mbeans? the dynamic
|mbean *is* a
|direct method call (plus a lookup in a map, big deal).  The standard mbean
|is a reflection call which is slow but we aren't using that as the bus.
|
||The interceptor chain methodology I cureently think will work
|best involves
||2 mbeans:
|
|We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking
|about a list
|of MBeans. right now the only mbean is the container that was
|added by Scott
|and I wired the other day...
|
||Interceptor factories:
||
||takes Interceptor class name as an attribute, has an mbean method
||newInterceptor returning a copy of the Interceptor.
||
||This is a dynamic mbean, it could be made to expose the get/set properties
||of the interceptor as attributes in the InterceptorFactory mbean.
||
||InterceptorChainFactory:
||takes an mbean-ref-list of the mbeans you want in the chain.  Has a
||newInterceptorChain method taking the head and tail of the chain as
||parameters, returns a new chain with the interceptors specified in the
||list.  Calls init(head) on each interceptor. (the head is an
|object that is
||assumed to contain the info needed for initialization, such as
|the info for
||the SecurityProxy setup.)  The supplied tail is setup as the last element.
||
||I have this much written.
||
||I have been wondering how to fit this into the ContainerFactory: I think
||one approach might be to make the Containers into MBeans that can be
||configured as any other mbeans in a service-xml file, and include an
|
|I prefer the lindfors/oberg approach to this with model mbeans.  The beans
|will probably point to an ejb that has a persistence engine that reads xml
|files like the ones we have.  With that you have clustered mbean
|configurations.
|
|I am going back to my linux box, over and out, will read stuff
|tomorrow/tonight, give me some time with this, we will deal with the
|interceptor chain when we really need to... down the road, one step at

RE: [JBoss-dev] Invocation and MethodInvocation

[Dain Sundstrom]

This is great.

This is what I wanted to do when I wrote my "message" passing hack.  I think
one problem is the current interceptors will be expecting a Method object,
so when they are changed to handle an Invocation with out a Method object, I
will definitely switch over.

-dain

> -Original 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 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 VERY useful for your custom advanced interceptors.
> 
> (was it the motorola kids in the Las Vegas training that 
> mentioned they
> needed this?)
> 
> marcf
> 
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On 
> Behalf Of marc
> |fleury
> |Sent: Wednesday, November 14, 2001 12:08 PM
> |To: Jboss-Development@Lists. Sourceforge. Net
> |Subject: [JBoss-dev] Invocation and MethodInvocation
> |
> |
> |Ok,
> |
> |[FOR RECORD, ARCH CHANGE]
> |
> |we discussed some time ago the possible extension of the 
> "MethodInvocation"
> |to be a more generic and powerful entity.
> |
> |Basically I have added the invocation directory and the 
> Invocation.java, as
> |well as changed the MethodInvocation.
> |
> |The 10,000 ft is that the new RH JMX view puts the mbeans in 
> front.  The
> |entity that travels inside our JMX bus is the "Invocation" 
> that I just
> |introduced.  The invocation basically takes the transaction 
> and security
> |information as its basis.  You are always doing stuff as part of
> |transaction
> |context (maybe empty meaning no transaction) and as someone 
> authenticated
> |(if you set it up) but these are the building blocks.  Then 
> everything else
> |is in a "payload" of possibly serialized byte[] data that we 
> can carry
> |around as such (avoiding cl madness).  We extend this for the
> |methodinvocation which is more EJB'ish in that it knows about the
> |EnterpriseContext (more on that later).
> |
> |The other new thing in there is the presence of the mbean 
> list of objects
> |this Invocation is supposed to go through.  It will identify 
> the MBean
> |interface of the Container for the EJBs, thereby really 
> finalizing the
> |detaching of the invokers from the invocation, both from the 
> bus (which is
> |already done) and the rmi impl (to be done next).
> |
> |The Invocation is not using the mbean list as yet, but 
> possibly will, since
> |what would come next is a self standing "invocation" in our 
> JMX base, going
> |through the bus from mbean to mbean, which would really give 
> us a possibly
> |dynamic way of maintaining the path that our invocation 
> takes in the base.
> |The stuff is there, will use a little bit to hook up the EJB 
> container, we
> |will see.
> |
> |I will also probably don't externalize the interceptors as 
> yet, no good
> |reason except it would be less disruptive a view from what 
> we have now and
> |it would be lindfors recommendation.
> |
> |I was going to talk about the "EnterpriseContext" thing but 
> this is already
> |a long mail. I will do so in a forthcoming email.
> |
> |Finally I will say that for legacy reasons I have kept the 
> old constructors
> |and allowed the Invocation to carry no MBean association.  
> The 2 legacy are
> |1- the invocation chain is not fully generic yet, it knows 
> the target, this
> |is detached already (going JMX bus) but will move next 2- the CMR
> |stuff from
> |Dain that uses the invocation chain to invoke stuff on 
> itself, this assumes
> |that you know the container (which it does) and calls it 
> directly (which it
> |does) withouth the intermission of the JMX bus (which is 
> ok), so this is
> |likely to remain as is for now. Moving it to the bus would 
> be trivial but
> |not a priority right now.
> |
> |The testsuite testbean runs fine afaict, so this should not 
> disrupt the
> |existing RH codebase, fully backward compatible (again afaict)
> |
> |just warming up
> |
> |marcf
> |
> |Marc Fleury
> |President
> |JBoss Group, LLC
> |
> |
> |
> |___
> |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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|-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 when I wrote my "message" passing
|hack.  I think
|one problem is the current interceptors will be expecting a Method object,
|so when they are changed to handle an Invocation with out a Method
|object, I
|will definitely switch over.

it is already done, the new "MI" walking down supports the addvalue and
getvalue... go ahead use it!

marcf

|
|-dain
|
|> -Original 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 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 VERY useful for your custom advanced interceptors.
|>
|> (was it the motorola kids in the Las Vegas training that
|> mentioned they
|> needed this?)
|>
|> marcf
|>
|> |-Original Message-
|> |From: [EMAIL PROTECTED]
|> |[mailto:[EMAIL PROTECTED]]On
|> Behalf Of marc
|> |fleury
|> |Sent: Wednesday, November 14, 2001 12:08 PM
|> |To: Jboss-Development@Lists. Sourceforge. Net
|> |Subject: [JBoss-dev] Invocation and MethodInvocation
|> |
|> |
|> |Ok,
|> |
|> |[FOR RECORD, ARCH CHANGE]
|> |
|> |we discussed some time ago the possible extension of the
|> "MethodInvocation"
|> |to be a more generic and powerful entity.
|> |
|> |Basically I have added the invocation directory and the
|> Invocation.java, as
|> |well as changed the MethodInvocation.
|> |
|> |The 10,000 ft is that the new RH JMX view puts the mbeans in
|> front.  The
|> |entity that travels inside our JMX bus is the "Invocation"
|> that I just
|> |introduced.  The invocation basically takes the transaction
|> and security
|> |information as its basis.  You are always doing stuff as part of
|> |transaction
|> |context (maybe empty meaning no transaction) and as someone
|> authenticated
|> |(if you set it up) but these are the building blocks.  Then
|> everything else
|> |is in a "payload" of possibly serialized byte[] data that we
|> can carry
|> |around as such (avoiding cl madness).  We extend this for the
|> |methodinvocation which is more EJB'ish in that it knows about the
|> |EnterpriseContext (more on that later).
|> |
|> |The other new thing in there is the presence of the mbean
|> list of objects
|> |this Invocation is supposed to go through.  It will identify
|> the MBean
|> |interface of the Container for the EJBs, thereby really
|> finalizing the
|> |detaching of the invokers from the invocation, both from the
|> bus (which is
|> |already done) and the rmi impl (to be done next).
|> |
|> |The Invocation is not using the mbean list as yet, but
|> possibly will, since
|> |what would come next is a self standing "invocation" in our
|> JMX base, going
|> |through the bus from mbean to mbean, which would really give
|> us a possibly
|> |dynamic way of maintaining the path that our invocation
|> takes in the base.
|> |The stuff is there, will use a little bit to hook up the EJB
|> container, we
|> |will see.
|> |
|> |I will also probably don't externalize the interceptors as
|> yet, no good
|> |reason except it would be less disruptive a view from what
|> we have now and
|> |it would be lindfors recommendation.
|> |
|> |I was going to talk about the "EnterpriseContext" thing but
|> this is already
|> |a long mail. I will do so in a forthcoming email.
|> |
|> |Finally I will say that for legacy reasons I have kept the
|> old constructors
|> |and allowed the Invocation to carry no MBean association.
|> The 2 legacy are
|> |1- the invocation chain is not fully generic yet, it knows
|> the target, this
|> |is detached already (going JMX bus) but will move next 2- the CMR
|> |stuff from
|> |Dain that uses the invocation chain to invoke stuff on
|> itself, this assumes
|> |that you know the container (which it does) and calls it
|> directly (which it
|> |does) withouth the intermission of the JMX bus (which is
|> ok), so this is
|> |likely to remain as is for now. Moving it to the bus would
|> be trivial but
|>

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Öberg]

marc fleury wrote:

> |should not need to know or store the interceptor-specific state info for
> |its chain.  IMHO using a catch-all (or cache-all) map is a bit of a hack.
> |In particular, this conflicts directly with the security proxy interceptor.


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 
the *container*? If that is done, you'd get very clean separation of 
concerns, where the interceptor act upon the meta-data, but is not 
responsible for the actual meta-data. To me that seems more natural.

So, the point isn't that the security interceptors should be stateless. 
In fact, they may very well be stateful. However, they should not have 
state *particular to any one container* (compare with Stateless Session 
Beans).


> |2. (possibly an implementation issue, but real at the moment).  Calling
> |mbeanserver.invoke is _wa_ slower than a direct method call.  On my
> |machine, 100,000 iterations in 10 sec compared with 0 sec.  I think this
> |will be a significant performance problem.
> 
> are you benching dynamic mbeans or standard mbeans? the dynamic mbean *is* a
> direct method call (plus a lookup in a map, big deal).  The standard mbean
> is a reflection call which is slow but we aren't using that as the bus.


Very Important Point.


> I prefer the lindfors/oberg approach to this with model mbeans.  The beans
> will probably point to an ejb that has a persistence engine that reads xml
> files like the ones we have.  With that you have clustered mbean
> configurations.


Also, the Model MBeans would be responsible for reading the meta-data 
from XML, which would then be provided through the standard methods 
(getMBeanInfo) to the interceptors. This allows the interceptor/state 
decoupling mentioned above. If the meta-data moves to RDF with 
namespaces you could also have multiple aspects of a container in *one* 
XML file (I'm not sure why people haven't done this already).

To me the only reason to use multiple XML files is that namespaces 
aren't used. If namespaces were introduced it should be trivial to merge 
them all into one (ejb-jar.xml).


> I am going back to my linux box, over and out, will read stuff
> tomorrow/tonight, give me some time with this, we will deal with the
> interceptor chain when we really need to... down the road, one step at a
> time, professor, one step at a time.


Do take time to look into Aspect Oriented Programming if you have time. 
Volume 44/Issue 10 of Communications of the ACM 
(http://portal.acm.org/toc.cfm?id=383845&type=issue&coll=portal&dl=ACM&idx=J79&part=magazine&WantType=Magazines&title=CACM)
 
have lots of great articles on the subject, and there are lots of 
parallels with how JBoss works already.

/Rickard
-- 
Rickard Öberg


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[Scott M Stark]

Any of the interceptors can be made stateless, its a question of the cost
of reassociating the state from the container meta-data and having to
cast from an opaque generic form to the data required by the interceptor.
The current state in the security interceptors is just cached data derived
from the container meta-data. In the case of the SecurityProxyInterceptor
the derived data can be an expensive transformation of the container
meta-data.
>
> > |should not need to know or store the interceptor-specific state info
for
> > |its chain.  IMHO using a catch-all (or cache-all) map is a bit of a
hack.
> > |In particular, this conflicts directly with the security proxy
interceptor.
>
>
> 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
> the *container*? If that is done, you'd get very clean separation of
> concerns, where the interceptor act upon the meta-data, but is not
> responsible for the actual meta-data. To me that seems more natural.
>
> So, the point isn't that the security interceptors should be stateless.
> In fact, they may very well be stateful. However, they should not have
> state *particular to any one container* (compare with Stateless Session
> Beans).
>



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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.

|the *container*? If that is done, you'd get very clean separation of
|concerns, where the interceptor act upon the meta-data, but is not
|responsible for the actual meta-data. To me that seems more natural.

yes, I agree.

|So, the point isn't that the security interceptors should be stateless.
|In fact, they may very well be stateful. However, they should not have
|state *particular to any one container* (compare with Stateless Session
|Beans).

Following Turin, the state here is really context of the state machine,
there is no context that stays with the machine once the invocation is gone
through.  If there is, it is in "cache" (think EJB) not in the interceptors.

|Also, the Model MBeans would be responsible for reading the meta-data
|from XML, which would then be provided through the standard methods
|(getMBeanInfo) to the interceptors. This allows the interceptor/state
|decoupling mentioned above. If the meta-data moves to RDF with
|namespaces you could also have multiple aspects of a container in *one*
|XML file (I'm not sure why people haven't done this already).
|
|To me the only reason to use multiple XML files is that namespaces
|aren't used. If namespaces were introduced it should be trivial to merge
|them all into one (ejb-jar.xml).

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

|Do take time to look into Aspect Oriented Programming if you have time.
|Volume 44/Issue 10 of Communications of the ACM
|(http://portal.acm.org/toc.cfm?id=383845&type=issue&coll=portal&dl=
|ACM&idx=J79&part=magazine&WantType=Magazines&title=CACM)
|have lots of great articles on the subject, and there are lots of
|parallels with how JBoss works already.

Yes, Aspect programming is the compilation heavy approach by PARC to
"meta-programming".  If you read this carefully you see that scripting is
probably the middle ground between compilation heavy PARC and XML light EJB.
Research but there is really no reason why intercepting mbeans wouldn't be
close to it.

marcf


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Öberg]

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, namespaces can be used with or without RDF. It's just a very nice 
way to get multiple aspects of a particular element into one XML file 
without element name clashes. Simple too.


> |Do take time to look into Aspect Oriented Programming if you have time.
> |Volume 44/Issue 10 of Communications of the ACM
> |(http://portal.acm.org/toc.cfm?id=383845&type=issue&coll=portal&dl=
> |ACM&idx=J79&part=magazine&WantType=Magazines&title=CACM)
> |have lots of great articles on the subject, and there are lots of
> |parallels with how JBoss works already.
> 
> Yes, Aspect programming is the compilation heavy approach by PARC to
> "meta-programming".  


To be precise, AspectJ is the compilation heavy approach. Aspect 
Oriented Programmin in general is more of a philosophy that can be 
implemented in numerous ways, the interceptor architecture of JBoss 
being one of them. The interceptors in JBoss fit really well with the 
notion of aspects in AOP.

> If you read this carefully you see that scripting is
> probably the middle ground between compilation heavy PARC and XML light EJB.
> Research but there is really no reason why intercepting mbeans wouldn't be
> close to it.

Yes, scripting will make it easier to insert aspect join points. Good 
point. To me it seems like AspectJ has this scripting aspect to it, 
although it uses pre-runtime compilation to get it into bytecode.

/Rickard

-- 
Rickard Öberg


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[danch]

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 container meta-data and having to
> cast from an opaque generic form to the data required by the interceptor.
> The current state in the security interceptors is just cached data derived
> from the container meta-data. In the case of the SecurityProxyInterceptor
> the derived data can be an expensive transformation of the container
> meta-data.
> 
>>>|should not need to know or store the interceptor-specific state info
>>>
> for
> 
>>>|its chain.  IMHO using a catch-all (or cache-all) map is a bit of a
>>>
> hack.
> 
>>>|In particular, this conflicts directly with the security proxy
>>>
> interceptor.
> 
>>
>>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
>>the *container*? If that is done, you'd get very clean separation of
>>concerns, where the interceptor act upon the meta-data, but is not
>>responsible for the actual meta-data. To me that seems more natural.
>>
>>So, the point isn't that the security interceptors should be stateless.
>>In fact, they may very well be stateful. However, they should not have
>>state *particular to any one container* (compare with Stateless Session
>>Beans).
>>
>>
> 
> 
> 
> ___
> 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

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Öberg]

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 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 not client specific, it is not instance specific, and it is not 
container specific, but it is nevertheless state.

/Rickard

-- 
Rickard Öberg


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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 reassociating the state from the container meta-data and having to
|> cast from an opaque generic form to the data required by the interceptor.
|> The current state in the security interceptors is just cached
|data derived
|> from the container meta-data. In the case of the SecurityProxyInterceptor
|> the derived data can be an expensive transformation of the container
|> meta-data.
|>
|>>>|should not need to know or store the interceptor-specific state info
|>>>
|> for
|>
|>>>|its chain.  IMHO using a catch-all (or cache-all) map is a bit of a
|>>>
|> hack.
|>
|>>>|In particular, this conflicts directly with the security proxy
|>>>
|> interceptor.
|>
|>>
|>>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
|>>the *container*? If that is done, you'd get very clean separation of
|>>concerns, where the interceptor act upon the meta-data, but is not
|>>responsible for the actual meta-data. To me that seems more natural.
|>>
|>>So, the point isn't that the security interceptors should be stateless.
|>>In fact, they may very well be stateful. However, they should not have
|>>state *particular to any one container* (compare with Stateless Session
|>>Beans).
|>>
|>>
|>
|>
|>
|> ___
|> 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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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 not client specific, it is not instance specific, and it is not
|container specific, but it is nevertheless state.

And Turin calls them "state machines".

I would rather quote the genius that got it started than the "wallpaper
patterns" of the itzy bitzy weeny bozos of today

marcf



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[Scott M Stark]

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 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 container meta-data and having to
> > cast from an opaque generic form to the data required by the
interceptor.
> > The current state in the security interceptors is just cached data
derived
> > from the container meta-data. In the case of the
SecurityProxyInterceptor
> > the derived data can be an expensive transformation of the container
> > meta-data.
> >
> >>>|should not need to know or store the interceptor-specific state info
> >>>
> > for
> >
> >>>|its chain.  IMHO using a catch-all (or cache-all) map is a bit of a
> >>>
> > hack.
> >
> >>>|In particular, this conflicts directly with the security proxy
> >>>
> > interceptor.
> >
> >>
> >>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
> >>the *container*? If that is done, you'd get very clean separation of
> >>concerns, where the interceptor act upon the meta-data, but is not
> >>responsible for the actual meta-data. To me that seems more natural.
> >>
> >>So, the point isn't that the security interceptors should be stateless.
> >>In fact, they may very well be stateful. However, they should not have
> >>state *particular to any one container* (compare with Stateless Session
> >>Beans).
> >>
> >>
> >
> >
> >
> > ___
> > 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

Re: [JBoss-dev] Invocation and MethodInvocation

[Scott M Stark]

- 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 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.
>
> |the *container*? If that is done, you'd get very clean separation of
> |concerns, where the interceptor act upon the meta-data, but is not
> |responsible for the actual meta-data. To me that seems more natural.
>
> yes, I agree.
>
Really, what am I cleaning up by moving container derived data out of
the interceptors? The fact that the meta-data is in the container is simply
a matter of choice. The security meta-data is really an interceptor
property.
No where in the codebase is the EJBSecurityManager for the container used
but in the SecurityInterceptor and SecurityProxyInterceptor. The same is
true of the SecurityProxyInterceptor. The custom securityProxy at the
Container is also not used anywhere but in the SecurityProxyInterceptor and
its supporting classes.

By virtue of the fact that one can define interceptors per bean class we are
supporting interceptors that are tied to their container in interceptor
specific
ways. Users are writing interceptors that have their own state based on data
derived from container meta-data in an interceptor specific way, and the
container has no knowledge of this state.

> |So, the point isn't that the security interceptors should be stateless.
> |In fact, they may very well be stateful. However, they should not have
> |state *particular to any one container* (compare with Stateless Session
> |Beans).
>
> Following Turin, the state here is really context of the state machine,
> there is no context that stays with the machine once the invocation is
gone
> through.  If there is, it is in "cache" (think EJB) not in the
interceptors.
>
This is a restriction on the current view of the interceptors. You can argue
that interceptors must be stateless. This simply pushes each stateful
interceptor
to develop their own session cache management layer. What are we gaining
from this change in the interceptor model?



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[David Jencks]

On 2001.11.15 11:09:40 -0500 Scott M Stark wrote:
> 
I feel like its deja vu all over again.  About a month ago I had this same
conversation with Scott and concluded that having an instance of
interceptor for each chain is definitely the way to go.  Here are some
reasons:


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 compiler type checking help or use an untyped map and hope for the
best if you want it generic.

If you put the state info in the interceptor instance, you can have all the
compiler type checking you can stand, you keep the state info needed for
the interceptor encapsulated in the interceptor (where, I will say, it
belongs), and the interceptor becomes much more self contained.

I vote for instances of interceptors per chain.

The only feature the stateless approach gets not easily available with the
statefull approach is the ability to change which interceptors are called
during the chain traversal.  I don't see any use for this meta-meta
programming 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
> 
> 
> > |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.
> >
> > |the *container*? If that is done, you'd get very clean separation of
> > |concerns, where the interceptor act upon the meta-data, but is not
> > |responsible for the actual meta-data. To me that seems more natural.
> >
> > yes, I agree.
> >
> Really, what am I cleaning up by moving container derived data out of
> the interceptors? The fact that the meta-data is in the container is
> simply
> a matter of choice. The security meta-data is really an interceptor
> property.
> No where in the codebase is the EJBSecurityManager for the container used
> but in the SecurityInterceptor and SecurityProxyInterceptor. The same is
> true of the SecurityProxyInterceptor. The custom securityProxy at the
> Container is also not used anywhere but in the SecurityProxyInterceptor
> and
> its supporting classes.
> 
> By virtue of the fact that one can define interceptors per bean class we
> are
> supporting interceptors that are tied to their container in interceptor
> specific
> ways. Users are writing interceptors that have their own state based on
> data
> derived from container meta-data in an interceptor specific way, and the
> container has no knowledge of this state.
> 
> > |So, the point isn't that the security interceptors should be
> stateless.
> > |In fact, they may very well be stateful. However, they should not have
> > |state *particular to any one container* (compare with Stateless
> Session
> > |Beans).
> >
> > Following Turin, the state here is really context of the state machine,
> > there is no context that stays with the machine once the invocation is
> gone
> > through.  If there is, it is in "cache" (think EJB) not in the
> interceptors.
> >
> This is a restriction on the current view of the interceptors. You can
> argue
> that interceptors must be stateless. This simply pushes each stateful
> interceptor
> to develop their own session cache management layer. What are we gaining
> from this change in the interceptor model?
> 
> 
> 
> ___
> 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

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Öberg]

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 compiler type checking help or use an untyped map and hope for the
> best if you want it generic.


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.


> If you put the state info in the interceptor instance, you can have all the
> compiler type checking you can stand, you keep the state info needed for
> the interceptor encapsulated in the interceptor (where, I will say, it
> belongs), and the interceptor becomes much more self contained.


What if two interceptors are interested in the same metadata?

> The only feature the stateless approach gets not easily available with the
> statefull approach is the ability to change which interceptors are called
> during the chain traversal.  I don't see any use for this meta-meta
> programming at this time.


Also, a stateless interceptor can be used for any container. If you want 
to just have tx's, you'd go find a tx-interceptor, and put it in the 
invocation chain. The interceptor will extract the metadata it needs 
about the container using the MBeanInfo, and do its work.

If it is stateful, how will the interceptor get its metadata? I hope it 
won't load it itself... that would make it dependent on the type of 
object the interceptor chain is being used on (since it may be used on 
things that are not EJB containers).

/Rickard

-- 
Rickard Öberg


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[Scott M Stark]

- 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 available with
the
> > statefull approach is the ability to change which interceptors are
called
> > during the chain traversal.  I don't see any use for this meta-meta
> > programming at this time.
>
>
> Also, a stateless interceptor can be used for any container. If you want
> to just have tx's, you'd go find a tx-interceptor, and put it in the
> invocation chain. The interceptor will extract the metadata it needs
> about the container using the MBeanInfo, and do its work.
>
> If it is stateful, how will the interceptor get its metadata? I hope it
> won't load it itself... that would make it dependent on the type of
> object the interceptor chain is being used on (since it may be used on
> things that are not EJB containers).
>
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 container specific model to
the
generic JAAS implmentation in fact.

I can force a container independent model on the interceptors that show up
at the top-level, but internally, the security interceptor is going to have
to
determine how to enforce the container specific view.

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.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[David Jencks]

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 interceptors that will be in the chain if you
> > want any compiler type checking help or use an untyped map and hope for
> the
> > best if you want it generic.
> 
> 
> 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.

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 possibility and I think the
case with the security proxy interceptor [NOT the security interceptor]
(and the interceptor I have for rule engines), you need to precompute the
derived info and save it somewhere in an initialization step. No matter
which approach we use, this initialization step is necessary.  I am saying
that storing the results of the initialization in the interceptor makes
more sense than putting it in an untyped map in the head of the chain. 
Doing this systematically also means you don't need to pass the head of the
chain when you are traversing it with a method invocation.

> 
> 
> > If you put the state info in the interceptor instance, you can have all
> the
> > compiler type checking you can stand, you keep the state info needed
> for
> > the interceptor encapsulated in the interceptor (where, I will say, it
> > belongs), and the interceptor becomes much more self contained.
> 
> 
> What if two interceptors are interested in the same metadata?
They each store the info they are interested in.  If its the same as
another interceptor, who cares?
> 
> > The only feature the stateless approach gets not easily available with
> the
> > statefull approach is the ability to change which interceptors are
> called
> > during the chain traversal.  I don't see any use for this meta-meta
> > programming at this time.
> 
> 
> Also, a stateless interceptor can be used for any container. If you want 
> to just have tx's, you'd go find a tx-interceptor, and put it in the 
> invocation chain. The interceptor will extract the metadata it needs 
> about the container using the MBeanInfo, and do its work.


what I'm talking about can also be used for any container.  The metadata
extraction occurs during chain initialization.
> 
> If it is stateful, how will the interceptor get its metadata? I hope it 
> won't load it itself... that would make it dependent on the type of 
> object the interceptor chain is being used on (since it may be used on 
> things that are not EJB containers).


Lets set up an example


  org.jboss.ejb.TxInterceptor


  org.jboss.ejb.SecurityInterceptor


  
JB:service=TxInterceptor
JB:service=SecurityInterceptor
  


  JB:service=MyChain
  myEjb


when the mbeans are started up, the Container gets the metadata for the
ejb, asks the InterceptorChainFactory for an interceptor chain containing
new instances of the specified interceptors from the interceptor factories,
and initializes (starts) it by sending itself or the metadata down the
chain.  Each interceptor extracts whatever info it needs from the metadata
and saves it in the most convenient form in itself, in typed objects. 
Method invocations go down the chain, and the interceptor instances use
their specially calculated info to do their job.


Note that the InterceptorFactory mbeans can of course include additional
attributes to further specialize the instances they create.

david jencks

> 
> /Rickard
> 
> -- 
> Rickard Öberg
> 
> 
> 

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Oberg]

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 container specific model to
> the
> generic JAAS implmentation in fact.


That is beside the point. If I have an MBean *wanting* the EJB security 
model, I'd like to be able to invoke it using the EJB interceptor, 
without the interceptor complaining about it. It shouldn't care what the 
end destination is, as long as the container can provide the right 
meta-data.


> I can force a container independent model on the interceptors that show up
> at the top-level, but internally, the security interceptor is going to have
> to
> determine how to enforce the container specific view.
> 
> 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.

That is your opinion :-)

/Rickard

-- 
Rickard Öberg



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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 really be the point.  "Scripting the flow" in the aspect
sense becomes quite trivial and manageable.

|to just have tx's, you'd go find a tx-interceptor, and put it in the
|invocation chain. The interceptor will extract the metadata it needs
|about the container using the MBeanInfo, and do its work.

That is the beauty of it, also we can leverage the metadata talk of EJB to
add transactional demarcation to flows... any flow, any object, same tags,
as we agree there, just that is really powerful.  No additional work
whatsoever, aspect programming for the masses.

|If it is stateful, how will the interceptor get its metadata? I hope it
|won't load it itself... that would make it dependent on the type of
|object the interceptor chain is being used on (since it may be used on
|things that are not EJB containers).

sure, the EJB container would not be "real" except for a metadata repository
of MBeanInfo describing the context for the invocation pertaining to the EJB
kind.

David, as I said previously, I work by increment, step by step professor,
step by step.  Right now the design that Rickard did is the one that you are
defending.  i.e. the stack of interceptors per instance.  I am ok with that.
In my roadmap I actually don't intend to replace it so far.  So even though
we are advocating the more advanced view it would require more retooling,
and I am worried about the amount of work there.

I don't want to get all mighty on your asses since as I said I don't think I
will implement this in the near future.  But the vision of Turin's slave
machines is a powerful one, we are so close to implementing it in JBoss, and
everyone seems to be pushing this view almost without knowing, that
something in me says "do it"... apart from the elegance I think it would be
an extremelly flexible framework.  But again, too much for now.

Please drop it now, let's avoid "empty" discussions and focus on the task at
hand.

marcf


|
|/Rickard
|
|--
|Rickard Öberg
|
|
|___
|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

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Oberg]

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 possibility and I think the
> case with the security proxy interceptor [NOT the security interceptor]
> (and the interceptor I have for rule engines), you need to precompute the
> derived info and save it somewhere in an initialization step. No matter
> which approach we use, this initialization step is necessary.  I am saying
> that storing the results of the initialization in the interceptor makes
> more sense than putting it in an untyped map in the head of the chain. 
> Doing this systematically also means you don't need to pass the head of the
> chain when you are traversing it with a method invocation.


This seems to have more to do with caching than the decision on where to 
keep the data. AFAICT there's no problem with caching the data in the 
interceptor (although you'd have to do it in a hashtable, with the 
end-point MBean name as key), to allow such initialization work to be 
done. As long as you can always re-get the data from the MBean, and that 
the MBean is really *in charge of* the state.

Is the reason you want interceptors stateful only for performance?


>>>If you put the state info in the interceptor instance, you can have all
>>>
>>the
>>
>>>compiler type checking you can stand, you keep the state info needed
>>>
>>for
>>
>>>the interceptor encapsulated in the interceptor (where, I will say, it
>>>belongs), and the interceptor becomes much more self contained.
>>>
>>
>>What if two interceptors are interested in the same metadata?
>>
> They each store the info they are interested in.  If its the same as
> another interceptor, who cares?


Well, *how do they get that info*?? As above, if two interceptors 
*cache* the data that is fine, because then they're not *in charge of* 
the data from an architectural/design point of view. It is then 
inherently shareable. If the metadata belongs to any of the 
interceptors, then somewhere there needs to be knowledge about what 
interceptor needs what metadata so that they can be provided this. In 
the stateless model they are themselves responsible for accessing 
whatever they need from the container (or whatever the end-point is), 
thus encapsulating the knowledge of that need.


>>Also, a stateless interceptor can be used for any container. If you want 
>>to just have tx's, you'd go find a tx-interceptor, and put it in the 
>>invocation chain. The interceptor will extract the metadata it needs 
>>about the container using the MBeanInfo, and do its work.
>>
> 
> 
> what I'm talking about can also be used for any container.  The metadata
> extraction occurs during chain initialization.


What you mean is that during chain init a particular instance is being 
created for that chain. Right? What I'm saying is that interceptors 
exist independently of these chains, i.e. they may exist before any 
chains exist, it's just that without a chain they are never invoked. 
When the chains are created particular interceptors are chosen for that 
chain, and then used. Those interceptors may however be part of other 
chains acting concurrently.


>  name="JB:service=TxInterceptor">
>   org.jboss.ejb.TxInterceptor
> 
>  name="JB:service=SecurityInterceptor">
>   org.jboss.ejb.SecurityInterceptor
> 
>  name="JB:service=MyChain">
>   
> JB:service=TxInterceptor
> JB:service=SecurityInterceptor
>   
> 
> 
>   JB:service=MyChain
>   myEjb
> 



Excellent! Nothing like an example to clarify things.

Here's mine:
  
java:/MyTM
  

  MyCompanyRealm
  

  

  
  JB:service=TxInterceptor
  
  
  JB:service=SecurityInterceptor
  

  

  

  JB:service=MyChain

myEjb
  
--
The interceptors are MBeans, and thus configurable as MBeans. They can 
have state, just as the two above does, but can also be used by any 
container, and any chain.

IMHO this is more powerful, since the interceptors can be used with 
pretty much whatever MBean/endpoint. If they need info about the 
endpoint, such as the TxInterceptor wanting to know whether a particular 
method in the end-point has a particular tx setting, they just ask the 
MBeanInfo of it, which it will get from the invocation (or at least the 
end-point identifier should be in the invocation, which will allow one 
to deduce the MBeanInfo from that).

You think this is bad? Why? If it's the performance part: fine, cache it.

/Rickard

-- 
Rickard Öberg



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|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 the ones you
are describing, it would just mean that some come specific to the bean, big
deal, we don't preclude it), then let's factor them in a clean way we we can
talk to them independenly through the JMX bus and thus offer trivial
scripting of flows (you want to add transaction behaviour to an assembly,
you can).

There can be as many mbeans as there are security types. Even one per
container, it is irrelevant but at least that metadata would be dynamically
updatable (defeating one of the points rickard makes about "ejb").

Look for the umpth time, we are talking of code that won't materialize in
the next coming weeks.  I will go with the lindfors/oberg initial
description of the stack, which is just what we have with some more
flexibility in the loading of configurations.

Ineed   toturnoffthisemail station   :  -   )

marcf
|
|
|
|___
|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

RE: [JBoss-dev] Invocation and MethodInvocation

[marc fleury]

|This seems to have more to do with caching than the decision on where to
|keep the data. AFAICT there's no problem with caching the data in the
|interceptor (although you'd have to do it in a hashtable, with the
|end-point MBean name as key), to allow such initialization work to be
|done. As long as you can always re-get the data from the MBean, and that
|the MBean is really *in charge of* the state.
|
|Is the reason you want interceptors stateful only for performance?
|

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 schme! 2 links
instead of one, and no lookup in there.

perf is the same.

|the data from an architectural/design point of view. It is then
|inherently shareable. If the metadata belongs to any of the

yes

|interceptors, then somewhere there needs to be knowledge about what
|interceptor needs what metadata so that they can be provided this. In
|the stateless model they are themselves responsible for accessing
|whatever they need from the container (or whatever the end-point is),
|thus encapsulating the knowledge of that need.

yes, the "endpoint" thing is weak though (but it is what I have in the
current invoker, need to think of something better) I think we need a real
logical name of the "chain" as path.

Sygma(path) == chain <==>container

It is the path integral that defines the container.  Today I identify it
with the MBean name of the container built by Scott.  That container
encapsulates a hardcoded chain (in effect).

|What you mean is that during chain init a particular instance is being
|created for that chain. Right? What I'm saying is that interceptors
|exist independently of these chains, i.e. they may exist before any

precisely

|chains exist, it's just that without a chain they are never invoked.

yes, they are configured in the JMX base, independently of EJB existence or
any container for that matter.

|When the chains are created particular interceptors are chosen for that
|chain, and then used. Those interceptors may however be part of other
|chains acting concurrently.

correct.


|Here's mine:
|  
|java:/MyTM
|  

re: mail of yesterday, remove the "ejb" in that interceptor

|  MyCompanyRealm
|  
|
|  
|
|  
|  JB:service=TxInterceptor
|  
|  
|  JB:service=SecurityInterceptor
|  
|
|  
|
|  
|
|  JB:service=MyChain
|
|myEjb
|  
|--

|The interceptors are MBeans, and thus configurable as MBeans. They can
|have state, just as the two above does, but can also be used by any
|container, and any chain.

yes

|IMHO this is more powerful, since the interceptors can be used with
|pretty much whatever MBean/endpoint. If they need info about the
|endpoint, such as the TxInterceptor wanting to know whether a particular
|method in the end-point has a particular tx setting, they just ask the
|MBeanInfo of it, which it will get from the invocation (or at least the
|end-point identifier should be in the invocation, which will allow one
|to deduce the MBeanInfo from that).

again abstract the end-point into a "chain" it is a different beast where
the identity is the sum of mbeans, that "container" is really the repository
of the path for a given logical type of flow.  EJB has little reality in
this approach, it only exists as a temporary list of interceptors and
plugins.

|You think this is bad? Why? If it's the performance part: fine, cache it.

I frankly don't think there is a performance issue here.

I also think the real problem is in the nature of this beast, too disruptive
a view.  I am ok with dealing with it, but I think that for most people the
real interceptor chain is "reassuring" also as in its first incarnation, I
doubt it will bring more functionality, you will find resistence in the
brains to "let go" and really go with this detyped/stateless/dynamic/shared
flow system view of the world.  It is fundamentally a SYSTEM view, really
what JBoss is all about these days.  Where there was a reassuring
"container" we now have a new beast, lightweight and dynamic with very
little reality.

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.  So for the 4th time
today, let's try to keep the religiousness of this discussion in a pure
"academic" world, since I won't code it this week.

I would really like to code for the rest of the day...


can I go ?

marcf
|
|/Rickard
|
|--
|Rickard Öberg
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development


___
Jboss-development mailing list
[EMAIL PROTECTED]
ht

Re: [JBoss-dev] Invocation and MethodInvocation

[Rickard Oberg]

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 schme! 2 links
> instead of one, and no lookup in there.


Good.


> again abstract the end-point into a "chain" it is a different beast where
> the identity is the sum of mbeans, that "container" is really the repository
> of the path for a given logical type of flow.  EJB has little reality in
> this approach, it only exists as a temporary list of interceptors and
> plugins.


Alright, I'm cool with that.

BTW, this notion is extremely similar to some meta-physics theories, 
which I find to be very amusing. :-) Funny how real-life concepts tends 
to finds its way into programming.


> I also think the real problem is in the nature of this beast, too disruptive
> a view.  I am ok with dealing with it, but I think that for most people the
> real interceptor chain is "reassuring" also as in its first incarnation, I
> doubt it will bring more functionality, you will find resistence in the
> brains to "let go" and really go with this detyped/stateless/dynamic/shared
> flow system view of the world.  It is fundamentally a SYSTEM view, really
> what JBoss is all about these days.  Where there was a reassuring
> "container" we now have a new beast, lightweight and dynamic with very
> little reality.


Yeah, now we're talking! It is always frightening to let go of adopted 
beliefs, but boy is the rush worth it ;-) Maybe for JBoss 4 then...


> 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.  So for the 4th time
> today, let's try to keep the religiousness of this discussion in a pure
> "academic" world, since I won't code it this week.
> 
> I would really like to code for the rest of the day...
> 
> 
> can I go ?


You're excused. Go code. I'm glad you "got" the above though.

/Rickard


-- 
Rickard Öberg



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Invocation and MethodInvocation

[David Jencks]

Ok marc, I'll try really hard to shut up after this one.

On 2001.11.15 13:00:23 -0500 Rickard Oberg wrote:
> 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 possibility and I think the
> > case with the security proxy interceptor [NOT the security interceptor]
> > (and the interceptor I have for rule engines), you need to precompute
> the
> > derived info and save it somewhere in an initialization step. No matter
> > which approach we use, this initialization step is necessary.  I am
> saying
> > that storing the results of the initialization in the interceptor makes
> > more sense than putting it in an untyped map in the head of the chain. 
> > Doing this systematically also means you don't need to pass the head of
> the
> > chain when you are traversing it with a method invocation.
> 
> 
> This seems to have more to do with caching than the decision on where to 
> keep the data. AFAICT there's no problem with caching the data in the 
> interceptor (although you'd have to do it in a hashtable, with the 
> end-point MBean name as key), to allow such initialization work to be 
> done. As long as you can always re-get the data from the MBean, and that 
> the MBean is really *in charge of* the state.
> 
> Is the reason you want interceptors stateful only for performance?
> 
> 
> >>>If you put the state info in the interceptor instance, you can have
> all
> >>>
> >>the
> >>
> >>>compiler type checking you can stand, you keep the state info needed
> >>>
> >>for
> >>
> >>>the interceptor encapsulated in the interceptor (where, I will say, it
> >>>belongs), and the interceptor becomes much more self contained.
> >>>
> >>
> >>What if two interceptors are interested in the same metadata?
> >>
> > They each store the info they are interested in.  If its the same as
> > another interceptor, who cares?
> 
> 
> Well, *how do they get that info*?? As above, if two interceptors 
> *cache* the data that is fine, because then they're not *in charge of* 
> the data from an architectural/design point of view. It is then 
> inherently shareable. If the metadata belongs to any of the 
> interceptors, then somewhere there needs to be knowledge about what 
> interceptor needs what metadata so that they can be provided this. In 
> the stateless model they are themselves responsible for accessing 
> whatever they need from the container (or whatever the end-point is), 
> thus encapsulating the knowledge of that need.
> 
> 
> >>Also, a stateless interceptor can be used for any container. If you
> want 
> >>to just have tx's, you'd go find a tx-interceptor, and put it in the 
> >>invocation chain. The interceptor will extract the metadata it needs 
> >>about the container using the MBeanInfo, and do its work.
> >>
> > 
> > 
> > what I'm talking about can also be used for any container.  The
> metadata
> > extraction occurs during chain initialization.
> 
> 
> What you mean is that during chain init a particular instance is being 
> created for that chain. Right? What I'm saying is that interceptors 
> exist independently of these chains, i.e. they may exist before any 
> chains exist, it's just that without a chain they are never invoked. 
> When the chains are created particular interceptors are chosen for that 
> chain, and then used. Those interceptors may however be part of other 
> chains acting concurrently.
> 
> 
> >  > name="JB:service=TxInterceptor">
> >   org.jboss.ejb.TxInterceptor
> > 
> >  > name="JB:service=SecurityInterceptor">
> >   org.jboss.ejb.SecurityInterceptor
> > 
> >  > name="JB:service=MyChain">
> >   
> > JB:service=TxInterceptor
> > JB:service=SecurityInterceptor
> >   
> > 
> > 
> >   JB:service=MyChain
> >   myEjb
> > 
> 
> 
> 
> Excellent! Nothing like an example to clarify things.
> 
> Here's mine:
> name="JB:service=TxInterceptor">
> java:/MyTM
>   
> 
> name="JB:service=SecurityInterceptor"
> MyCompanyRealm
>   
> 
> name="JB:service=MyChain">
> 
>   
>   JB:service=TxInterceptor
>   
>   
>   JB:service=SecurityInterceptor
>   
> 
>   
> 
>   
> 
>   JB:service=MyChain
> 
> myEjb
>   
> --
> The interceptors are MBeans, and thus configurable as MBeans. They can 
> have state, just as the two above does, but can also be used by any 
> container, and any chain.
> 
> IMHO this is more powerful, since the interceptors can be used with 
> pretty much whatever MBean/endpoint. If they need info about the 
> endpoint, such as the TxInterceptor wanting to know whether a particular 
> method in the end-point has a particular tx setting, they just ask the 
> MBeanInfo of it, which it will get from the invocation (or at least the 
> end-point identifier 

Re: [JBoss-dev] Invocation and MethodInvocation

[David Jencks]

> 
> 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 that the
factory approach doesn't.  Do you have an example where this is useful?


 So for the 4th
> time
> today, let's try to keep the religiousness of this discussion in a pure
> "academic" world, since I won't code it this week.
> 
> I would really like to code for the rest of the day...
> 
> 
> can I go ?

But what will we do???;-)

david
> 
> marcf
> |
> |/Rickard
> |
> |--
> |Rickard Öberg
> |
> |
> |
> |___
> |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