-
15. Re: AOP Introductions(Extensions)
> > still don't see it. who stops me to substitute the
> > collection class? but, ok, let me do it first.
>
> the classloader will:
>
> $ cat Test.java
> package java.something;
>
> public class Test
> {
> public static void main(String[] args)
> {
> System.out.println("Hot Stuff!!");
> }
> }
>
> $ java java.something.Test
> Exception in thread "main"
> java.lang.SecurityException: Prohibited package name:
> java.something
>
> Can't load anything into java.* package.
Actually, I think Javassist can replace a reference of one class with another. so:
{
HashMap map = new HashMap();
}
I think you can change all references to HashMap to be another class. I haven't tried it yet.
I support replicated collections in the AOP cache. I don't use replacement but rather use a proxy instead.
Bill -
16. Re: AOP Introductions(Extensions)
> > to instrument these in AOP. Using class swapping is
> the
> > way to do it naturally through the classloader
> level.
>
> still don't see it. who stops me to substitute the
> collection class? but, ok, let me do it first.
you can't :) see with juha and adrian on how to code around with class substitution tricks. So when someone asks for "map' he really gets another class.
will work for those that use the standards collection package. -
17. Re: AOP Introductions(Extensions)
> > I am looking for a simple state tracking at the
> object
> > level, see what bill has done for acid.
>
>
> i do it.
Great then! CMP POJO persistence should be far :) -
18. Re: AOP Introductions(Extensions)
> Actually, I think Javassist can replace a reference
> of one class with another. so:
>
> {
> HashMap map = new HashMap();
> }
>
> I think you can change all references to HashMap to
> be another class. I haven't tried it yet.
try it ! try it!
that would be great, we wouldn't even have to do any funky stuff then, -
19. Re: AOP Introductions(Extensions)
Juha,
the only problem I see is with the user implemented collections. When an application expects to get a collection of some custom type from the persistence framework. And here AOP is the rescue.
But when user expects just some java.util.Collection, I can return an instance of org.jboss.persistence.jdo.Collection class I implemented.
By the JDO spec, btw, an application should not rely on custom collection classes and use standard java interfaces. So, I don't see the problem here.
alex -
20. Re: AOP Introductions(Extensions)
> But when user expects just some java.util.Collection,
> I can return an instance of
> org.jboss.persistence.jdo.Collection class I
> implemented.
> By the JDO spec, btw, an application should not rely
> on custom collection classes and use standard java
> interfaces. So, I don't see the problem here.
nice work alex, can't wait for your jdo commits.