JBossDeveloper

Fine by me.

"alesj" wrote:
Fine by me.

MutableFieldInfo createMutableField/Method/Constructor(ModifierInfo modifier, String type, String name);

MutableFieldInfo createMutableField/Method/Constructor(int modifier, String type, String name);

public enum ModifierInfo
{
 PUBLIC(Modifier.PUBLIC), PRIVATE(Modifier.PRIVATE),....
 private final int modifier;
 ModifierInfo(int modifier) {this.modifier = modifier; }
 public int getValue() { return modifier; }
 public boolean isPublic/isStatic/isVolatile/etc;
}

Sure.

But can you do then a quick check on how much of
other MC things break with this change?

yup, ill take a look. do you have any overview of which modules that use it?

"stale.pedersen@jboss.org" wrote:
do you have any overview of which modules that use it?

i checked all the mc modules and couldnt find any occurrences of ModifierInfo so it seems we're in the clear.

ive finished most of the implementation except the usage of ExprEditor. from what i can see now, this is the last thing aop uses that i havent implemented in reflect.
take a look at CtBehaviour.instrument(ExprEditor) and for a example of how aop uses it: org.jboss.aop.instrument.CallerTransformer$CallerExprEditor.
the only way i can see we support this is to add something similar to whats in javassist.expr.* to jboss-reflect spi. imo this is something very javassist specific and not something we really should have in the spi.
one solution could be that we add the interfaces to the javassist package (org.jboss.reflect.plugins.javassist) and just add the method to the Javassist* implementation classes.

"stale.pedersen@jboss.org" wrote:

one solution could be that we add the interfaces to the javassist package (org.jboss.reflect.plugins.javassist) and just add the method to the Javassist* implementation classes.

"alesj" wrote:

What about extracting ExprEditor's api in some our interface
and than having the only impl based on Javassist.
(just thinking outloud)

Or this doesn't make sense as you need too much Javassist specific
things from this ExprEditor?

public class BodyTranslatorImpl extends ExprEditor implements BodyTranslator { ... }

Why does it have to be on a MutableX in the first place?

I guess having a custom interface is OK,
but then you need to separate your AOP code as well,
to have this part in configurable (depending on the actuall Reflect impl) class.

e.g.
org.jboss.aop.bodyt.BodyTranslator
org.jboss.aop.bodyt.javassist.JavassistBodyTranslator
org.jboss.aop.bodyt.cglib.CGLibBodyTranslator

"alesj" wrote:
Why does it have to be on a MutableX in the first place?

"alesj" wrote:

I guess having a custom interface is OK,
but then you need to separate your AOP code as well,
to have this part in configurable (depending on the actuall Reflect impl) class.

after the conf call with luc i guess that we dont need to implement the expression editor at all since i cant see us changing aop to use jboss-reflect anyway. - i guess we'll be teammates alesj :)

so i guess i have to ask if the work ive done on jboss-reflect is something you still want in the module?
if so im almost done, the only thing that remains is the classloader issue, but that might not be any issue if aop wont use it anyway (support of scoped classloading/the new classloader integration kabir has been working on).
if its not something that we need for jboss-reflect i think ill be ready to migrate the changes ive done to jboss-reflect/trunk by the beginning of next week.

"stale.pedersen@jboss.org" wrote:

so i guess i have to ask if the work ive done on jboss-reflect is something you still want in the module?

"stale.pedersen@jboss.org" wrote:

if so im almost done, the only thing that remains is the classloader issue, but that might not be any issue if aop wont use it anyway (support of scoped classloading/the new classloader integration kabir has been working on).
if its not something that we need for jboss-reflect i think ill be ready to migrate the changes ive done to jboss-reflect/trunk by the beginning of next week.

"alesj" wrote:

Classloader issue where? In jboss-reflect?
The scoped pool per classloader?

"stale.pedersen@jboss.org" wrote:
im not sure if kabir will finish this at all anymore and even more if jboss-reflect need it since aop wont be changed to use it anyway.