[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by adrian@jboss.org
"alesj" wrote :
| But I guess this shouldn't be a problem to add/impl,
| as our current scoped classpool impl is simply a map of CL,Pool pairs
| and all TypeInfoFactory::get methods have a means to get CL.
|
The scoped classpool isn't that though. It works at the "domain" level
assuming all peer classloaders are visible to each other and that they all
export everything.
anonymous wrote :
| It's probably just the case of delaying class loading as late as possible
| plus changing how we cache things with non-introspection TypeInfoFactory impls.
| e.g. Class == CL + classname
If everybody used the ClassInfo stuff there should be no real classloading at all
until it is really needed, i.e. objects constructed.
And all the reflection would be optimized (faster and stored only once)
using the javassist implementation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201766#4201766
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201766
17 years, 2 months
[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by adrian@jboss.org
"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#4201761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201761
17 years, 2 months
[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by alesj
"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.
"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); ?
"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
"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?
"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.
"stale.pedersen(a)jboss.org" wrote :
| - support scoped classpools
|
Yup.
Adrian, what would happen now if we used Javassist impl of TypeInfo?
Probably CtClass not found for some non 'default' classes?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201729#4201729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201729
17 years, 2 months