There is always a balance to be struck between on the one hand greater
generality and flexibility with less compile-time type checking and less
speed, and on the other hand a more specific solution that can be checked
more by the compiler and includes scenario-specific optimizations. We have
some hard decisions about where we want to end up on this continuum.
You are suggesting a map for invocation-specific properties of the method
invocation (MI). We could do something similar with the
interceptor-instance-specific state. A few days ago I discussed with Scott
how to deal with interceptor-chain-instance specific interceptor state,
such as the processed security proxy. He suggested keeping essentially the
current system of individual interceptor instances for each chain, each
with their chain specific state. I have started implementing the chain
configuration based on this model. An alternate approach is to keep the
interceptor state in a map attached to the chain head, and sent down the
chain in the MI. Each interceptor can retrieve its state, if any, from the
map in the MI. I find this model somewhat attractive, but would like some
more opinions: right now I am following Scott's suggestion not to implement
it.
If we pursue this model, with one interceptor of each type globally, shared
by all chains, the question arises whether the "next" calls should be
direct or through the mbean server via mbeanserver.invoke(...). On my
machine, using jmxri, 100,000 direct calls take from 0 to 96 ms, whereas
through the mbean server they take 10 sec. I'd like other opinions on
whether this overhead is significant enough to dictate implementation, or
whether an improved mbeanserver will make this negligible.
Thanks
david jencks
On 2001.10.18 04:25:11 -0400 "Jung , Dr. Christoph" wrote:
> Hello Marc & others,
>
> I would like to pose another issue in revisiting the invocation-handler
> chain to public discussion, that is the
> separation of "Invoker" into "Invoker" and "ArgumentDeserializer".
>
> That is, we use sometimes very particular (de-)serialisation routines
> (XML<->Java as well as RMI<->Java) when
> it comes to communicating JDO-related data structures (i.e., persistent,
> but
> serializable
> objects with, e.g., lazy references into the database). The possibilities
> for putting custom serializers
> into the RMI subsystem are, in general, very useful!
>
> Hence, it would be a great invention if one could use the invocation�s
> security/tx/whatever context
> whenever this (de-)serialization is non-trivial (for example,
> fine-grained
> value-object attribute access checks).
>
> For this to work, it would be important to separate the
> (de-)serialisation
> of the arguments in a subsequent
> ArgumentDeserializerInterceptor" from the (de-)serialisation of the
> MethodInvocation in the "Invoker".
>
> Example:
>
> Invoker --> TxInterceptor --> SecurityInterceptor --> ... -->
> ArgumentDeserializer --> BeanInterceptor --> Bean
>
> Even more general,
> it would be the most flexible solution to have the MethodInvocation being
> something like
>
> class MethodInvocation {
> Method method; // or JMX like: String methodName; String[]
> classNames;
>
> Map properties;
> }
>
> where the property map will contain (de-)serialized objects/byte-arrays
> as
> processed by the individual
> Interceptors.
>
>
> Any comments?,
> CGJ
>
> -----Urspr�ngliche Nachricht-----
> Von: marc fleury [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 17. Oktober 2001 00:34
> An: Jboss-Development@Lists. Sourceforge. Net
> Betreff: [JBoss-dev] JMX detaching of invokers (RH/3.0)
>
>
> So let's do good on our promises and finish this RH/3.0 release.
>
> So one thing to do is something that will really bring focus to the
> puzzle.
> It is the detaching of invokers. The invokers (RMI/EJB first) will need
> to
> talk to the JMX node and we route the invocation to the right bean.
> There
> is going to be quite a bit of retooling to do in the container factory
> but I
> don't expect anything major to happen there (I fear it less than the
> classloaders stuff:).
>
> Once we do the RMI/EJB one, we can integrate the .net one and the
> RMI/IIOP
> as well. One enhancement I think has its place is the model MBean
> configuration that Rickard and Juha have been working on, I think Juha
> has
> something good with the XMBeans of the book and it makes sense to
> implement
> it in JBoss. We need the http integration as "standard" JBoss distro
> (don't
> worry tomcat guys we will keep it integrated :)
>
> This is going to be fun as we will then have a generic solution for the
> clustering and failover... and I am eager to hear Bill at Vegas and get
> an
> update.
>
> So... let's clean this industry for good. In a year, this industry will
> feel very lonely. I promise you.
>
> We will own the fucking place
>
> PLgC
>
> marcf
>
>
> xxxxxxxxxxxxxxxx
> Marc Fleury
> President
> JBoss Group, LLC
> xxxxxxxxxxxxxxxx
>
>
> _______________________________________________
> 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
