Discussions

News: Tech Talk with Bill Burke about ongoing work on JBoss

  1. In this latest tech talk, JBoss Chief Architect Bill Burke discusses some of the ongoing work at JBoss including new aspects in JBoss AOP, annotations support, contributions to EJB 3, JBoss Cache, a new server-less version of JMS, and more. The new Asynchronous aspect would allow one to mark a method as asynchronous rather than write MDBs/handle JMS.

    Watch Bill Burke about ongoing work at JBoss.

    Threaded Messages (75)

  2. Two questions[ Go to top ]

    I am trying to understand the following two points.

    AOP standardization.

    What is meant by this ? I don't know of any OO standardization efforts.

    I saw one question about the 'Paradigm shift'.

    Are there two major AOP proponents ? One with a bytecode engineering view and the other with a 'Paradigm shift' view.
  3. AOP Standardization[ Go to top ]

    I am trying to understand the following two points.AOP standardization.What is meant by this ? I don't know of any OO standardization efforts.I saw one question about the 'Paradigm shift'.Are there two major AOP proponents ? One with a bytecode engineering view and the other with a 'Paradigm shift' view.

    When I did this interview, Gregor Kiczales wanted to start a AOP Standardization effort. Unfortunately, the effort never really got started.
  4. The problem with JBoss is of a kind of paradoxal nature:
    it has tones of stuff that I doubt being used widely (AOP stuff,etc)
    but ,at the same time, it lacks very essential enterprise features, mainy:
    1- Complete transactional infrastructure
    2- Robust, scaleable, non-trivial JMS implementation
    Point#1 is what I think prevents JBoss being enterprise-ready.
    Without a reliable transaction system, JBoss remains mainly a development
    ,testing and non-mission critical tasks server. And it has serious alternatives(Tomcat,Jetty,etc) in
    this arena with the rise of light-weight container-based design approaches

    Point#2 is not peculiar to JBoss, even WebLogic has the same problem
    (They are claiming of fixing this in Diablo). But even then, the real
    problem is that JBoss bandits show no interest whatsoever to integrate
    their server seriously with high-quality JMS(e.g ActiveMQ). Instead
    they pour their energy into "sexy stuff" like asynchronous method
    invocations aspects!!!

    As it is discussed in a past theserverside thread, three reasons come to mind
    to understand this paradoxial situations
    1- These guys are not aware of this situation. They are just blind, ignorant. Then I hope this post will help them realize the situation
    2- They are aware of the situation but are unable to make anything
    that will heal it: Probably due to lack of skill and knowhow. If so lets
    prey for them
    3- They intentionally do this in order to gain a few buckets out of
    consulting busines and deals they make with vendors like Arjuna.
    What can I say : it is what they understand from "professional open-source"
  5. Right On Cetin[ Go to top ]

    Right On Cetin! I wish the J2EE community had more critics like you instead of those lazy guys at JBoss.
  6. fud[ Go to top ]

    cetin affiliated with activemq, why it high quality u say ? can u explaining why it high quality and prove please ?
  7. Pardon my ignorance, but what do you mean by "Complete transactional infrastructure" ? And what exactly features is JBoss lacking ? Thanx in advance
  8. This means that JBoss does not have transaction logging. Mike Spille explains what is all about here: http://jroller.com/page/pyrasun/Weblog?catname=%2FXA . Shortly, this could be resumed to this scenario: you have a 2pc commit and JBoss transaction manager sends "prepare" to the involved XAResources (who log the transaction in their logs). Now, a power outage occurs and when the system comes up again, it does not send any "recover" message to the XAResources, because it does not have a transaction log. So you have a lot of locks in your database that are held for a long time. Some other transactions won't work because they need the locked resources and the whole thing escalates until the db admin performes some manual recovery.
  9. I haven't seen cases where the DB and appserver are located in different ISP's, so I don't see how that specific scenario applies to real life. In all the cases I've seen first hand, the database and application server are both located in the same building. Therefore, everything crashes, including the Database. In reality, Tier 1 ISP's have heafty backup generators that can last 2-3 weeks, so a power outage taking down an application server is rather unlikely. It is more likely for a bug to brind down the app server than a power outage. Of course that doesn't mean JBoss handles recovery correctly/incorrectly.
  10. This means that JBoss does not have transaction logging. Mike Spille explains what is all about here: http://jroller.com/page/pyrasun/Weblog?catname=%2FXA . Shortly, this could be resumed to this scenario: you have a 2pc commit and JBoss transaction manager sends "prepare" to the involved XAResources (who log the transaction in their logs). Now, a power outage occurs and when the system comes up again, it does not send any "recover" message to the XAResources, because it does not have a transaction log. So you have a lot of locks in your database that are held for a long time. Some other transactions won't work because they need the locked resources and the whole thing escalates until the db admin performes some manual recovery.

    I have written a recovery prototype in cvs and Adrian Brock and I have had some discussion on how it should be implemented on our JTA forum. The prototype is only partially tested and probably a bit naive. We're looking for somebody to drive this impl, so if you're interested, let me know.

    If you need recovery now, you can use Arjuna's or Iona's TM. They integrate pretty well with JBoss. If you are using only one XAResource in your application, then you do not need 2PC and recovery. BTW, 2pc is an EXTREMELY expensive protocol and applications should design themselves not to use it. I know...this is not always possible, but see the solutions above and below in this reply.

    Also, I don't know the status of JOTM, but the next version is supposed to support recovery. Alberto Jimenez has done some work integrating JOTM with JBoss. I'll post the info on our Wiki when I get a chance. If anybody is interested in taking JOTM+JBoss integration as a task, please contact me and I can send you the details.

    Bill
  11. Cetin

    While there definitely are App Servers on the market that include a JMS server just to be J2EE compliant, the implication that the internal JMS server in WebLogic is not enterprise-ready is not justified. I have worked with lots of customers that are using it in production without problems.

    In my experience, most WLS applications use external JMS servers (e.g. MQSeries, Tibco) when these servers are already in place and are required for accessing certain back office systems. In cases where connectivity with external JMS servers is needed, WebLogic 8.1 also includes a messaging bridge to integrate with any JMS server as well as an MQSeries Control to communicate with MQ via native protocols.

    All this can be done today with very reasonable throughput and scalability (load balancing). You can even failover JMS messages, although there are manual steps involved.

    There are tons of enhancements to JMS in Diablo, including improved performance, monitoring and failover. The messaging bridge has also be optimized to improve integration with other JMS servers. These enhancements will certainly help customers who are using JMS at the core of their applications, both in reduced HW requirements and reduced administration.

    By the way, I'm curious to understand why you consider ActiveMQ a high-quality JMS implementation and WebLogic JMS a trivial technology. Performance? Configuration? Monitoring? Protocol support? Client support? Never having used ActiveMQ, I honestly don't know what makes it better for your use cases. What do you see as necessary in WebLogic JMS to make it "enterprise-ready"?

    Peace in the new year...
  12. By the way, I'm curious to understand why you consider ActiveMQ a high-quality JMS implementation and WebLogic JMS a trivial technology.

    I don't understand it either. A mature JMS system needs *years* in the field in production, used by *many* customers. ActiveMQ is just an early 1.* release. It's certainly not a production ready system (I mean *real* production).

    I don't know if it's better than JBossMQ. I doubt that.

    And, btw, it's a commercial project. The business model behind is just like that of JBoss. It's only backed by another company, Protique. For this reason, I'm wondering why the could run the TCK against ActiveMQ? IMO this is not allowed, because it's not a Apache project. So actually they would have to pay for the TCK just like JBoss had to pay but they don't.

    Happy New Year.

    -- Andreas
  13. By the way, I'm curious to understand why you consider ActiveMQ a high-quality JMS implementation and WebLogic JMS a trivial technology.
    I don't understand it either. A mature JMS system needs *years* in the field in production, used by *many* customers. ActiveMQ is just an early 1.* release. It's certainly not a production ready system (I mean *real* production). I don't know if it's better than JBossMQ. I doubt that.And, btw, it's a commercial project. The business model behind is just like that of JBoss. It's only backed by another company, Protique. For this reason, I'm wondering why the could run the TCK against ActiveMQ? IMO this is not allowed, because it's not a Apache project. So actually they would have to pay for the TCK just like JBoss had to pay but they don't.Happy New Year.-- Andreas

    I'd like to put a word in for ActiveMQ. Although I haven't used it in production, I did do some testing with the new JMS Sampler I wrote for JMeter. In the tests I ran, ActiveMQ performed well. When you consider it's still the first release, it's pretty darn impressive. Also, lets not forget that James used to work at SpiritSoft and has a couple of years of experience writing JMS systems. The nightly build of JMeter has a JMS sampler now, so it should be a little bit easier to benchmark JMS servers.

    During the development process, I tested the sampler against Orion, ActiveMQ and OpenJMS. ActiveMQ was faster than the other two. I still haven't had time to run the benchmark I had in mind, since setting up the servers take time. My bias opinion is ActiveMQ is ready for production environments, but the catch is I would only do that after running stress tests on a real application to make sure the performance meets my requirements.
  14. Also, lets not forget that James used to work at SpiritSoft and has a couple of years of experience writing JMS systems.

    Right. If I were from SpiritSoft, I would let my lawyers take a hard look on every line of that code.

    -- Andreas
  15. Also, lets not forget that James used to work at SpiritSoft and has a couple of years of experience writing JMS systems.
    Right. If I were from SpiritSoft, I would let my lawyers take a hard look on every line of that code.-- Andreas

    James has worked at SpiritSoft, prototyping the SpiritWave message framework (which provided a JMS abstraction layer over Tibco/Talarian/MQSeries and others) and providing the ground work on SpiritSoft's caching product, SpiritCache.

    James was not directly involved in writing our SpiritWave messaging system, and having looked through all the code for ActiveMQ, I an more than happy that it's not based on SpiritWave.

    Rob Davies
    CTO
    SpiritSoft
  16. Hey Andreas -- I see management is alive and well at SwiftMQ!

    Hey did you ever work up in Redmond?
  17. there you have it[ Go to top ]

    right from SpiritSoft. ActiveMQ is clean, so there's no need to spread FUD. I've only read a small part of ActiveMQ, but it's pretty solid. About the only thing I would like to see is a full JNDI server, so that I don't have to use properties file. But that's really a minor issue, especially if ActiveMQ is embedded in another container. but that's my bias perspective.
  18. there you have it[ Go to top ]

    ActiveMQ is clean, so there's no need to spread FUD.

    That wasn't FUD. It was what *I* would do if an ex-employee from us would start with a product which is similar to ours.

    Anyway, it is even more interesting to me why James uses the J2EE TCK to run it against ActiveMQ although he or his company is not a J2EE licensee and ActiveMQ is not an Apache project. What is the legal base for this?

    -- Andreas
  19. wouldn't that be obvious?[ Go to top ]

    SpiritSoft is respected in the industry. Reviewing ActiveMQ would definitely part of due diligence in my mind, so assuming that SpiritSoft wouldn't take time to review ActiveMQ doesn't sound like a good excuse to me. If there was an issue with ActiveMQ, it would have happened when james released it. It's the duty of all programmers to follow ethical conduct, even if it means writing stuff from scratch to make sure no copyrights are violated.
  20. there you have it[ Go to top ]

    Andreas Mueller :
    For this reason, I'm wondering why the could run the TCK against ActiveMQ?

    Speaking with my Apache hat on :

    James has access to the J2EE TCK as a member of the Geronimo project. Of course, we can't say what parts pass, because we can only pass/fail the entire suite. However, I can't recall a claim made by Protique or the ActiveMQ project about compatibility.
    Anyway, it is even more interesting to me why James uses the J2EE TCK to run it against ActiveMQ although he or his company is not a J2EE licensee and ActiveMQ is not an Apache project. What is the legal base for this?-- Andreas

    The Geronimo project collaborates with many other peer projects, such as ActiveMQ from Codehaus, OpenEJB, Howl and others from ObjectWeb, and we use what we need in building the Geronimo J2EE Application Server. So yes, ActiveMQ is being tested as part of the whole Geronimo J2EE stack.

    --

    That said, there are products based on ActiveMQ, like JOE produced by my employer, Gluecode Software. JOE passes the the independent JMS TCK, for which Gluecode is a licensee.

    Also, next time it would be curteous for you to have identified yourself as the managing director of SwiftMQ.com, a commercial JMS provider, for those of us that didn't know.

    geir

    (both a member of the Apache Geronimo project, and employee of Gluecode Software)
  21. geir u spreading the fud[ Go to top ]

    why my dear, u also taking advantage in other ways ... we can seeing this..
  22. geir u spreading the fud[ Go to top ]

    "The Dude" :
    why my dear, u also taking advantage in other ways ... we can seeing this..

    My darling, where's the FUD? Do you understand what the term means?

    Yes, I did a plug for a commercial product that I'm associated with in as far as I said that the product passed a test suite...

    - geir
  23. geir u spreading the fud[ Go to top ]

    why my dear, u also taking advantage in other ways ... we can seeing this..

    I thought that [professional open source] astroturfing was disallowed .. maybe you [213.38.69.82] didn't get the memo?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  24. purdy turdy purdy[ Go to top ]

    my dear boy, where u getting this ip from ? you must be very bery clever unless the tss club you part of where you all enjoying genitilia tug fest must be giving you special favours eh ?

    if you checking my ip (here is tip, go to maxmind) i comming from the england, so maybe i can say this is wrong and u indeed confirm by spreading the fud

    " I thought that [professional open source] astroturfing was disallowed .. maybe you [213.38.69.82] didn't get the memo" ..
  25. purdy turdy purdy[ Go to top ]

    my dear boy, where u getting this ip from ? you must be very bery clever unless the tss club you part of where you all enjoying genitilia tug fest must be giving you special favours eh ?

    No, I'm not very clever. Every packet your computer sends onto the Internet has a sending IP address and a destination IP address in the first eight bytes of the IP packet header.

    How I *may have* figured out your IP address (remember, it's just a random guess) is another story, but I didn't have any help from anyone at TSS.
    if you checking my ip (here is tip, go to maxmind) i comming from the england, so maybe i can say this is wrong and u indeed confirm by spreading the fud

    One of us is posting under our real name.

    The other is a coward hiding behind a month-old anonymous account.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  26. u bery clever man[ Go to top ]

    oh my, u very bery clever and knowing alot. please teaching me your super technique.
  27. there you have it[ Go to top ]

    Speaking with my Apache hat on :James has access to the J2EE TCK as a member of the Geronimo project. Of course, we can't say what parts pass, because we can only pass/fail the entire suite.

    Yes, and he didn't ran only the JMS part against ActiveMQ. Noooo! This is freeloading, just that. Cadger!
    Also, next time it would be curteous for you to have identified yourself as the managing director of SwiftMQ.com, a commercial JMS provider, for those of us that didn't know.

    I think most people know me here. I'm not someone who stamps his post with plugs.

    -- Andreas
  28. there you have it[ Go to top ]

    Adreas :
    Speaking with my Apache hat on :James has access to the J2EE TCK as a member of the Geronimo project. Of course, we can't say what parts pass, because we can only pass/fail the entire suite.
    Yes, and he didn't ran only the JMS part against ActiveMQ. Noooo! This is freeloading, just that. Cadger!

    Where are you getting this information from?
    Also, next time it would be curteous for you to have identified yourself as the managing director of SwiftMQ.com, a commercial JMS provider, for those of us that didn't know.
    I think most people know me here. I'm not someone who stamps his post with plugs.-- Andreas

    I didn't.

    It really wasn't a plug as much as I was noting that software based on ActiveMQ does pass the JMS TCK. I just felt it proper to a) note the name of the product and b) note that I am an employee of the company producing that product.

    - geir
  29. there you have it[ Go to top ]

    Speaking with my Apache hat on :James has access to the J2EE TCK as a member of the Geronimo project. Of course, we can't say what parts pass, because we can only pass/fail the entire suite. However, I can't recall a claim made by Protique or the ActiveMQ project about compatibility.

    I think what you do is illegal.

    James, as from Protique, hasn't access to the TCK. In fact, it is illegal for a J2EE licensee to pass results of the TCK to a non-licensee. As you said, you can only say the suite passes as a whole or not but you cannot tell him the results of the JMS selector tests to fix it in ActiveMQ. He may also not view the test results as an Apache member and use it to fix bugs in ActiveMQ.

    So actually James cannot be an Apache member as long as this means that he has access to the TCK. That clashes with your duties as J2EE licensee.

    -- Andreas
  30. there you have it[ Go to top ]

    Speaking with my Apache hat on :James has access to the J2EE TCK as a member of the Geronimo project. Of course, we can't say what parts pass, because we can only pass/fail the entire suite. However, I can't recall a claim made by Protique or the ActiveMQ project about compatibility.
    I think what you do is illegal. James, as from Protique, hasn't access to the TCK. In fact, it is illegal for a J2EE licensee to pass results of the TCK to a non-licensee. As you said, you can only say the suite passes as a whole or not but you cannot tell him the results of the JMS selector tests to fix it in ActiveMQ. He may also not view the test results as an Apache member and use it to fix bugs in ActiveMQ. So actually James cannot be an Apache member as long as this means that he has access to the TCK. That clashes with your duties as J2EE licensee.-- Andreas

    Andreas, I think you're pretty well mistaken. Just to clear up the facts for you...

    * I'm an Apache member and have been for a few years now
    * I'm a founder and committer on the Geronimo project
    * I've signed Sun's NDA for the TCK and am in the Geronimo TCK testing group
    * I can run the TCK tests on Geronimo completely legally and comply fully with Sun's NDA - and so I'm pretty careful about what I say about J2EE TCK compliance testing due to the NDA

    I hope that clears things up for you - there's nothing illegal going on here.

    James
    Protique
    Enteprise Open Source
  31. there you have it[ Go to top ]

    I'm a founder and committer on the Geronimo project* I've signed Sun's NDA for the TCK and am in the Geronimo TCK testing group* I can run the TCK tests on Geronimo completely legally and comply fully with Sun's NDA - and so I'm pretty careful about what I say about J2EE TCK compliance testing due to the NDAI hope that clears things up for you - there's nothing illegal going on here.

    I think you are wrong. You cannot use the TCK results to fix bugs in ActiveMQ. ActiveMQ is not an Apache project, not part of Geronimo. It is a commercial (although ASF licensed) project. Same model as JBoss so actually you would have to pay for a J2EE licence.

    -- Andreas
  32. there you have it[ Go to top ]

    I'm a founder and committer on the Geronimo project* I've signed Sun's NDA for the TCK and am in the Geronimo TCK testing group* I can run the TCK tests on Geronimo completely legally and comply fully with Sun's NDA - and so I'm pretty careful about what I say about J2EE TCK compliance testing due to the NDAI hope that clears things up for you - there's nothing illegal going on here.
    I think you are wrong. You cannot use the TCK results to fix bugs in ActiveMQ. ActiveMQ is not an Apache project, not part of Geronimo.

    ActiveMQ is a part of Geronimo; just as Jetty, mx4j, Howl, openejb, tranql, Spring, cglib are all parts of Geronimo despite none of them being hosted at Apache. Also Geronimo includes other Apache projects like Tomcat, Axis, XMLBeans, Cloudscape, commons-logging which are not part of the Geronimo source tree. The only requirement for what Geronimo can use is that it must be BSD/Apache licenced open source code.

    To help Geronimo certify, developers might have to patch any of these libraries (and as part of the certification effort we've probably had to patch most of them :)

    So I don't really follow your logic. Its Geronimo which is being certified at Apache.

    It is a commercial (although ASF licensed) project.

    Its still an open source library used by the Geronimo project - irrespective of whether companies provide commercial support (say, Protique) or companies embed it into commercial products (say, GlueCode's JOE).

    James
    Protique
    Enteprise Open Source
  33. there you have it[ Go to top ]

    You defend yourself but I'm pretty confident that you follow my logic. ActiveMQ is not part of the Geronimo source tree. You control it for the only reason to press money out of it. It's just the JBoss model.

    And you think that you can save your J2EE license fee by scrounging the TCK results from Geronimo which in my opinion is illegal.

    Your function as a committer of Geronimo and a patcher of ActiveMQ is certainly not compliant with the NDA. I'm sure you signed the NDA before you did publish ActiveMQ.

    Others would have to pay a lot of money for the TCK. And you scrounge it. That can't be tolerated.

    -- Andreas
  34. there you have it[ Go to top ]

    Andreas :
    You defend yourself but I'm pretty confident that you follow my logic. ActiveMQ is not part of the Geronimo source tree. You control it for the only reason to press money out of it. It's just the JBoss model. And you think that you can save your J2EE license fee by scrounging the TCK results from Geronimo which in my opinion is illegal. Your function as a committer of Geronimo and a patcher of ActiveMQ is certainly not compliant with the NDA. I'm sure you signed the NDA before you did publish ActiveMQ.Others would have to pay a lot of money for the TCK. And you scrounge it. That can't be tolerated.-- Andreas


    I realize I'm just feeding a troll here, but I really think you are way off base.

    1) The purpose of a TCK is to test compatibility of Java bytecode that claims to support a given JSR. The fact that information about non-compliance resulting from this testing is used as a basis for bug reporting or bug fixing is irrelevant. Anyone working with the J2EE TCK on Geronimo testing compatibiliy is allowed to use that information to fix bugs in the software that we use in Geronimo as long as proprietary information about or in the TCK isn't revealed (required by the terms of the TCK license) and the status of Geronimo's J2EE compatibility beyond pass/fail isn't disclosed.

    2) Gluecode Software [for which a) I am an employee and b) is a J2EE licensee, and c) also a licensee for the standalone JMS TCK] employed open source developers to help us get our binary that uses ActiveMQ to pass the JMS TCK. We contributed fixes for any non-compliance with the JMS spec back to the ActiveMQ project under the Apache License for all users to benefit from. However, this only means that Gluecode's JOE product passes the JMS TCK. Technically speaking, no conclusion can be drawn about the compatibiliy of any other binary based on ActiveMQ unless tested also by the JMS TCK (or J2EE TCK when part of the stack), and no conclusion about the compatibility of the ActiveMQ sourcebase can be drawn, as you can't test source, only binaries.

    3) There is no requirement for heterogenaity of source tree, or anything like that for using a TCK. In fact, the source is utterly irrelevant - a TCK tests a binary, and a binary only. (In fact, the binary should be separately certified for each JVM it will run on...) For example, there are many instances of open source software being included in commercial J2EE servers (and other JSR-implementing products) that are certified by commercial vendors. In the process of certification, I am nearly certain that information about bugs detected by the TCKs has made it's way back to the projects and fixes put in place. I think this is a very healthy thing.

    -geir
  35. there you have it[ Go to top ]

    I realize I'm just feeding a troll here, but I really think you are way off base.1) The purpose of a TCK is to test compatibility of Java bytecode that claims to support a given JSR. The fact that information about non-compliance resulting from this testing is used as a basis for bug reporting or bug fixing is irrelevant. Anyone working with the J2EE TCK on Geronimo testing compatibiliy is allowed to use that information to fix bugs in the software that we use in Geronimo as long as proprietary information about or in the TCK isn't revealed (required by the terms of the TCK license) and the status of Geronimo's J2EE compatibility beyond pass/fail isn't disclosed.

    Look, geir, I'm not a troll and this is the point:

    Let's say you would test Geronimo with another BSD/ASF licensed JMS DumbMQ. Nobody from the DumbMQ project is in your geronimo team. Let's say the TCK failed. How would you pass the information about bugs to the DumbMQ guys without disclosing anything beyond pass/fail?

    You can't!

    You can fork and fix but you can't not pass it back!

    -- Andreas
  36. worst thread yet![ Go to top ]

    Between Geir and Andreas and Cameron and "the dude" this thread has become absolutely useless. Either the TSS needs mediation or the dicussion needs to move to a site with better forum software so admins can keep discussions on track.

    Perhaps a site that used the technologies it advocates would be interesting (not saying TSS doesn't entirely, I'm talking about a site that uses a stack, perhaps with spring etc. similar to jroller - it eats it's own dog food and occasionally get sick because of it).

    Now I'm taking it further off topic ;)
  37. there you have it[ Go to top ]

    Andreas :

    Geir :
    The purpose of a TCK is to test compatibility of Java bytecode that claims to support a given JSR. The fact that information about non-compliance resulting from this testing is used as a basis for bug reporting or bug fixing is irrelevant.

     Let's say you would test Geronimo with another BSD/ASF licensed JMS DumbMQ. Nobody from the DumbMQ project is in your geronimo team. Let's say the TCK failed. How would you pass the information about bugs to the DumbMQ guys without disclosing anything beyond pass/fail? You can't!You can fork and fix but you can't not pass it back! -- Andreas

    I don't know if you do any opensource, but the way we do it both in the Geronimo project and at Gluecode is either report a bug ("I can't send an ObjectMessage when I do bloh...") or send them a patch. We do have programmers doing this...

    Take Jetty for example. Geronimo uses it, as does Gluecode JOE. We've submitted both bug reports and patches to the Jetty project for things that we found were wrong, and the people doing the testing in either case have no relationship to Mortbay Consulting, which is to Jetty what Protique is to ActiveMQ - a commercial organization deriving revenue from adding value and services to the open source projects.

    Yet those bugfixes and but reports were accepted, and Gluecode JOE passes the standalone servlet TCK.

    Clear?

    - geir
  38. Why don't you just call Sun?[ Go to top ]

    Here you go Andreas:

    US 1-800-555-9SUN
    International 1-650-960-1300
  39. there you have it[ Go to top ]

    Clear?- geir

    Sure, but it's you who don't understand.

    -- Andreas
  40. there you have it[ Go to top ]

    And to think that I actually considered buying SwiftMQ? After this pathetic display of unprofessional whining, I confess that I will never let that thought cross my mind (or the minds of anyone who asks me) again. My god, and you thought the JBossians were bad? "Whaaaaaaa! You're getting free testing, you're getting free testing! I would have to pay and you get it free!" Give it a rest.

    -Ravi
  41. there you have it[ Go to top ]

    And to think that I actually considered buying SwiftMQ? After this pathetic display of unprofessional whining, I confess that I will never let that thought cross my mind (or the minds of anyone who asks me) again. My god, and you thought the JBossians were bad? "Whaaaaaaa! You're getting free testing, you're getting free testing! I would have to pay and you get it free!" Give it a rest.-Ravi

    you cannot seeing the bushes from the trees little boy. too bad so sad, please going back to village in india
  42. there you have it[ Go to top ]

    And to think that I actually considered buying SwiftMQ? After this pathetic display of unprofessional whining, I confess that I will never let that thought cross my mind (or the minds of anyone who asks me) again. My god, and you thought the JBossians were bad? "Whaaaaaaa! You're getting free testing, you're getting free testing! I would have to pay and you get it free!" Give it a rest.-Ravi

    It happens from time to time that some poor web developer like you came out of his dirty Spring hole (hehe) and tries to threaten me. If that would be a problem for me or my company, I would not post under my real name. If you would know how successful SwiftMQ is, you would not try, believe me. SwiftMQ is not used because someone like me or not but because of its strength.

    Whining? No. I address an issue, that's all. If you don't want to read it, skip over!

    Thanks "the dude", I love you!

    -- Andreas
  43. it shouldn't affect your decision[ Go to top ]

    And to think that I actually considered buying SwiftMQ? After this pathetic display of unprofessional whining, I confess that I will never let that thought cross my mind (or the minds of anyone who asks me) again. My god, and you thought the JBossians were bad? "Whaaaaaaa! You're getting free testing, you're getting free testing! I would have to pay and you get it free!" Give it a rest.-Ravi
    It happens from time to time that some poor web developer like you came out of his dirty Spring hole (hehe) and tries to threaten me. If that would be a problem for me or my company, I would not post under my real name. If you would know how successful SwiftMQ is, you would not try, believe me. SwiftMQ is not used because someone like me or not but because of its strength. Whining? No. I address an issue, that's all. If you don't want to read it, skip over!Thanks "the dude", I love you!-- Andreas

    I wouldn't let one individual complaining represent an entire company. The reason I say that is because we're human and whining is part of life. Heck, I love to whine and moan, though I try to refrain from doing that on public forums. But back on the topic of TCK, if swiftMQ doesn't like non-profit orgs getting a better deal, than they should lobby Sun to either reduce the cost of TCK or charge non-profits for it.

    Every product has strengths and weaknesses. what is important is measuring it based on reproducible tests and whether it meets the functional requirements.

    peter
  44. it shouldn't affect your decision[ Go to top ]

    Peter Lin :
    But back on the topic of TCK, if swiftMQ doesn't like non-profit orgs getting a better deal, than they should lobby Sun to either reduce the cost of TCK or charge non-profits for it.Every product has strengths and weaknesses. what is important is measuring it based on reproducible tests and whether it meets the functional requirements.peter

    I'm not sure if that would satisfy Andreas. Suppose the ASF, ObjectWeb, and all the other non-profits, individuals and academics that are able to apply for the scholarship couldn't. Further suppose that the ASF paid for the J2EE TCK license (it's really support and brand management that's being charged for, but I digress..).

    What would change?

    We'd still provide bug reports and bug fixes to the projects we work with that implement JSRs. We'd still send bug reports and patches to ActiveMQ, Jetty, MX4J, JOTM, whatever. Nothing would change. Apache Geronimo is built using software from other projects, and we're happy to contribute back to those projects to make them better for all users.

    The value of a TCK isn't to show you were you screwed up, but rather to prove that the implementation is compatibile with the spec. This has value for users, whose code then isn't "surprised" by a misbehaving standard API. Spec compatbility isn't be a competitive differentiator, but the base requirement for a specific market. Compete on quality of implementation, or added features, or whatever, not that it manages to implement the spec that it claims to implement.

    geir

    p.s. Andreas : if you make SwiftMQ open-source under a license that we can use with Apache Geronimo, we'll send you bug reports and fixes too if someone decides to certify Geronimo w/ SwiftMQ. You could even volunteer to come over and do it. All volunteers welcome :)
  45. it shouldn't affect your decision[ Go to top ]

    so geir who would benefit most directly financially from this cloak/n/dagger /undercover / call-it-what-you-want operation ?

    obviously you won't cover this point as you are part of it aswell.
  46. it shouldn't affect your decision[ Go to top ]

    so geir who would benefit most directly financially from this cloak/n/dagger /undercover / call-it-what-you-want operation ?obviously you won't cover this point as you are part of it aswell.

    Which is the undercover part? Seems like everything is in the open here.

    Anyone who wants to use parts of or all of these projects to produce a product - say a commercial J2EE server based on Geronimo - still must get a J2EE TCK license from Sun, integrate their value-added pieces, and certify the resulting product. There is no "transfer of certification-ness". The benefit they get is the reduction of engineering needed, but this is a benefit of the commons - everyone gets to take advantage of this. This is the point of open source, right?

    If they just ship the certified version produced (now or in the future) by an open-source project, all they are is re-distributing. Plain re-distribution no longer is an interesting or lucrative business IMO. It's when there's value-add like support, management or additional features, like what JBoss or SpikeSource does, that you begin to see wealth creation.

    So I don't see it - what's the nefarious plot you see in this?

    - geir
  47. it shouldn't affect your decision[ Go to top ]

    Further suppose that the ASF paid for the J2EE TCK license (it's really support and brand management that's being charged for, but I digress..).
    Yes you will digress, away from the indirect financial gain
  48. it shouldn't affect your decision[ Go to top ]

    Peter Lin :
    But back on the topic of TCK, if swiftMQ doesn't like non-profit orgs getting a better deal, than they should lobby Sun to either reduce the cost of TCK or charge non-profits for it.Every product has strengths and weaknesses. what is important is measuring it based on reproducible tests and whether it meets the functional requirements.peter
    I'm not sure if that would satisfy Andreas. Suppose the ASF, ObjectWeb, and all the other non-profits, individuals and academics that are able to apply for the scholarship couldn't. Further suppose that the ASF paid for the J2EE TCK license (it's really support and brand management that's being charged for, but I digress..).What would change?We'd still provide bug reports and bug fixes to the projects we work with that implement JSRs. We'd still send bug reports and patches to ActiveMQ, Jetty, MX4J, JOTM, whatever. Nothing would change. Apache Geronimo is built using software from other projects, and we're happy to contribute back to those projects to make them better for all users.The value of a TCK isn't to show you were you screwed up, but rather to prove that the implementation is compatibile with the spec. This has value for users, whose code then isn't "surprised" by a misbehaving standard API. Spec compatbility isn't be a competitive differentiator, but the base requirement for a specific market. Compete on quality of implementation, or added features, or whatever, not that it manages to implement the spec that it claims to implement.geirp.s. Andreas : if you make SwiftMQ open-source under a license that we can use with Apache Geronimo, we'll send you bug reports and fixes too if someone decides to certify Geronimo w/ SwiftMQ. You could even volunteer to come over and do it. All volunteers welcome :)

    totally agree. My hope is swiftMQ will compete based on implementation and not on politics. I see no benefit to developers for Sun to deny non profit orgs. In the same way that non profits get special treatment from the government, I feel (totally bias) non profit orgs should get a reduced fee for TCK.

    on the other side of the coin, I can understand swiftMQ being concerned about another player in a crowded Messaging space. But regardless of ActiveMQ, that's a natural part of the maturation process. At some point, the best implementation will beat out the competition, so there is a lot at stake.

    as a developer, i just want something that works and helps me get my job done :) when vendors compete I benefit, so it's all good to me.

    peter
  49. it shouldn't affect your decision[ Go to top ]

    Hey Peter,

    I have no problem with competition. I have also no problems with non-profit organizations getting the TCK for less. But - as I said already - ActiveMQ is under control of James' company. He created it to make money. So that's not more non-profit. It's Jboss' model. Call it professional open source? Why should JBoss pay but he not? Could you tell me a reason?

    -- Andreas
  50. because i can fork ActiveMQ[ Go to top ]

    I look at it this way. It's using Apache license and I can fork ActiveMQ. Not that I would, since I have zero experience implementing a full blown JMS server. SpiritSoft, Tibo, Sun, JBoss or Swift can all fork ActiveMQ or do what ever they want with it as long as they include the license with the distribution.

    I agree 100% protique is for profit. If I compare activeMQ to say Orion JMS. I don't have access to Orion's source code and I do not have permission to fork the code. to do that, I would have to do what Oracle did. Pay a couple million dollars to buy an unrestricted source license. James leads development of ActiveMQ, but he has freely given control to the user. Therefore, protique does not have more control over the code than the user. though practically speaking, the learning curve for the average developer is rather high, so not everyone can take ActiveMQ and start a company.

    peter
  51. Hey Peter,I have no problem with competition. I have also no problems with non-profit organizations getting the TCK for less. But - as I said already - ActiveMQ is under control of James' company. He created it to make money. So that's not more non-profit. It's Jboss' model. Call it professional open source? Why should JBoss pay but he not? Could you tell me a reason? -- Andreas

    Protique isn't a J2EE TCK licensee Nor are they a JMS TCK licensee. JBoss paid because JBoss is a commercial organization and wanted to ship a J2EE 1.4 certified server. They did that. They get the benefit, and can use that license in any way they choose. Right now they are certifying the distribution at sourceforge, but they are free to do anything they want. They paid for that right, and they get the benefits.

    Protique can't ship a certified JMS broker. They can't even call it a JMS broker until they pass the TCK. When Geronimo certifies, they can't take the jars out of that and call it a JMS broker. They can't pull the jars out of Gluecode JOE and call that a JMS broker.

    If Protique wants to ship a certified JMS broker, they need to get a license for the TCK from sun, and run that TCK on the binary that they will distribute.

    geir
  52. it shouldn't affect your decision[ Go to top ]

    ok perhaps if we look at it in this way:

    1. Protique benefits from ActiveMQ
    2. ActiveMQ benefits from Geronimo
    3. Geronimo benefits from the free J2EE/TCK etc provided by Sun

    Points 1,2,3 are all interdependant, resulting in Protique benefiting from the free J2EE/TCK etc provided.

    I can't make this anymore clearer, but then as they say, you can lead a horse to water, but you can't make him drink it.
  53. it shouldn't affect your decision[ Go to top ]

    ok perhaps if we look at it in this way:1. Protique benefits from ActiveMQ2. ActiveMQ benefits from Geronimo3. Geronimo benefits from the free J2EE/TCK etc provided by SunPoints 1,2,3 are all interdependant, resulting in Protique benefiting from the free J2EE/TCK etc provided.I can't make this anymore clearer, but then as they say, you can lead a horse to water, but you can't make him drink it.

    It's true the Protique benefits from ActiveMQ, because Protique is a subset of the beneficiaries of this, namely everyone in the Java ecosystem. For example, JBoss could benefit from ActiveMQ by offering it as a broker for customers that ask for it, and can actually do one better than Protique by certifying that distribution. Protique can't do that.

    This is actually a cool example of the sybiosis in collaborating open-source communities.

    Slurp.

    - geir
  54. "The Dude" exposed.[ Go to top ]

    Strange, you did not speak fluent English before (ex1, ex2, ex3).

    Perhaps you didn't read your alias spreadsheet correctly.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  55. "The Dude" exposed.[ Go to top ]

    i is yawning now because you so very bery smart ..

    whoops you just exposed me, oh my deary deary .. i think i heard the toilet flush blah blah, whatever.

    i going now to watching the tv
  56. there you have it[ Go to top ]

    If I were in the position to need it, I'd be looking closely at ActiveMQ, since it has Andreas Mueller of SwiftMQ, a competitor, so obviously perturbed and afraid of the competition.
  57. On its own merits[ Go to top ]

    From the quick benchmarks I ran during the development of the JMS sampler for jmeter, I was quite impressed with the throughput ActiveMQ achieved. I keep planning on running benchmarks, but it's just hard to find the time. If anyone wants to run benchmarks comparing the JMS offering out there, I'll do what I can to help.

    peter
  58. Is that even a valid argument?[ Go to top ]

    I see no sense in that argument. When Glue Code gets certified by Sun and passes the TCK, it does not mean ActiveMQ is also certified. If I download Jonas or Jboss and start a fork of the code, any certification JBoss gets doesn't automatically apply to my fork. The same is true of commercial code. Perhaps you should read Sun's licenses more closely or ask a lawyer for an official interpretation. In either case, don't you think Sun would have already said, "stop immediately!" I understand your concerns, but Sun does not take TCK certification lightly. I don't work for glue code, nor am I a committer for ActiveMQ, but I am a committer on Jmeter. If you have real concerns, why not handle this through official channels? Debating licensing and legal issues on a forum usually degenerates to gibberish, since most of us are not lawyers.
  59. Is that even a valid argument?[ Go to top ]

    I see no sense in that argument. When Glue Code gets certified by Sun and passes the TCK, it does not mean ActiveMQ is also certified.

    My concern is not certification but the use of the TCK with several thousands of test cases without paying for it. ActiveMQ/Protique is not a non-profit organization like ASF; it's a business.

    -- Andreas
  60. Is that even a valid argument?[ Go to top ]

    ActiveMQ isn't an organization full stop - it is an open-source JMS product. The fact that Protique provides support for ActiveMQ doesn't make ActiveMQ a commercial product.

    By your logic, any open source project that has a company offering paid for support based on it is now a commercial product/organisation. You are confusing ActiveMQ the project with Protique the company. ActiveMQ is hosted by Codehaus and any developers are free to contribute code as they see fit, whether they work for Protique or not.

    I find it strange that you have chosen to single out James/Protique in this argument, given the large amount of other projects such as Jetty that are covered under the TCK and are also supported by commercial organisation.

    Rob
  61. Is that even a valid argument?[ Go to top ]

    ActiveMQ isn't an organization full stop - it is an open-source JMS product. The fact that Protique provides support for ActiveMQ doesn't make ActiveMQ a commercial product.

    Come on. We had this discussion with JBoss and they had to pay. They are hosted at SF and everybody can contribute ;-).

    Outside JMS is not my area.

    -- Andreas
  62. Is that even a valid argument?[ Go to top ]

    ActiveMQ isn't an organization full stop - it is an open-source JMS product. The fact that Protique provides support for ActiveMQ doesn't make ActiveMQ a commercial product.
    Come on. We had this discussion with JBoss and they had to pay. They are hosted at SF and everybody can contribute ;-).Outside JMS is not my area.-- Andreas

    Apache is a J2EE licencee and is certifiying Geronimo with a ton of other open source inside it, including ActiveMQ.

    GlueCode is a J2EE licencee and is certifiying JOE with a ton of other open source inside it, including ActiveMQ.

    ActiveMQ is a bunch of open source code that anyone can use - whether organisations offer commercial support or not. There's nothing to stop any other J2EE licensee from certifying their product with ActiveMQ integrated - such as the ObjectWeb guys with Jonas or the JBoss guys.

    Sure, Protique could one day be a J2EE licensee and certify just ActiveMQ by itself - which we'll probably do further down the line - but thats completely irrelevant to the discussion. Noone is violating any TCK licensing terms or NDAs - relax.

    James
    Protique
    Enteprise Open Source
  63. So life isn't fair[ Go to top ]

    I see no sense in that argument. When Glue Code gets certified by Sun and passes the TCK, it does not mean ActiveMQ is also certified.
    My concern is not certification but the use of the TCK with several thousands of test cases without paying for it. ActiveMQ/Protique is not a non-profit organization like ASF; it's a business.-- Andreas

    ActiveMQ is non-profit. Protique is for profit. I understand that it doesn't feel all that fair to businesses, but that has nothing to do with being legal. Any business can take advantage of that model. I would say it is savy to use that business model and allows the little guy to compete. Once a business is big enough to pay for it, they will, just like Jboss did. I'm totally bias for the small guys trying to compete.
  64. By the way, I'm curious to understand why you consider ActiveMQ a high-quality JMS implementation and WebLogic JMS a trivial technology.
    I don't understand it either. A mature JMS system needs *years* in the field in production, used by *many* customers. ActiveMQ is just an early 1.* release. It's certainly not a production ready system (I mean *real* production). I don't know if it's better than JBossMQ. I doubt that.And, btw, it's a commercial project. The business model behind is just like that of JBoss. It's only backed by another company, Protique. For this reason, I'm wondering why the could run the TCK against ActiveMQ? IMO this is not allowed, because it's not a Apache project. So actually they would have to pay for the TCK just like JBoss had to pay but they don't.Happy New Year.-- Andreas

    Currently Protique doesn't run the TCK against ActiveMQ (though this may change in the future) but Apache does as part of the Geronimo certification.

    Apache can integrate any BSD / ASF licenced code inside Geronimo, such as Jetty/Tomcat, mx4j, OpenEJB, ActiveMQ, Spring etc. The only real requirement is its open source & BSD / ASF licenced.

    James
    Protique
    Enteprise Open Source
  65. Arjuna+JBoss[ Go to top ]

    You might be interested in Arjuna+JBoss http://www.arjuna.com/products/jboss/index.html , which is a modified version of JBoss where the transaction manager and JMS implementation have been replaced with Arjuna products (Arjuna TS and Arjuna MS, respectively) that provide much better qualities of service.

    I have used Arjuna MS for the past 6 months and consider it a high quality, very affordable JMS implementation. Arjuna MS also contains an embedded version of the transaction manager and supports message-driven services with 2PC etc.

    Alain.
  66. But even then, the real problem is that JBoss bandits show no interest whatsoever to integrate their server seriously with high-quality JMS(e.g ActiveMQ).

    FWIW already ActiveMQ works pretty well with JBoss 4 thanks to JCA 1.5...

    http://activemq.codehaus.org/JBoss+Integration

    James
    Protique
    Enteprise Open Source
  67. JBoss Roadmap[ Go to top ]

    Bill's interview (nice job Bill!) is part of our ongoing efforts to have a very public roadmap, with a very open community. If you have specific questions such as JMS and transactioning, you can look at the Roadmap on our web site as well as the Wiki's for these areas. You can also listen to Bill's talk in these areas. We also encourage community participation and development. We've recently migrated over to Jira so that we have better facillities to enable the broader community - so join in and help drive where we are going!

    At a broader level, JBoss recently announced our overall vision of the JBoss Enterprise Middleware System (JEMS). This is our plan to build out an entire middleware stack over the next 1-2 years. This stack will have several attributes:
    - Complete Free Open Source
    - Loosley-Coupled Plug and Play.

    The loosely-coupled nature of JBoss and the Microkernel architecture are already apparent and will continue to be so in the future. For example, basically every JMS implementation available has an integration into JBoss - this include ActiveMQ, Arjuna JMS, Sonic, TIBCO, Webmethods, etc. This also extends to all of our projects working either with other app servers or stand alone. For example Hibernate, JBoss jBPM, JBoss Cache all can be used stand alone, with the JBoss App Server or with other App Servers like BEA or IBM.

    Our strategy mirrors the reality of the market. Many customers want a complete solution from JBoss - and we are well on our way to providing a complete Middleware infrastructure. Our goal is to make the entire stack work well together, as well as have each part of the stack a very competitive stand alone offering - for example we have many customers that are using JBossMQ today in production sites, or integrated with other messaging systems like IBM's MQ Series.

    On the other hand, many more customers want to plug and play their own mixture of technologies - and the JEMS architecture is being designed for that. We do not want to become a single huge distribution that can not be broen up into smaller, more digestable pieces - we want to allow our customers and users and community to use the things that they need. This also allows for a very healthy and vibrant ecosystem of partners and plug-ins - hence the rich assortment of JMS providers for example...

    Bob Bickel
    JBoss
  68. Aspects for Dependency Injection[ Go to top ]

    Some of the other things we are doing, we are investigating how to use dependency injection inversion of control via aspects.

    I'm very interested in this... who is in charge? There are cases where I would be very willing to use container-specific annotations to circumvent some of the headaches associated with current DI frameworks.
  69. 9 months old[ Go to top ]

    FYI, this interview is over 9 months old. I did at at the last TSS Symposium in May 2004.

    Some things off the top of my head that have happened since then:

    * JBoss 4.0 became J2EE Certified
    * JBoss 4.0.0 and 4.0.1 were released
    * We released our EJB 3.0 Previews
    * jBPM joined the jboss umbrella
    * New production versions of JBoss AOP, JBoss IDE, Javassist, JBoss Portal, and JBoss Cache
    * We became #1 in market share according to BZ Research
    * We got on J2EE 1.5, EJB 3.0, Web Services, JBI committees
    * We were voted to the J2EE/J2SE Executive Committee
    * We became a member of the Eclipse organization
    * We made our documentation free

    Bill
  70. 9 months old[ Go to top ]

    I actually had a suspicion that this interview was months behind… But it is a bit ridiculous that it takes TSS 9 months to post an interview that supposed to be an updated on a product development?!?

    On a subject of full TM implementation (and similar issues) I have long thought that JBoss strategy is to push it to the partners (and Arjuna is a good one). For simple cases (1 XAR), JBoss works, for anything else – talk to our partners.

    I, however, would point that we should be very clear on separating 2PC protocol with one transaction coordinator and situation when there is more than one transaction coordinator. Later case requires transaction context propagation and this is exactly what usually is referred as unacceptably slow.

    Here I would agree with Bill that having 2 or more TMs coordinating with each other must be a rare exception rather than a rule. Having normal (not-coordinated) 2PC transactions however is absolutely normal and performs rather well considering what it does.

    Regards,
    Nikita.
  71. I never understood this whole fud. What is the use of it? I know in some webservices scenario we use it (one way method calls in .NET world); but if you think carefully you are introducing more coupling here. I mean you are writing a component and forcing your client to use it asynchronously. It is so ironic that AOP invented to decouple things but people can use and abuse it to the extent where we got back to sqaure one. What a fuzzy world my friends; hope experts of AOP sitting in JBoss will think about it again:-)
  72. I never understood this whole fud. What is the use of it? I know in some webservices scenario we use it (one way method calls in .NET world); but if you think carefully you are introducing more coupling here. I mean you are writing a component and forcing your client to use it asynchronously. It is so ironic that AOP invented to decouple things but people can use and abuse it to the extent where we got back to sqaure one. What a fuzzy world my friends; hope experts of AOP sitting in JBoss will think about it again:-)
    I don’t think AOP has added anything of clear significance for solving decoupling problem. It’s been drummed about for the last 12-18 months and it’s still there where it began, in my opinion. Frankly, JBoss seems to be the only one who is still pushing all-out AOP development approach.

    AOP has certain niche but it should rather be considered as a very obscure programming technique for implementing very specific portion of low-level infrastructure code.

    Annotations have much more relevance to decoupling. Look at .NET 2.0 usage of them, for example, that’s where Java will be, so to speak, in the nearest future.

    Best,
    Nikita.
  73. I don’t think AOP has added anything of clear significance for solving decoupling problem. It’s been drummed about for the last 12-18 months and it’s still there where it began, in my opinion. Frankly, JBoss seems to be the only one who is still pushing all-out AOP development approach. AOP has certain niche but it should rather be considered as a very obscure programming technique for implementing very specific portion of low-level infrastructure code. Annotations have much more relevance to decoupling. Look at .NET 2.0 usage of them, for example, that’s where Java will be, so to speak, in the nearest future. Best,Nikita.

    Ok Nikita wihtout getting into the argument about AOP or what it is intended for I think it is fair to say that Jboss version of AOP, Java (annotations), .NET(attributes) can all be classified as attribute based programming. And I am ok with that as far as you can tag your obejcts with some meaning that you can use later to achieve some specfic task (injecting context, transaction etc, etc). But tagging methods with synch asynch attributes and making clients commit to that is nothing but insanity in my humble opinion. Again without getting into any argument of programming paradigms it is the client's decession how to call you, it is 101.

    BTW if JBoss is pushing AOP for good I am with them too. But just to catch the buzz and doing some thing silly doesn't impress me much...
  74. Hi Rashid,
    But tagging methods with synch asynch attributes and making clients commit to that is nothing but insanity in my humble opinion. Again without getting into any argument of programming paradigms it is the client's decession how to call you, it is 101.
    I'm with you and me here :-)
    I was making broader statement about AOP as to whether or not it is mitigating decoupling. As far as asynchronous calls I agree. I would not call it insanity but it surely looks like a solution in search of a problem.

    Regards,
    Nikita.
  75. AOP has certain niche but it should rather be considered as a very obscure programming technique for implementing very specific portion of low-level infrastructure code. Annotations have much more relevance to decoupling. Look at .NET 2.0 usage of them, for example, that’s where Java will be, so to speak, in the nearest future. Best,Nikita.

    IMO, AOP + Annotations is one of the better ways of applying providing functionality for the logic that needs to be applied for an annotation. It is a much better encapsulation annotation behavior.


    http://docs.jboss.org/aop/aspect-framework/userguide/en/html/annotations.html

    If you go to the main contents of this manual, you'll see a lot of other examples where AOP is pertinant. I'm not saying use AOP for everything, but it can help out in a lot situations. Remember, AOP is a compliment to OOP, not a replacement.

    I also encourage you to go to the AspectJ site and view some of their tutorials. Things like declare error/declare warning (which we're adding to JBoss AOP) allow you to enforce programming contracts in your code.

    Bill
  76. IMO, AOP + Annotations is one of the better ways of applying providing functionality for the logic that needs to be applied for an annotation. It is a much better encapsulation annotation behavior. http://docs.jboss.org/aop/aspect-framework/userguide/en/html/annotations.htmlIf you go to the main contents of this manual, you'll see a lot of other examples where AOP is pertinant. I'm not saying use AOP for everything, but it can help out in a lot situations. Remember, AOP is a compliment to OOP, not a replacement.I also encourage you to go to the AspectJ site and view some of their tutorials. Things like declare error/declare warning (which we're adding to JBoss AOP) allow you to enforce programming contracts in your code.Bill
    Been there, done that, tried this (AspectJ), dropped it. Bill, most of us who were really interested in AOP are past examples/tutorial phase and already spent significant amount of time and have more or less clear and full understanding of it.

    Examples seem to be the worst technique in AOP discussion b/c I can counteract practically any example with counter-example where AOP simply doesn’t work or make things worse. So, it’s no use.

    Some of the things in AOP, like that semantic enforcement from AspectJ you are referring to, are neat and may be useful in certain situations. But that was exactly my point – niche and specialized programming technique. To iterate, I believe that annotations are much more fundamental and broad feature than AOP.

    Best,
    Nikita.