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
