Peter, > (I've deleted your original message Paul, but this just reached my > annoyance level so i thought i'd comment)
No probs, I delete your too ;-) > It would be very nice to be able to catch the exceptions that are > actually thrown. How do other users of phoenix deal with this problem? > If I have a service that throws a checked exception, the client of > that service has to handle it properly, but the handling code is never > called because the original exception never comes through, its the > wrapped one. You can ask the InvokationTargetException what exception it contains. You just have to code in such a way that you know a proxy exists. > Why do we have the dynamic proxies anyway? I'm guessing to enforce > separation between blocks & services? > > If the BCEL would let us have the proxies AND the original exceptions, > lets have our cake and eat it too :) Yes, and Pete#1 probably guess wehre I am going with this... Image Phoenix classloader loading Sar1 - Tomcal and say a future James SAR that needs TCL for stats publishing and an admin interface. We'll refer to first as PCL and the seperate classloaders Phoenix has made for the two sars as TCL and JCL. Consider that James wants to use "Tomcat.launchWebApp(URL locationOfWebapp)" and that is what we call a service so it has a version - "1.0". We could describe the two apps having their own Tomcat interfaces in their own lib/ like so: TCL:org.apache.Tomcat:V1.0 JCL:org.apache.Tomcat:V1.0 Now we want the James app to use the Tomcat from the Tomcat app. All of my understanding (backed up by some experimentation) is that if the same interface is in two class loaders and one of the apps is, for the sake of argument, trying to cast an instance from the other to it's Tomcat interface, then it will get a ClassCastException (CCE) as they are different interface according to the JVM. We're considering BCEL as a solution to DymanicProxys. It could also be more of a delagate in that it is bridging two seeingingly identical interfaces in seperate classloaders. It would not be so hard to write, and I was considering a standalone demo to illustrate the idea, but I think we might all be able to understand it as described. At Xmas (as prev mentioned) I did an interface promotion demo/trick to illustrate a solution to the same problem (one interface in two classloaders is two differnet interfaces), but it sucked as it really was a trick and meant that we could only support one version of one interface at any one time. With a BCEL delegate design to the shared/published block problem, we could support multiple versions of the same inteface in the same Phoenix VM. A perfect world. No, it gets better we could design mappings to illustrate how backwards compatible a particular block was. A 1.1 block, with a slightly different interface could support all the features of a 1.0 block if the delegate generation was smart enough. This is so neat (if it works) Apache should kickoff a dynamic class generation API of their own (BCEL's jar contains GNU regexp and is LGPL). Regards, - Paul H --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
