Women in Technology

Hear us Roar

  Aspect-Oriented Programming and JBoss
Subject:   Logging and tracing code
Date:   2003-05-29 15:24:12
From:   warjort
Response to: Logging and tracing code

A healthy sceptic :-)

1) We have been "hacking" bytecode for a while
within jboss. How do you think we implement
abstract getters/setters for Entity beans?
It is a one time operation during classloading
or deployment.
Sun do it themselves in their
java.lang.reflect.Proxy implementation.

2) Try changing java to jdb in the examples.
Most good IDEs will let you filter packages
such as org.jboss.aop if you aren't interested
in the plumbing.

3) The byte code engineering, no.
But the aspect implementations are based
on tried and tested production code we have
been using in our EJB containers for a while.
We are bringing EJB to the POJO.

4) Would you really ask for a read-lock or
even use a transaction when checking a
user/password table?
In any case, security will be one of the first
aspects in the chain, you don't want people
starting transactions or wasting other
resources if they are not authorised to the


Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Logging and tracing code
    2003-05-29 16:23:22  anonymous2 [View]

    I'm not a skeptic so much as a reasonable engineer. In order to adopt a new technology in a PRODUCTION environment that technology has to prove not only it's value (which was only assumed by the article) and it's robustness.

    1) Having done it in the past doesn't make it the right thing to do. You don't think it's a red flag that to implement basic database transactionally functionality we are hacking byte code?

    2) I'm not actually running the examples. The question remains, can I use the standard IDE debugging tools to debug through both the aspect code and the standard class code in a straightforward manner.

    3) The reason we have the term POJO is that engineers were burned by having an EJB 1.0 standard that could not be deployed. The very idea of 'bringing EJB to POJO' is defeating the point.

    4) I'm the adminstrator adding a user to the user table. After one level of nesting within the transaction you have the potential for a read lock. Or are all of the transactions within a transaction restricted to being within a single method?

    I think you are missing the larger point. I am an experienced programmer with a lot of production work under my belt and I am interested in AOP. From what I have seen so far I, like many others, have stayed away from AOP because of well founded issues like these. But also because AOP is a paradigm shift, possibly a larger paradigm shift than object oriented programming. In order to get people up over that hump the AOP advocacy community is going to address the fundamental issues that surround revolutionary technology:

    1) What is the compelling value.
    2) What are the pros and CONs
    3) What are the killer applications.
    4) OOP was a better mapping from the real world to the software world. Does AOP provide an even better mapping. If so, how?

    These issues need to be addressed before you can realize this vision of AOP leading the technology wave over the next 15 years.

    Object Oriented Programming wasn't immediately embraced. There were a lot of doubters then, and there are still some now (though I am not one). In order for OOP to become popular the supporters had to twist of lot of arms and minds. I'm sitting here begging for my arm to be twisted and simply seeing a bunch of code and some assumptions that AOP is just 'right'.