[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: MutableClassInfo?

adrian@jboss.org do-not-reply at jboss.com
Wed Jan 14 07:57:29 EST 2009


"alesj" wrote : "stale.pedersen at 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 at 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 at 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 at 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 at 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 at 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#4201761

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201761



More information about the jboss-dev-forums mailing list