Rickard,
> Alright, here's *my* take on what "AOP" means (this
> is largely the same as what's in my recent tech talks
> at www.java.no).
Good to have you back.
> 2) Extend interfaces of the "class". An "class" in
> AOP can be thought of as "the set of interfaces and
> the set of interceptors", since objects with the same
> set of interfaces and same set of interceptors will
> "look and feel" the same.
Can we agree on this modelization of the Aspect.
[==o
or
[=-|||-=o
Where the front is an interface, the link the actual detyped is - and type ==
The o is the target object. Could be EJB, MBean, DMBean, interface + pojo, nothing.
The first AOP is just a simple interface+object. This is good as people like simple objects to implement their behavior, they can understand that very easily.
The Aspect is thus
[=-|||-=o
[==o
[=-|||-=o
[=-|||-=o
for example, where this interceptor has 3 detyped chains (dynamically monitorable) and 1 typed instance. We DP the whole so that the resulting Object has the 4 mentioned types.
An EJB for example is a simple
[=-|||-=o
Where the [ is the Remote type the = the Dynamic Proxy generated decoupler, - the detyped invoke(Invocation) signature, the |||| the interceptors implementing remoteness, transactions, CMP and cache maintenance.
Yes I like that, message recieved, see drawing above.
> The base implementation is to do it using Dynamic
> Proxies, blah blah. You know the drill here, nothing
> new.
Well that is actually a limitation. Let's work on BCEL for the objects and pojos. We need to be able to give an instance of anything to implement the behavior.
The DP bytecode would then result in the front interface showing the sum of interfaces thrown at it at construction time as well as the methods exposed by the pojos. I don't even know if this is possible in bytecode (I don't know bytecode at all).
> For 1) I have (at least) the following requirements:
> *) Need to be able to replace interceptors at
> runtime, and especially when sending it back and
> forth between client and server. I want one set of
> interceptors on the client and one set on the
> server.
Yes on updatability but I am fuzzy as to how you would change the client side. Right now I am thinking of an MMB to hold the interceptor configuration. Please explain how you see the client side modifications? I don't assume you want a JMX construct on the client (although we could, he he) and then how do you notify the client of the modifications? Do you allow for updates from the client? and do you allow for updates from the server? this would be simple to do in JBoss 4.0 with what bill is adding in the interfaces. In clustering we use the return value to update the topology of clients. The same could help the server control the configuration of the clients by way of the return method.
> *) Need to be able to specify interceptors on the
> "object" or on a specific interface. For example, I
> may want one interceptor to apply to all interfaces
> in a particular "class" (as defined above), and
> another to apply to a particular interface regardless
> of what "class" it is being used in. This is very
> very important, to have these two levels of
> interceptors.
pffff... ok here is what I want to do. I want to be able to specify for the detyped ones, what set of chains should have the interceptors. You may want "ALL" you may want "APPLICATION" you may want "OBJECT" or maybe even "METHOD" (?). This can be specified in configuration files. Kiss.
> *) Need to be able to specify in descriptor (as a
> regular expression) what methods to apply each
> interceptor on. For example, I want to trigger a
> search engine to index my objects whenever I call a
> "set*|add*|remove*" method.
do you think the following statement
apply CMPinterceptor where application="MY-APP" and method="get|set*";
uttered by a sys-admin is possible? I kinda do but I want your input on that. If not KISS, ejb-jar.xml like semantics with extensions to application.
> *) Interceptors need to be able to be both stateless
> and stateful, i.e. one for all objects or one for
> each object.
yes, I am reaching that conclusion as well. I think stateful interceptors are easier to code and configure though. Simple to do with current JBoss 3.0. The pure stateless interceptor is a theoretical possibility that is implemented in the client interceptor but whose applicability I don't really see.
> For 2) I have (at least) the following requirements:
> *) The interfaces should have no restrictions. No
> "need to extend blah" or "methods need to throw yada"
> stuff. Just plain interfaces
Yeah yeah yeah, we agree.
> *) My implementations need to be able to implement
> those interfaces directly, i.e. not like in EJB.
see my [==o object that is the one.
> *) I need to be able specify per "class" whether I
> want a generic implementation of an interface or if I
> want a particular implementation. I.e. I want to say
> "this class has interfaces X,Y,Z" but not *have* to
> say "the implementation of X is XBean". This should
> be provided as a default through a "the default
> implementation of X is XBean" declaration.
configuration. Already done in JBoss 2.x.
> *) I should be able to take an object, and while I'm
> holding on to it I should be able to attach a new
> interface to it that can be thrown away when I'm
> done. This essentially means to create a new proxy
> with n+1 interfaces, that has the same set of
You can't. A Microsoft employee who came to the Palma training pointed out that you could use hotswap in JDK 1.4 (debugging facility).
> interfaces as before. Typical example of when this
> might be useful is if I have an object graph that I
> want to access through DOM: just attach DOM
> interfaces and send it to a XSL processor or
> something like that. This doesn't affect the core
> object model, only for how I'm using it at that
> particular time.
>
> And so on and so forth.
>
> I've already implemented all of this though, and
> yeah, it's pretty cool. If you do this in JBoss, make
> sure that it's not tied to JMX, or else it'll be
> tricky to use it in clients (e.g. we use our object
> model, which are AOP objects) in applets. If you
> can't do that, much of the value is lost.
>
> /Rickard
ahem, where is the source?
marc f