I am learning JMX as a I go here (by writing tests) and was hoping that registerMBean doesn't depend on the actual class (or its name). What's the point of interfaces if you write APIs that require classes? I am still hoping to make this work with a proxy, but I will try out a genclass-based approach and see if that fixes things.
Maybe a better way to summarize my position is that I understand class loaders, and I am wondering how poorly-behaved the JMX API is. Stu > I took a quick look at the lib, and yes, it could be a classloader > thing. But I wonder if your plan is destined for success. If > registerMBean is capturing the actual class of a proxy there are a few > issues. One is that proxy doesn't guarantee a unique class per usage, > in fact, currently it will reuse the same class for any invocation > with the same set of superclasses. > > The second has to do with visibility. There simply is no way to > dynamically generate a class accessible by name from every other class > in an app, due at least to classloader hierarchy in the basic Java > case, and modularity systems like OSGi make it less possible, since > they are working to prevent exactly that. > > Even if proxy did generate a unique class per call site _and_ you > could establish a classloader of your choice with context classloader > or something, you'd still have a problem in that there is no standard > root classloader that will load classes for you from bytecode, so such > a classloader has to be a child of another, and thus the classes it > loads not universally visible. > > The bottom line is that the instances generated by proxy are meant to > be manipulated via the interfaces they implement. The specific classes > of which they are instances is an implementation detail. > > Rich > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
