Aspect-Oriented Programming and JBoss
下面是关于这篇文章的讨论，值得一看。
Logging and tracing code
Why is it that all of the AOP examples I see are always logging and tracing? Is AOP good for anything else?
- Logging and tracing code
2003-05-29 11:10:37 warjort [Reply | View]
- Logging and tracing code
2003-05-29 14:22:58 anonymous2 [Reply | View]
All of those things (security, transactions, clustering) are all great, but any reasonable engineer is going to find a lot of things to be concerned about with this approach.
First, AOP is hacking the byte-code at runtime. This is a huge red flag that if it is really no problem needs to be addressed up front.
Second, can I debug it? Can I step through line by line as the method gets called and the aspects get invoked, then as the main body runs and the aspects are re-invoked, etc.
Third, has this technology ever been used IN PRODUCTION? We have heard a lot about AOP theory and example implementations from PARC, but what about real use on a web application has a healthy amount of tables and real business logic with transactional edge cases?
Plus there are possible interaction issues. What if my security aspect requires a database lookup within a nested transaction aspect? Will it find a read-lock table and go into deadlock?- Logging and tracing code
2003-05-29 15:24:12 warjort [Reply | View]
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
operation.
Regards,
Adrian- Logging and tracing code
2003-05-29 16:23:22 anonymous2 [Reply | 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'.
- Production
2003-05-30 09:26:43 anonymous2 [Reply | View]
Just to emphasize one of Bill's points.
A lot of the aspects we have are proven
PRODUCTION implementations from our EJB container.
Whether AOP applies to non-system aspects
is another question.
System aspects deal mainly with context
rather than data.
Bill mentioned billing.
Constraint validation would be another,
a sort of business level "assert".
Letting the POJO get on with the job of doing
rather than deciding whether it should.
You can build your own OOP framework for this,
AOP is much more flexible. It handles
the plumbing for you.
But it may be too flexible if you have lost
static type checking.
Regards,
Adrian- Production
2003-05-30 09:40:03 anonymous2 [Reply | View]
Another example is hooks for notifications. No more of the syntax-sugar of Listener interfaces and such.
Bill- Production
2003-05-30 12:00:15 anonymous2 [Reply | View]
It's funny you should mention this because I am a big fan of the Dependency pattern. When you make use of it on a large scale it becomes critical to be able to control who publishes what and when, and what listeners do in response. Otherwise the notifications trigger listeners, which trigger more notifications which trigger more listeners and eventually it spins out of control.
What I found when I used the Dependency mechanism on a large scale project was that I inititally wanted some sort of aspect mechanism (AOP wasn't around at the time). But that later, during debugging, I was thankful that I could adress the listener/notification issues on a case-by-case basis by inspecting the code.
I also kept the number of central broadcasters to a minimum. If I were to add notification to every method of every class I wouldn't have a good grasp of which notification was the RIGHT notification to listen to.
I understand how these issues are addressed when I am writing the code in a standard imperative manner. How are these addressed by AOP?
- Production
2003-05-30 13:33:15 patriot1burke [Reply | View]
You haven't clearly defined your requirements here. Can you elaborate?
There is a bunch of ways you could implement this pattern.
1) Add a interceptor that broadcasts a generic message "notify(className, methodName, args, response);" and attached via a pointcut
2) Add an interceptor per notification type which is attached via a separate pointcut for each notification type.
3) Use our AOP runtime interface and have subscribers register specifically for notifications on a per instance basis.
With JBoss AOP, you can apply interceptors solely to one specific object instance at runtime. So subscribers can register themselves in the traditional Listener manner, but Publishers don't have to be architected ahead of time to be publishers.
- Production
2003-05-31 09:36:55 anonymous2 [Reply | View]
Is there a manual you can point to?- Production
2003-06-02 05:56:35 warjort [Reply | View]
There is html documentation included in the
download.
Regards,
Adrian
- Production
- Production
- Production
- Production
- Production
- Answering your well-founded skeptism
2003-05-29 20:29:01 patriot1burke [Reply | View]
"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?"
XDoclet with JDK 1.4, JSR 175 with JDK 1.5 declares the behavior you want. AOP provides the glue for system level constructs. For JBoss AOP + XDoclet now?
/**
* @jboss-aop.metadata group="transaction" trans-atribute="Required"
*/
public void somePOJOMethod()
You write simple basic database logic, define simple metadata tags for the transactional behavior you want, and AOP glues in the appropriate system-level code.
I mean its just plain ridiculous that for EJB you have to spend money on fancy IDE or generate mounds of code to get that kind of simplicity. Tools aren't the answer. To reduce complexity the architecture has to change.
C# has it right with with their metatags, JSR 175 is playing catchup. For now, JBoss AOP metatags + XDoclet can provide this type of declarative programming.
"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."
You should be able to. Line numbers and debug info is preserved.
"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."
Defeating what point? That to get simple transaction demarcation you have to write a Home, Remote, and EJB class, an ejb-jar.xml file, and a vendor specific deployment descriptor and package it within a jar?
With Declarative programming and AOP as the glue, we have a real chance to really simplify things. Not through some fancy, expensive IDE, but through the language and framework itself. Go look at .Net and you'll see what I mean.
"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?"
Like any good component writer, the aspect writer needs to think and solve these types of issues. You're in luck. JBoss has been built on interceptor technology since 2000. JBoss AOP security leverages this technology.
"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."
I too have a lot of production work under my belt. Besides actually implementing many parts of the specs themselves, I've applied DCE, CORBA, and J2EE to various in-production applications over the years.
These specs are VERY useful for the functionality they define, but really get in the way of writing actual application code.
"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:"
Have you written EJB's? Then you've applied the fundamentals of Aspect Oriented Programming. Sure, EJB is pretty static, but think about what you're doing when you're writing a bean. You're applying system aspects to a class.
"1) What is the compelling value."
Simplicity and flexibility. A better, simpler contract between the system developer and application developer. A layered approach to programming without the syntactic sugar.
2) What are the pros and CONs
The biggest concern I have is: Will you be able to determine what is actually going on? This is where tools will have to come in the picture.
The biggest con is that AOP provides too much flexibility. The hurried, lazy, or ignorant programming could use AOP to bandaid their code, instead of iterating and producing a better design.
3) What are the killer applications.
Iona's Corba implementation, Orbix 2000, was written on interceptor technology, and so is JBoss. Rickard Oberg's company is building a CMS system upon AOP with success (www.dreambean.com).
I guess, the first killer applications will be applications like JBoss that leverage AOP to provide J2EE and beyond J2EE functionality to POJOs. AOP fits very very nicely in implementing and applying frameworks like J2EE and CORBA.
"4) OOP was a better mapping from the real world to the software world. Does AOP provide an even better mapping. If so, how?"
As I said above, I think AOP fits best with system level constructs. The only application-level aspect I can think of now is Billing.
"These issues need to be addressed before you can realize this vision of AOP leading the technology wave over the next 15 years."
AOP names patterns that many software developers have been applying for years and encapsulates them within various frameworks.
"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'."
When we ran into the definition of AOP early last year, we were like, "Heck, we've been doing this type of stuff for years! We could really bring our technology to POJOs!" Hence JBoss4.
OnJava willing, I plan on writing a follow-up article showing how you can apply system-level aspects of JB4 to POJOs. Until then, visit www.jboss.org. We're applying AOP in a multitude of different ways!
BTW, these are great questions! Skeptics are needed otherwise you end up with crappy code and frameworks.
Regards,
Bill
- Answering your well-founded skeptism
2003-05-29 23:49:06 anonymous2 [Reply | View]
I appreciate the conversation we are having. This is potentially the most targeted response that I have ever seen about aspect oriented programming.
Some responses:
Most importantly you say: "OnJava willing, I plan on writing a follow-up article showing how you can apply system-level aspects of JB4 to POJOs." I too would like to see another article on AOP, but I would rather see you address these fundamental issues about what it's good for, what it's not good for, where it fits into the architecture, at a high level. NO CODE. I know the 'no code' thing is against all that O'Reilly stands for, but really, a conceptual and architecture article is required once and a while. Not all concepts are best taught in 9pt Courier.
Let me put it a different way. You are too close to the oven because you are assuming a great deal from your readers. I work in a well known software company (not M$) with a great team of bright engineers. I took an informal poll after I started this thread yesterday. Of the fifteen I talked with, only five knew of the term 'aspect oriented programming'. None could define it as to what it mean or it's use.
The article you have here skips right over 'what is AOP', jumps over 'what is it good for', ducks straight around 'what are the advantages and disadvantages', and heads straight into 'this is how it works, here is a little command line song and dance'. You left 99% of the audience at the door. Notice that only two people responded to your article the first day. An article on the front page of OnJava and listed above the fold!
Ok, now off my soapbox and into your very kind response:
"Will you be able to determine what is actually going on?" - Yeah, this goes right to the heart of my debugging issue. I can see it right now. A couple of months into the the project everyone is happy. AOP is running cool and snappy. Then at crunch time when the bugs are flying around like mad people will be banging their heads into walls trying to figure out "what is actually going on", and ripping out aspects left and right to get back to "real code".
Much like threads, I can see AOP turning good code into chaotic goo where engineers return from three day bug hunts with five mile stares mumbling "I stared into the abyss and it stared back."
"the first killer applications will be applications like JBoss that leverage AOP to provide J2EE and beyond J2EE functionality to POJOs" - So if this is the killer app, then why not write it and talk about that as the article? Why is it the next article? Certainly chromatic would have preferred that? Why go back a rehash the same old 'tracing and logging' story we have heard since the beginning of AOP. Honestly, if it did logging really well, it may be worth using just for that. Just because you have a new tool doesn't mean you need to apply it to everything. Perhaps we should be happy with AOP for logging and leave it at that. Remember Dave Thomas' "Golden Hammer" principle.
"AOP names patterns that many software developers have been applying for years and encapsulates them within various frameworks." - This is just the kind of statement that deserves a full article? Which patterns? Dependency? Observer? Oracle's Fastlane? ;-) (I just threw that last one in for my own kicks.)
"EJB is pretty static, but think about what you're doing when you're writing a bean. You're applying system aspects to a class." - Yeah, I understand AOP (well, at least I think I do), and I certainly understand EJB (though it's not a pleasant thought). But I don't understand this statement. Again, another thing to address in an article. Summarized as, "how is what I am doing today akin to using aspect oriented programming?"
"With Declarative programming and AOP as the glue, we have a real chance to really simplify things. Not through some fancy, expensive IDE, but through the language and framework itself. Go look at .Net and you'll see what I mean." - I have looked at with and worked with .NET and as always, Microsoft knows how to build a fast block query architecture. They also know that you can map a table to one class. Unlike J2EE which takes five classes and two interfaces per table. But all you really need to get to the .NET is to use straight POJOs talking to JDBC. I just looked up "Apsect Oriented Programming" on the MSDN, "No Topics Found". Microsoft doesn't think the need AOP to have solid and simple data access in C#. Do you think Java that different?
"Rickard Oberg's company is building a CMS system upon AOP with success" - This would make for a fascinating case study to get people on board with AOP.
"The biggest con is that AOP provides too much flexibility." - Seriously, here are some cons:
* Maintenance programmers won't know AOP from ASP and will reak havoc.
* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
* You can have hairy aspect ordering problems.
* There are issues getting aspects to talk between each other.
* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* Aspects can cross component boundaries freely, with adverse effect.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release.
Saying that the only downside of a new technology is that it allows "too much flexibility" is glossing over reality. If you want to see engineers you have to be up-front about the technology warts and all. Every technology has problems.
Expecting that you can just take a technology with as much power as AOP and walk it into any production shop, lay it one the table and say 'bye' and have everyone use it is unrealistic. You have a lot of educating to do and process to indocrinate before you succesfully deploy AOP.
Again, thanks for the conversation. It's been great. I'd love to see AOP take off, and it's going to take conversations like this that educate, inform and address the misoneism indocrinated into software engineers.- Answering your well-founded skeptism
2003-05-30 07:22:47 patriot1burke [Reply | View]
""Will you be able to determine what is actually going on?" - I can see it right now. A couple of months into the the project everyone is happy. AOP is running cool and snappy. Then at crunch time when the bugs are flying around like mad people will be banging their heads into walls trying to figure out "what is actually going on", and ripping out aspects left and right to get back to "real code"."
We've written a GUI management console so that you can see what aspects have been applied to any given class at runtime. Many of the aspects we're writing for JB4 are triggered by metatags declared using XDoclet tags right in the source. GUI + declarative XDoclet tags bring aspects out right in the open.
"I just looked up "Apsect Oriented Programming" on the MSDN, "No Topics Found"."
You didn't look hard enough. http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx
"* Maintenance programmers won't know AOP from ASP and will reak havoc.
* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release."
PLEASE! Replace aspect or AOP with your favorite methodology (OOP etc..), acronym (EJB, CORBA), or language (C++, Python, Java) and you can apply the generalized statements you make above really to anything in software development.
But other statements, I will address.
"* You can have hairy aspect ordering problems."
Yes this is an issue. JBoss AOP provides some mechanisms for this, other AOP frameworks do the same. Go to our website or another AOP frameworks' website.
"* There are issues getting aspects to talk between each other."
Not a problem with JBoss AOP at least with a single full remote or local invocation which is why we have an Invocation and InvocationResponse object in the first place. ThreadLocals are also useful as well.
"* Aspects can cross component boundaries freely, with adverse effect."
Then don't use a regular expression to apply your aspects and/or rely on pointcuts triggered by metatags. Apply aspects declaratively on a per-class basis.
Although this is non-documented, in JBoss AOP we are also experimenting with the idea of an abstract AOP container so that pointcuts can be applied across groups of different instances rather than forcing pointcuts at the class level.
One of the things I wanted to drive JBoss AOP is real-world requirements. I want all functionality of JBoss AOP to be driven by use cases, not some academic ivory tower phd thesis. JBoss 4 implements a bunch of powerful aspects that have actually driven the underlying framework itself. We are currently using it also to implement EJB caching and optimized HTTP session replication. In other words, we are eating our own lunch.
I'm sorry the article did not meet your expectations. Personally, I need to see some simple examples in action before I can really understand how something can be used. When opening a tech book, I usually skip the BS in the first few chapters and go directly to the meat, but that's just me. Spare me the "blah blah blah", just show me the damn code!
On a side note, its funny. Recently, we were talking to an AOP expert who generally writes articles and papers on AOP about reviewing and making suggestions on our codebase, his response was "I'm allergic to code." I'll leave the "conceptual and architecture article"s to those allergic to code.
All and all, thanks for the exercise. Its good practice and helps me refine the message.
Bill
- Answering your well-founded skeptism
2003-05-30 10:48:53 anonymous2 [Reply | View]
I'll have some specific comments, but I'd like to center my response around the educational aspects of your response.
First, let me again prove my case that you have an education problem with AOP. Once again, my own informal poll, the only information that I have, on knowledge about AOP tells me that ZERO percent of engineers around me understand AOP. ZERO.
And in the time since we have started this conversation the sun has risen and set on Japan, Australia and India, and nobody in any of those places chose to respond to your article.
Must I make my case any more plain? You have an adoption and education problem with AOP. If you want AOP to take off it's your job as a member of the AOP community to be an advocate for the technology. Statements such as: 'Spare me the "blah blah blah", just show me the damn code!' betray a lack of understanding about your audience. You cannot assume knowledge of AOP. Period.
The article you mention (which is not on the CD version of the MSDN):
http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx
Is interesting because it spends six paragraphs and a graphic explaining AOP and giving links before it "show(s) me the damn code!"
Is there no place for a pragmatist, like yourself, to write articles on pragmatic, but high level, approaches to actually using AOP in production? Why must all of the AOP articles either be ridiculously abstract, or nose deep in th code?
Comments or your other comments:
Your assertion that I can "apply the generalized statements you make above really to anything in software development" is both right and wrong. These problems occur in other environments but they are more acute in AOP because nobody knows AOP. Let's look at them again, so that you can understand them before you brush them off:
* Maintenance programmers won't know AOP from ASP and will reak havoc.
This has a real world case in point. When the first qsort algorithm was implemented it was ripped out by maintenance engineers that didn't know what it was or how it worked. I have proven that nobody knows AOP or how it works. Thus it will be ripped out by maintenance engineers with bugs to fix.
* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
You missed the point. Aspects can INVISIBLY insert code from other areas of the program into your code. This is disconcerting at best. It's also a pain to debug as you invoke a method in one place then attempt to trace into that method invocation and crash before you get there. Why? Because an aspect has patched the method invocation in the byte code.
* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release.
These two address the system-wide changing nature of AOP which is unique to AOP. When you change a base class in OOP you can understand readily the number of test cases you are having an impact on. The same is not so clear on wide-spread aspects.
"One of the things I wanted to drive JBoss AOP is real-world requirements. I want all functionality of JBoss AOP to be driven by use cases, not some academic ivory tower phd thesis." - This is a good sign. Perhaps we as customers of JBoss would like to know just what those use cases are so that when can ensure that our architectures match the design that you are creating.
"Its good practice and helps me refine the message." - Ok, but what is the message? "Here is some code?" Read it and be in awe? Messaging and articles are supposed to inform and educate. The important part is the Times New Roman bits stuck between the code fragments. The code is meant to be an illustration!
- Answering your well-founded skeptism
2003-05-30 13:08:41 patriot1burke [Reply | View]
"First, let me again prove my case that you have an education problem with AOP. Once again, my own informal poll, the only information that I have, on knowledge about AOP tells me that ZERO percent of engineers around me understand AOP. ZERO."
I agree that there is an education problem, but it is not as bad as you think. I recently gave a JBoss presentation at the NEJUG in front of about 400 people. I spent about 1-2 slides on JBoss 4 and AOP out of 60. I was hit with a flood of questions by about 5-10% of the audience. Not questions like, "what is AOP?" but rather, "How are you applying it?" "How did you implement it?" "Are you using AspectJ?" "Why not?" etc.
I thank you for your literary critism and will take them into account the next time I write an AOP article.
"* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
You missed the point. Aspects can INVISIBLY insert code from other areas of the program into your code. This is disconcerting at best. It's also a pain to debug as you invoke a method in one place then attempt to trace into that method invocation and crash before you get there. Why? Because an aspect has patched the method invocation in the byte code."
We only weave enough byte code so that it can hook into the framework. All the inserted bytecode does is package the method arguments into an object array and passes it along to a AOP framework class that manages the interception.
All aspects are written as Java objects, so you will be able to see these interceptors in stack traces when exceptions are thrown. Since the bytecode insertion is very minimal this will stabalize quite quickly if it hasn't already. And you can still step through with a debugger.
"* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release.
These two address the system-wide changing nature of AOP which is unique to AOP. When you change a base class in OOP you can understand readily the number of test cases you are having an impact on. The same is not so clear on wide-spread aspects."
If this is a worry, refrain from defining pointcuts using a generic regular expression. Or maybe regular-expression based pointcuts should be removed from the framework entirely?
Use metatags to trigger the application of an interceptor rather than a pointcut. With JBoss AOP, you can use XDoclet at first (then later JSR-175 when its ready to) to articulate behavior and bind aspects implicitly.
i.e.
/**
*
* @jboss-aop.meta-tag group="transaction" trans-attribute="RequiresNew"
*/
public void someMethod() {...}
The above would trigger the addition of a transaction interceptor
But, yes, until you can right-click on a pointcut definition within an IDE and find out what classes are affected, then some aspects ;-p of AOP will have some disadvantages(we're working on Eclipse integration as well). Until then, at least with JBoss-AOP, you'll have to find out how aspects are glued at runtime through our management console.
""Its good practice and helps me refine the message." - Ok, but what is the message? "Here is some code?" Read it and be in awe? Messaging and articles are supposed to inform and educate. The important part is the Times New Roman bits stuck between the code fragments. The code is meant to be an illustration!"
One is no less important than the other.
I learn by example, I teach by example. The example in the article is the cross-cutting concern of tracing. I apologize if you don't find my Times New Roman up-to-par. I will try to do better next time.
Bill
- Answering your well-founded skeptism
2003-05-31 09:39:38 anonymous2 [Reply | View]
Ok, thanks for the conversation. I've learned a lot and you have been very tolerant of my interrogation style.- Answering your well-founded skeptism
2003-07-02 02:17:35 anonymous2 [Reply | View]
This is the best thread on AOP I've read so far.
Thank you, both.
-jjr- Answering your well-founded skeptism
2003-08-04 14:45:03 anonymous2 [Reply | View]
I ended up with this thread not after reading the article but when I started evaluating AspectJ Vs JBoss AOP.
I found this discussion thread very useful, it had a lot to read. I have a feeling that over the period of time JBoss AOP framework will improve in every respect. Well, I think I should get started with JBoss AOP leaving AspectJ aside.
I am still skeptical about the ClassLoader issue, what is roadmap for JBoss AOP framework, will the class loader dependency be removed in future. How easy it would be to migrate JBoss AOP enabled Applications to other J2EE App Servers like Weblogic, WebSphere...
I would love to see Eclipse integration, if it is already available where can I find it.
Pardon me, if my question looks stupid.
-Yogesh Prajapati
- Answering your well-founded skeptism
- Answering your well-founded skeptism
2003-06-02 04:58:15 anonymous2 [Reply | View]
Certainly, he has been very tolerant with you!- Answering your well-founded skeptism
2003-06-03 02:56:56 anonymous2 [Reply | View]
I loved the article. First time I've understood what AOP is about (not that I have tried that hard).
At project start up the issues are always:
How do we do error handling
How do we do logging
How do we do internationalization
How do we persist data
How do we ensure it runs, and bounces back if it dies.
AOP can answer quite a few of these. However, the next concern is:
How do we make sure it works quickly and robustly.
And here I side with the red flag - I can't see the code, and I worry like hell that it will create far more trouble for me than doing it myself with simply high level language constructs that I know work.
So what if its a little extra typing, typing is easy.
Jonathan- Answering your well-founded skeptism
2003-06-03 09:00:25 anonymous2 [Reply | View]
Here's a link to another interesting article on AOP, actually EAOP, that doesn't use logging as an example:
http://www.emn.fr/x-info/sudholt/papers/tr-11-2002.pdf
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Answering your well-founded skeptism
- Production
- Logging and tracing code
- Logging and tracing code
- Logging and tracing code
Do you want secured/transactional/clustered pojo?
This is already exists with jboss4
Regards,
Adrian