|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jung
|, Dr. Christoph
|Sent: Thursday, October 18, 2001 4:25 AM
|To: Jboss-Development (E-Mail)
|Subject: AW: [JBoss-dev] JMX detaching of invokers (RH/3.0)
|
|
|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?,
I have no problem with the factorization of the deserialization of the
contextual state in MethodInvocation. Maybe even with a loadContext() call.
marcf
|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
