First, I want to make sure no one confuses me for an AOP or AspectJ expert. :)
Interestingly, just after I posted this message, someone else posted an AspectJ-related message in struts-dev. He shows how to apply exception handling to the entire Struts framework in about 6 lines of code; and he also shows his custom Ant task (not the code, just how to use it in build.xml). If you're interested, check out the archives for struts-dev on 1/10/2002 (U.S. Eastern); "AspectJ" is in the subject line. I used the term "interceptor" because I knew everyone would understand that concept. But in some ways AOP seems to be significantly about intercepting and enhancing or modifying behavior in existing classes/libraries. Check out http://aspectj.org/doc/dist/progguide/ch01s04.html, specifically the "Providing Consistent Behavior" section. A "pointcut" named "publicMethodCall" is defined. It refers to any invocation of any public method on the named set of packages. The "advice" named after() is defined for any invocation of methods in the publicMethodCall pointcut when those methods throw an exception of type Error. The extra behavior is in that after() advice's code. If the methods exit normally, nothing happens. The behavior here just writes something out; but it could throw a different kind of exception such as a RuntimeException. Also check out: http://aspectj.org/doc/dist/progguide/ch01s03.html to see some simple examples of interception which add method entry/exit logging, pre- and post-conditions, etc. All of those types of aspects are essentially interceptors. At this point, of course, you've about exhausted my knowledge. ;) Donnie > -----Original Message----- > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 11, 2002 3:12 AM > To: Jakarta Commons Developers List > Subject: Re: AltRMI - Proposal & request for help > > > Donnie, > > Very Interesting suggestion. I''ve clicked on the URLs and read quite a > bit. I had reservations about it until I realised it generates standard > Java bytecode. I'd like to find out more about the 'interceptor' idea > you have but can't find info on the site. Could you point me to a > snipped of example code (I am an example orientated person - EOP ;). > > - Paul > > >This is likely ***way*** out of scope, but for those who have followed > >"aspect-oriented programming" (AOP) at all, check out http://aspectj.org, > >especially: http://aspectj.org/doc/dist/progguide/ch01.html. > > > >How does this possibly apply to AltRMI, you ask? Using AOP > techniques, you > >can define interceptors (aspects) for arbitrary method invocations on > >arbitrary classes/interfaces. In those, you can catch > exceptions, add code, > >examine parameters, etc. The point is you can overcome the interface > >extension and RemoteException problems of RMI without needing an > alternate > >transport. > > > >Of course, this is a general solution to what an application-specific > >dynamic proxy can also accomplish. I'm using that type of technique (a > >dynamic proxy) in a current application to insulate the client from > >RemoteExceptions, log all call entries/exits, etc. > > > >I'm not trying to "dis" AltRMI at all, just pointing out the > availability of > >other solutions if those are your primary objections to RMI. > > > >FWIW... > > > >Donnie > > > > > >>-----Original Message----- > >>From: Paul Hammant [mailto:[EMAIL PROTECTED]] > >>Sent: Thursday, January 10, 2002 1:12 PM > >>To: [EMAIL PROTECTED] > >>Subject: AltRMI - Proposal & request for help > >> > >> > >>Folks, > >> > >>Here is the proposal. The audience for this tool is those that dislike > >>RMI in that it needs special interfaces (must extend Remote, must > >>specify RemoteException). Those people that dislike RMI may have come > >>across Glue ( http://www.themindelectric.com/products/glue/glue.html ) > >>and its unhindered interface publication scheme. People that dabble > >>with .NET claim that it has a similar unencumbered method publication > >>scheme. > >> > >>AltRMI is the same idea as Glue but not over SOAP. Again, this is not > >>for people that think there is nothing wrong with RMI as is. The first > >>alpha version has been used by Avalon-Cornerstone as a XML configurable > >>'block' that other blocks can depend on. That block has already been > >>used by AvalonDB - a full RDBMS being built by a few of us in > >>Avalon-Cornerstone's CVS. Incidentally, AltRMI was code ripped out of > >>AvalonDB and generalized. > >> > >>There are a few differences with Glue : > >> > >>1) Not over SOAP. In this respect Glue is a very accomplished > >>bit of work. > >> > >>2) AltRMI can be instrcted as to what is pass by value and what is pass > >>by reference (Glue can't). > >> > >>3) Glue does not generate client side proxy code, AltRMI does. The Glue > >>solution is compatible with JDK1.1, 1.2, 1.3, 1.4 (according to Graham > >>Glass) and therefore very flexible. The secret solution Glue uses does > >>not support introspection on the client side. AltRMI does generate > >>proxy classes for client side use. As such it is introspectable. This > >>is of most use to scripting languages/envs (Rhino, Beanshell etc). At > >>the bottom of this email is a example generated proxy class. > >> > >>We (I) need to build a community around AltRMI. There are quite a few > >>things to do. Please take a few minutes to read the following proposal. > >> If you are interested in running AltRMI, its CVS dir contains a README > >>file for instructions. Alt positive ideas/patches very welcome. > >> > >>Regards, > >> > >>- Paul H > >> > >>---------------------------------------------------------------- > ---------- > >> JAKARTA COMMONS - ALTERNATIVE (TO) REMOTE METHOD INVOCATION > - "AltRMI" > >>---------------------------------------------------------------- > ---------- > >> > >>Abstract: > >> > >>The AltRMI package provides an alternative to Java's RMI. Apart from > >>simply > >>being an alternative it provides the following features: > >> > >>1) Any interface publishing > >> > >> - no forcing of extension of java.rmi.Remote > >> - no forced declarations of "throws RemoteException" > >> > >> * These two features are part of the reason why Graham Glass's 'Glue' > >> product is so successful. His API goes several stages futher in that > >> it pubishes APIs via SOAP so that any language in any location can > >> use Glue published Java services. > >> > >>2) Multiple transports > >> > >> - Plain Sockets / ObjectStream > >> - via RMI > >> - Piped with same VM / ObjectStream > >> - Direct within same VM > >> - SOAP (planned) > >> - Might require additional undynamic "toWSDL()" step. > >> - CORBA (planned) > >> - Might require additional undynamic "toIDL()" step. > >> - Plain sockets / custom messaging (planned) > >> - JMS (planned) > >> > >>3) Speed > >> > >> - Using the AltRMI over RMI transport as a baseline. > Measuring 100,000 > >> method invocations after discarding the first for the purposes of > >> timing, ObjStream over sockets is three times faster, ObjStream over > >> Pipe is eleven times faster, Direct is a thousand times > >>faster. Granted > >> there could be less of an advantage if compared to a proper > >>RMI solution > >> (not layered), or one that is in the same VM with different threads. > >> > >>4) Interface/Impl separated design. > >> > >> - AltRMI can be build easily into any application or application > >>framework. > >> Individual aspects can be reimplemented (or overridden) as the need > >> arises. > >> > >>5) Choice of location of generated Proxy class. > >> > >> - Classes providing client side implementation of the transported > >> interface(s) can be either on the client side or the server > side (and > >> duly transported) at time of lookup. > >> > >>6) Choice of castability of generated proxy class. > >> > >> - To suit remote facilities that are happy with refection and do > >> not need to cast to an interface to use a bean (I am thinking of > >> beanshell) the proxy class can be generated without specifying > >> that it implements the interface(s). > >> > >>7) Suspendable/Resumable service. > >> > >> - The Server supports suspend() and resume(). With the current > >>impl this > >> replies in a timely fashion to the client that the client should try > >> later. The client waits for the notified amount of time and > >>seamlessly > >> trys the requets again. A server could cycle through > >>suspended and back > >> to resumed will not affect the client except for the a delay. > >> > >>8) Recovering transport > >> > >> - AltRMI tries to recover its transports should they fail. > The recovery > >> is pluggable in that the developer can choose when/how/if the > >>connection > >> handler tries to recover the connection. Any inprogress, but > >> disconnected method invocation will attempt to be recoved and just > >>return > >> as normal, albeit after a longer than normal delay. > >> > >>9) Event API > >> > >> - For suspensions, abnormal ends of connection etc, there is > a listener > >> that can be set that will allow actions to be taken. Abnormally > >> terminated connections will by default try to be reconnected, the > >> listener can decide if, how many, and how often the retries occur. > >> > >>10) Unpublishable and republishable API > >> > >> - The server is able to unpublish a service. In conjuction with > >> suspend()/resume() a service can be republished, upgraded etc > >> whilst in use, or just offlined. > >> > >>11) Startable API for Server > >> > >> - The server implements and acts upon start() and stop() methods. > >> > >>12) No just pass by value. > >> > >> - AltRMI started life as 'pass by value' only. In now supports return > >> types and parameters wrapped in another AltRMI Facade. > >> > >>13) No duplicate instances. > >> > >> - If you call Person p = getPerson("Fred") twice you will get the same > >> instance on the client side is it is the same instance on the server > >>side. > >> > >>Limitations: > >> > >>1) Use in EJB > >> > >> - This is not of any use for EJB Home/Remote interfaces. The > container > >> maker chooses the transport for use that container, not the > >>bean coder. > >> This is intended for other client server solutions. Beside RMI over > >>IIOP > >> is Sun specified. > >> > >>Todo: > >> > >>1) Other transports > >> > >> - SOAP, CORBA (with WDSL & IDL generation steps) > >> - Other RMI (over IIOP, over HTTP) > >> - Custom, socket protocol > >> - JMS > >> > >>2) BCEL for generated proxy class. > >> > >> - The current impl writes java source then compiles it. We > >>could do this > >> inline with BCEL. This as an heavier, but more design perfect > >> alternative to the current server side impl. > >> > >> - BCEL is really difficult to use if you are not skilled in it!! > >> > >> > >>3) Client and Server code for secure conversations. > >> > >>4) Authentication and Authorisation on lookup(..). > >> > >>Initial committers: > >> > >>Paul Hammant (hammant) > >> > >>---------------------------------------------------------------- > ---------- > >>Example Generated Proxy class. Not for editing, not normally > >> for user viewing. A step similar to rmic. > >>---------------------------------------------------------------- > ---------- > >> > >>public final class AltrmiGeneratedHello_Main implements > >>org.apache.commons.altrmi.test.TestInterface { > >> private transient > >>org.apache.commons.altrmi.client.impl.BaseServedObject > mBaseServedObject; > >> public AltrmiGeneratedHello_Main > >>(org.apache.commons.altrmi.client.impl.BaseServedObject > >>baseServedObject) { > >> mBaseServedObject = baseServedObject; > >> } > >> public void hello (java.lang.String v0) { > >> Object[] args = new Object[1]; > >> args[0] = v0; > >> try { > >> > >>mBaseServedObject.altrmiProcessVoidRequest("hello(java.lang.String > >>)",args); > >> } catch (Throwable t) { > >> if (t instanceof RuntimeException) { > >> throw (RuntimeException) t; > >> } else if (t instanceof Error) { > >> throw (Error) t; > >> } else { > >> throw new > >>org.apache.commons.altrmi.common.AltrmiInvocationException("Should never > >>get here" + t.getMessage()); > >> } > >> } > >> } > >> public boolean hello3 (short v0) throws > >>java.beans.PropertyVetoException, java.io.IOException{ > >> Object[] args = new Object[1]; > >> args[0] = new Short(v0); > >> try { > >> Object retVal = > >>mBaseServedObject.altrmiProcessObjectRequest("hello3(short)",args); > >> return ((Boolean) retVal).booleanValue(); > >> } catch (Throwable t) { > >> if (t instanceof java.beans.PropertyVetoException) { > >> throw (java.beans.PropertyVetoException) t; > >> } else if (t instanceof java.io.IOException) { > >> throw (java.io.IOException) t; > >> } else if (t instanceof RuntimeException) { > >> throw (RuntimeException) t; > >> } else if (t instanceof Error) { > >> throw (Error) t; > >> } else { > >> throw new > >>org.apache.commons.altrmi.common.AltrmiInvocationException("Should never > >>get here" + t.getMessage()); > >> } > >> } > >> } > >>} > >> > >> > >> > >>-- > >>To unsubscribe, e-mail: > >><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > >><mailto:[EMAIL PROTECTED]> > >> > >> > > > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
