The AspectClassLoader

[hchirino]

"marc fleury" wrote:
> You could do that by slipping the AspectClassLoader
> as a child of the UCL that jetty sets up for the
> webapp. Then the webapp developer creates a
> "org/foo/XServlet.aspect" file and sticks it in
> WEB-INF/classes.

wouldn't work that way would it. The child delagates to the parent (in our case a UCL) that would just return a defined class. Unless the UCL is itself an AspectCL you are missing that behavior.

> When jetty trys to create an instance of the
> org.foo.XServlet class, the AspectClassLoader
> intercepts the load call and returns the proxy class
> for the aspect that was defined in the
> XServlet.aspect file.

That is pretty good.

I did talk to a professor at Georgia Tech yesterday that does something interesting. He generates a dynamic proxy equivalent from the bytecode representation with just BCEL generation of bytecode. They published a paper recently that demos how they make any java object "remote" with that trick. While I think this is dumb as we essentially make that work with a much robust interceptor implementation on the client side I saw the light of their work. Essentially we can intercept pojos and really create an interface and proxy add all our shit to it. We must ensure that the implementation delegates to a handler so we can dynamically add behavior as we are discussing (they were implementing behavior in BCEL barf!).

Bottom line is that this behavior implemented in the ClassLoader can make sure that we intercept the UCL loading to be AOP enabled. We DP all objects coming in.

THAT IS REALLY POWERFUL.

> This same pattern should be applicable anywhere you
> configure a "java class name" as long as you can slip
> in the AspectClassLoader into the loading structure
> of the application that is creating instances of your
> "java class name"
>
> Make better sense??

almost, I think we are onto something here.

[marc.fleury]

"marc fleury" wrote:
I don't get it,

expand on the webworks/struts action idea. How can I dynamically make an EJB a struts action. Give me an example and example usage. Are the CLs extensions of UCL? how do you specify that we should use the CL for deployment? how do you specify an aspect deployment? right now it seems we are using purely a run-time approach.

in other words give me a clear use-case scenario. I am not saying it is "cute" I am just saying that I want to see it clearly. Stuff that isn't clear usually isn't real.

[hchirino]

"hchirino" wrote:
OK.. lets take the case we want to start a transaction at the servlet level. Right now that would be done with a UserTransaction.

The goal is to remove the UserTransaction stuff out of the servlet since thats work that the container could be doing in a less error prone way.

You could do that by slipping the AspectClassLoader as a child of the UCL that jetty sets up for the webapp. Then the webapp developer creates a "org/foo/XServlet.aspect" file and sticks it in WEB-INF/classes.

When jetty trys to create an instance of the org.foo.XServlet class, the AspectClassLoader intercepts the load call and returns the proxy class for the aspect that was defined in the XServlet.aspect file.

This also means that the XServlet.aspect file defines what the targetObject class will be so he can lazyload the targetObject which in our example would be the target servlet.

So in effect jetty would we working with a servlet that is really an aspect object with a interceptor stack to a normal servlet.

This same pattern should be applicable anywhere you configure a "java class name" as long as you can slip in the AspectClassLoader into the loading structure of the application that is creating instances of your "java class name"

Make better sense??

[marc.fleury]

"marc fleury" wrote:
> You could do that by slipping the AspectClassLoader
> as a child of the UCL that jetty sets up for the
> webapp. Then the webapp developer creates a
> "org/foo/XServlet.aspect" file and sticks it in
> WEB-INF/classes.

wouldn't work that way would it. The child delagates to the parent (in our case a UCL) that would just return a defined class. Unless the UCL is itself an AspectCL you are missing that behavior.

> When jetty trys to create an instance of the
> org.foo.XServlet class, the AspectClassLoader
> intercepts the load call and returns the proxy class
> for the aspect that was defined in the
> XServlet.aspect file.

That is pretty good.

I did talk to a professor at Georgia Tech yesterday that does something interesting. He generates a dynamic proxy equivalent from the bytecode representation with just BCEL generation of bytecode. They published a paper recently that demos how they make any java object "remote" with that trick. While I think this is dumb as we essentially make that work with a much robust interceptor implementation on the client side I saw the light of their work. Essentially we can intercept pojos and really create an interface and proxy add all our shit to it. We must ensure that the implementation delegates to a handler so we can dynamically add behavior as we are discussing (they were implementing behavior in BCEL barf!).

Bottom line is that this behavior implemented in the ClassLoader can make sure that we intercept the UCL loading to be AOP enabled. We DP all objects coming in.

THAT IS REALLY POWERFUL.

> This same pattern should be applicable anywhere you
> configure a "java class name" as long as you can slip
> in the AspectClassLoader into the loading structure
> of the application that is creating instances of your
> "java class name"
>
> Make better sense??

almost, I think we are onto something here.