"alesj" wrote : "stale.pedersen(a)jboss.org" wrote : as we've stated in the aop design forum (and here) is that the current state of jboss-reflect is too limited for aop to use at all. a well designed MutableClassInfo can change that though. | | | What about if we just added 'mutable' wrapper/delegate. | e.g. you would actually create your own ClassInfo impl based on existing JavassistCI: | Extra stuff would be held in this mutable wrapper/delegate. | When invoked, first check extra stuff if it exists, else delegate. | No. It should evolve into a one-stop shop for reflection and byte-code manipulation implemented on top of javassist (or any other byte code tool). That's the purpose of the abstraction. The original idea was that ClassInfo would be able to represent classes before they are loaded. The code was originally ported by Bill from AOP. Having additional functionality to add/change methods, etc. should also be a part of this api. That additional functionality obviously wouldn't work if you just chose to use the basic introspection implementation as now which is "read-only". But to make it properly useful it needs deeper integration with the classloading structure, see below. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - the possibility to create a classobjectrepresentation from a byte[]/File/Url | | | What exactly do you mean here? | e.g. ClassInfo ci = factory.getClassInfo(byte[]/File/Url); ? | This just lets you create a ClassInfo from the bytecode. But for this to work properly it needs to have a understanding as to which classloader the class/bytecode should be assigned. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - be able to change/add/remove fields/methods/constructors/classes similiar to what javassist support | | | How do you do this in your prototype? | I guess a single place where you know the aop rules would be enough? | e.g. AOP impl of TypeInfoFactory overridding instantiate method | See above. It just needs a new interface to say the Javassist*Info implements the Mutable behaviour. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik) | | | Annotation visibility? | Not sure why you need this. I assume you mean being able to look at annotations that are not Runtime visible? Is that really a good idea? anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - be able to get a classobjectrepresentations (ala ClassFile in javassist) from an existing ClassInfo object | | | Why? | This is/shoule be impl detail. | Unless you mean being able to get the resulting byte code from the manipulation so you can defineClass() on it I don't think it is a good idea. Allowing access to implementation details is not a good idea, e.g. the deprecated TypeInfo.getClass() should not be there. Instead we need to extend the abstraction to make this unnecessary. This could include some helper methods to defineClass() from a ClassInfo. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - support scoped classpools | | | Yup. | Nope/Yup. The Scoped classpools are wrong. They don't understand the classloading rules properly - except in JBoss4, although they are better than what we have now. See the discussions in the aop forum I had repeatedly last year with Kabir. SUMMARY Besides completing the generics stuff in the javassist class info so we can use it, the TypeInfo needs additional "optional" interfaces for mutable behaviour. But the real work is making aop/classinfo properly integrate with the classloading structure. Additionally as Ales and I discussed in Slovenia, the MDR introspection stuff (Class annotations) and a number of other places should also be using the ClassInfo stuff. Especially when it comes to the more efficient method/field reflection stuff I wrote in the JavassistClassInfo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201761#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...