Discussions

News: J1 Day 2 : Rave, Java.Net, JBossTwo, EJB 3.0, J2SE 1.5 Security

  1. JBossTwo featured 'The Marc Fleury Show' and a fascinating AOP Panel. The morning keynote at JavaOne looked at the new Java.net portal and gave a demo of Project Rave. Throughout the day and into the evening there were several key talks and discussions on EJB 3.0. Other sessions included 'Agile Methods vs. MDA', 'Design Patterns for Heavy Load Websites', and New Security Features in J2SE 1.5.

    Read TheServerSide's Day 2 JavaOne 2003 Coverage

    What did people think of the second day of Technical Sessions and BoF's? What were your thoughts on JBossTwo?

    Threaded Messages (62)

  2. Applying AOP[ Go to top ]

    Will [field interception] mean the end of set*() get*() methods?

    NO NO NO NO NO. The point of AOP is not to undo all of the good design principles, like encapsulation, that we learned with OOP. This is exactly the sort of thing that is going to give AOP a bad name before best practices set in.

    Use field interception to COMPLEMENT your getters and setters. For example:

    public void setState( int newState )
    {
      _state = newState;
      if ( newState == CLOSED )
      {
        _available = false;
      }
    }

    Now, field interception is handy. Start transaction. Call object.setState( COMPLETE ). And... transaction rollback. Both _state and _available are restored to their original settings.

    _available might even be a persistent field that is not publically accessible. That's something you can't do with Entity Beans right now.
  3. Applying AOP[ Go to top ]

    Now, field interception is handy. Start transaction. Call object.setState( COMPLETE ). And... transaction rollback. Both _state and _available are restored to their original settings.

    >
    > _available might even be a persistent field that is not publically accessible. That's something you can't do with Entity Beans right now.

    How does JBoss' field interception work? Currently, this is a unique feature of JDO, achieved via bytecode modification to be able to intercept field access. I don't see any other mechanism for this, so does JBoss use bytecode modification too?

    And what does AOP have to do with this? AFAIK, AOP is mainly there to wrap existing objects, exposing the same interface but intercepting method calls. So is field interception really the right way? I feel that it does indeed break encapsulation, and if it really requires bytecode modification too... Then this isn't about clean OOP-complementing aspects anymore, IMHO.

    Juergen
  4. Applying AOP[ Go to top ]

    Now, field interception is handy. Start transaction. Call object.setState( COMPLETE ). And... transaction rollback. Both _state and _available are restored to their original settings.

    > >
    > > _available might even be a persistent field that is not publically accessible. That's something you can't do with Entity Beans right now.
    >
    > How does JBoss' field interception work? Currently, this is a unique feature of JDO, achieved via bytecode modification to be able to intercept field access. I don't see any other mechanism for this, so does JBoss use bytecode modification too?

    yes jboss uses bytecode modification
    >
    > And what does AOP have to do with this? AFAIK, AOP is mainly there to wrap existing objects, exposing the same interface but intercepting method calls. So is field interception really the right way? I feel that it does indeed break encapsulation, and if it really requires bytecode modification too... Then this isn't about clean OOP-complementing aspects anymore, IMHO.
    >
    you have a great view of jdo but i think your view of AOP is a little naive

    public class Pojo
    {
      private Pojo pojo
      public Pojo getPojo()
      {
        return pojo;
      }
      public Pojo setPojo(Pojo pojo)
      {
        this.pojo = pojo;
      }
      public void someOtherBadMethodThatDoesntUseTheGetterAndSetterForYourCase()
      {
        pojo.setSomething(something);
        pojo = new Pojo();
      }
    }

    now without field interception where does the distributed cache find out that the pojo has changed once the following is executed:
    pojo.someOtherBadMethodThatDoesntUseTheGetterAndSetterForYourCase();

    probably a bad example but anyway

    tx

    Matt
  5. Applying AOP[ Go to top ]

    yes jboss uses bytecode modification


    OK then, I assumed that anyway. But is it different to JDO's mechanism? And is the modification a compile-time or a run-time step?

    > you have a great view of jdo but i think your view of AOP is a little naive
    > (...)
    > now without field interception where does the distributed cache find out that the pojo has changed once the following is executed:
    > pojo.someOtherBadMethodThatDoesntUseTheGetterAndSetterForYourCase();

    That has something do with transactional behavior of the object (as supported by JDO's transactional-but-not-persistent objects), but I don't see an immediate connection to AOP. In my view, an AOP interceptor is chained into the method invocation of the target object, to be able to intercept before and after the call on the target itself.

    I guess we have a different concept of "aspects" in our heads, as I imagine non-intrusive ones that work on completely unmodified objects, using a proxy for the target object's interfaces underneath. An obvious example is starting a transaction before a call on the target, and committing or rolling it back afterwards. As long as the resources that the target accesses are all transactional, this should work nicely - on the transactional resources, not on the target's fields. As I'm mainly thinking about Stateless-Session-style service instances, there won't be any transactional state in them anyway.

    On the other hand, you seem to think about an Entity-style case where the target object holds transactional state itself, triggering a cache after changes. Obviously, you'll need to intercept field accesses here, to be able to detect changes. I don't consider solutions for this problem "aspects" though, but rather solutions for transactional behavior of (persistent) objects. This is what JDO is about, or Hibernate with its shared cache support. So why call this AOP when it isn't about a non-intrusive aspect (JDO doesn't call it aspect either)? And after all, why not use JDO in the first place?

    Juergen
  6. Applying AOP[ Go to top ]

    But is it different to JDO's mechanism? And is the (JBoss) modification a compile-time or a run-time step?


    It uses Javassist (now part of JBoss), to generate bytecode at runtime. The downside of this is that it requires complete control of the class loader. So although there's a standalone release of JBoss AOP, it's hard to see how this can work safely in other app servers.

    Personally I share Juergen's skepticism about field-level interception. While there are a few cases where it might be attractive, it violates encapsulation. I'm not convinced by Matt's example, as you could intercept someOtherBadMethodThatDoesntUseTheGetterAndSetterForYourCase()--a method--to invalidate your cache.

    I want my AOP to complement OO, not break it. Maybe we'll get to building whole systems on aspects in the future, but I think we have a lot to learn before we do.

    I see multiple levels of AOP:
    - method interception against interfaces, probably intercepted by dynamic proxies (Spring, Nanning). Note that this can be done without messing with the class loader or bytecodes.
    - method interception against any class, which you can do easily enough with CGLIB
    - method and field interception against any class (JBoss, AspectWerkz?)
    - anything you can possibly think of (AspectJ). This might be true AOP, but it can be dangerous. If you want this sort of power, there's no alternative to language extensions to implement it. And AspectJ has already made a good job of it.

    As I want only to AOP-enable business objects, and I believe it's good practice to put business objects behind interfaces, the first of these approaches delivers the functionality I want (declarative transactions for POJOs etc) without any threat to object encapsulation. Sure it's a subset of what a full AOP solution will give you, but it also raises far fewer maintenance unknowns.

    Btw, I enjoyed Bill Burke's OnJava article. His answers on the thread linked to the article are also excellent, and well worth reading.

    Regards,
    Rod
  7. Applying AOP[ Go to top ]

    I want my AOP to complement OO, not break it. Maybe we'll

    > get to building whole systems on aspects in the future, but
    > I think we have a lot to learn before we do.

    Those statements should be written in boldface; the AOP zealots
    need to understand those reservations and provide appropriate
    design patterns.


    > As I want only to AOP-enable business objects, and I
    > believe it's good practice to put business objects
    > behind interfaces, the first of these approaches
    > delivers the functionality I want (declarative
    > transactions for POJOs etc) without any threat to
    > object encapsulation. Sure it's a subset of what a
    > full AOP solution will give you, but it also raises
    > far fewer maintenance unknowns.

    I, too, believe that to be a sound starting point. You
    might also like to mention testing as well as maintenance.

    But then far too few people consider testability (and its
    cousins, fault detection reporting and containment) nowadays.
  8. JBoss is NOT ready for prime time[ Go to top ]

    Ryan Broadband: Where do I go for 24/7 support if I use JBoss? Oh wait, which JBoss are we talking about? The one group that has 8 developers or the breakaway group that has even fewer?

    Stop drinking the kool-aid and smell the roses. ie: get back to reality!
  9. Spend the time to look at the source[ Go to top ]

    Just my 2c. If something doesn't work, and it's really *not* your fault, then what will you do? With a commercial vendor, do you search the news groups, call level 1 support, put in a support ticket? And how long does that take compared to digging into the source of the product? I guess it depends, but I have on more than one occasion had to decompile a commercial product just to figure out what the hell was going on, and let me tell you, sometimes its not pretty.
  10. Spend the time to look at the source[ Go to top ]

    \Chun\
    Just my 2c. If something doesn't work, and it's really *not* your fault, then what will you do? With a commercial vendor, do you search the news groups, call level 1 support, put in a support ticket? And how long does that take compared to digging into the source of the product? I guess it depends, but I have on more than one occasion had to decompile a commercial product just to figure out what the hell was going on, and let me tell you, sometimes its not pretty.
    \Chun\

    I'm generally a fan of open source, and I've delved pretty deeply into some source bases. But I shudder at the idea of trying to debug JBoss, and even more at the idea of changing the source to fix a problem (which I believe is what you were getting at). Now imagine trying to debug & change aspect-based JBoss on your own....

         -Mike
  11. JBoss supports their software through commercial support contracts. Here the information incase you need it.

    From JBoss (amounts blacked out):

    a. $####### for 20 hours of support, 24 hour response, 6 month contract, billed in 15 minute increments.

    b. $####### for 50 hours of support, 24 hour response, 12 month contract, billed in 15 minute increments

    c. $####### Production Site for 24/7 production support, 6 hour response time, unlimited calls.

    d. $####### Production Site for 24/7 Production support, 2 hours response time, unlimited calls.

    Chill out, whippersnapper.
  12. Nick Whippersnapper:

    Thanks for proving my point. Case closed.
  13. If you had a point, we might be able to prove it.
    If you ever had a case, it's clearly closed.
  14. 24/7[ Go to top ]

    Ryan Broadband: Where do I go for 24/7 support if I use JBoss? Oh wait, which JBoss are we talking about? The one group that has 8 developers or the breakaway group that has even fewer?

    >
    > Stop drinking the kool-aid and smell the roses. ie: get back to reality!


    JBossGroup has a lot more than 8 consultants in it's close knit network. We have a lot of independents that don't want to be direct employees of JBossGroup , for tax purposes and other reasons.

    Bill
  15. 24/7[ Go to top ]

    Ryan Broadband: Where do I go for 24/7 support if I use JBoss? Oh wait, which JBoss are we talking about? The one group that has 8 developers or the breakaway group that has even fewer?

    > >
    > > Stop drinking the kool-aid and smell the roses. ie: get back to reality!
    >
    >
    > JBossGroup has a lot more than 8 consultants in it's close knit network. We have a lot of independents that don't want to be direct employees of JBossGroup , for tax purposes and other reasons.
    >
    > Bill

    And we do offer 24/7 support, except unlike our competitors, you'll get somebody that can actually help out with your problem.

    Bill
  16. 24/7[ Go to top ]

    JBossGroup has a lot more than 8 consultants in it's close knit network.


    I'm curious: exactly how many do you have in your close knit network?

    /Rickard
  17. 24/7 ...NOT![ Go to top ]

    Bill Burkee: For starters, you folks can't even fix your own website. And you are talking about offering 24/7 support for enterprises! ROFLMAO!

    Secondly, what is that I hear that you have more than 8 people in your close knit network. How many "more" is this? And what is that all that stuff about "tax purposes"? Are these additional folks who you claim aren't on your payroll doing this so that they can under-report their income to the IRS? Sounds very shady to me and definitely not a company that I would like to do business with.
  18. Applying AOP[ Go to top ]

    told you it was a bad example

    should read

    public class Pojo
    {
      private Pojo pojo
      private Pojo someField;

      public Pojo getPojo()
      {
        return pojo;
      }
      public Pojo setPojo(Pojo pojo)
      {
        this.pojo = pojo;
      }
      public void someOtherBadMethodThatDoesntUseTheGetterAndSetterForYourCase()
      {
        pojo.someField = new Pojo();
        pojo = new Pojo();
      }
    }
  19. The real action was at JBossTwo[ Go to top ]

    What were your thoughts on JBossTwo?


    The JBoss Group presented the addition of AOP, a compelling feature, to their application server.

    With AOP, JBoss brought application server power to an order of magnitude higher than the competition. The technology simplifies enterprise development and reduces the cost of such endeavors. The technology is revolutionary for enterprise development.

    Also the panel of users demonstrated that JBoss is currently being used for 24/7 mission critical applications. It is compelling to listen to the panel explain how the competition did not work for them and how JBoss enabled them to build their solutions.

    JBoss is the killer enterprise application server.
  20. The real action was at JBossTwo[ Go to top ]

    \English\
    With AOP, JBoss brought application server power to an order of magnitude higher than the competition. The technology simplifies enterprise development and reduces the cost of such endeavors. The technology is revolutionary for enterprise development.
    \English\

    I haven't attended the sessions, but have perused various pieces of coverage. From what I've seen, while yourself (and others :-) are talking about power and simplicity, the fundamental questions aren't being answered.

    For example:

    Q. "Isn't it hard to debug Aspects?"
    Marc: "You don't have to. JBoss has already debugged the aspects for you. They are solid" [can you ever just trust services like these?]

    That's an evasive answer that doesn't address the question - a very valid question.

    Q. "If we jump into the new JBoss was of doing things with POJO's and Aspects, haven't we lost interopobility?"
    Marc: "Do you mind being stuck in a free world?"

    Another non-answer. While there may be something to JBoss' aggressive use of AOP, right now if you use it you _are_ locking yourself into JBoss. Full stop. Period. Not everyone needs to be "standard", and there are always advantages to people pushing the envelop. But at the same time, you can't just ignore interoperability and portability - and denigrating it with a flippant comment is
    just going to alienate the more mature customers out there.

    [On Burke: He answered the "is debugging aspects hard?" question by saying that tools need to help out, and reminding everyone that people used to say that polymorphism is bad, as it makes debugging hard]

    I wish AOP advocates would be honest here and simply answer "yes".

    [When an example was shown, that had a Tracer, Marc groaned "NOT A LOGGING EXAMPLE AGAIN". When you see anything to do with AOP, logging is always the example.... so one can feel Marc's pain with that one]

    While there's some truth that examples are just examples, and new technologies often have terrible ones (how about the animal inheritance tree for OOP?), it's disappointing that logging/tracing is the quintessesntial AOP example. And the reason why is obvious - more real life examples expose the fragility of AOP systems, and how hard it is to understand what the heck's going on.


    \English\
    Also the panel of users demonstrated that JBoss is currently being used for 24/7 mission critical applications. It is compelling to listen to the panel explain how the competition did not work for them and how JBoss enabled them to build their solutions.
    \English\

    I understand their need to demonstrate this, but personally I don't think it means very much. It's a comfort factor for PHBs, but for technologists it doesn't help much, and it's still difficult for a technologist to get any feel whatsoever for real JBoss usage. Put another way, it's not interesting that it's used in "24/7 mission critical applications", because _every_ technology I can think of is used somewhere in a 24/7 mission critical app (yes, every one). The real question is how it stacks up to the competition and the unique benefits (and drawbacks), and frankly JBoss' dearth of documentation alone is actually making it difficult for many people to even properly evaluate it in a reasonable time frame.

    Shifting gears - overall coverage here of the show has been great. I echo others in saying TSS has done a great job.

        -Mike
  21. The real action was at JBossTwo[ Go to top ]

    I also attended the JBoss session and found it well worth the time.

    I thought that point on difficulty of debugging an AOP was made clear and tools would need to step up and support it was well stressed.

    Most of the AOP concept has been thought out well in terms of system aspects such as persistance, security etc. However I was amused to see that even the folks in the AOP trenches are scratching their head in terms of User Aspects. What would be a real world example of an application level aspects?

    I found Marc to be quite eloquent in getting a point across. Good job guys.
  22. The real action was at JBossTwo[ Go to top ]

    Also the panel of users demonstrated that JBoss is currently being used for

    >24/7 mission critical applications.

    >>I understand their need to demonstrate this, but personally I don't think it
    >>means very much. It's a comfort factor for PHBs, but for technologists it
    >>doesn't help much, and it's still difficult for a technologist to get any
    >>feel whatsoever for real JBoss usage.

    One person on the panel was from a financial company with an energy trading application implemented on JBOSS. Another was from a billion dollar business supply company that implemented their e-commerce application on JBOSS. Another person was from a major company that perform airline travel reservations. Their enthusiasm and justification for using for JBOSS was very persuasive.

    >>Put another way, it's not interesting that it's used in "24/7 mission
    >>critical applications", because _every_ technology I can think of is used
    >>somewhere in a 24/7 mission critical app (yes, every one). The real question
    >>is how it stacks up to the competition and the unique benefits (and
    >>drawbacks),

    They all looked at the competition and some even implemented on the competition, but when it came to working in the real world, they switch to JBOSS because JBoss worked when the competition didn't. In other cases, the competition was so expensive that they could not justify it at any pricing sheme or discount that the competition gave them.

    >>and frankly JBoss' dearth of documentation alone is actually making it
    >>difficult for many people to even properly evaluate it in a reasonable time
    >>frame.

    I bought the plain vanila documentation and was able to deploy an application that was certified for WebLogic on JBOSS to evaluate JBOSS.

    In terms of the cost, you could probably get Marc Fleury himself to come for a training day at you company and still walk away spending less than the competition.
  23. because JBoss worked when the competition didn't.

    Who was the competition, then? Maybe they did beat an old iPlanet version :-), but I don't believe (yet) that there is a case where JBoss 3 really beats WebLogic when it comes to 7/24 operations, except on license price, of course.

    Cheers,
        Henrik
  24. because JBoss worked when the competition didn't.

    >Who was the competition, then? Maybe they did beat an old iPlanet version :-
    >), but I don't believe (yet) that there is a case where JBoss 3 really beats
    >WebLogic when it comes to 7/24 operations, except on license price, of
    >course.

    You might be very surprised.
  25. because JBoss worked when the competition didn't.

    >Who was the competition, then? Maybe they did beat an old iPlanet version :-
    >), but I don't believe (yet) that there is a case where JBoss 3 really beats
    >WebLogic when it comes to 7/24 operations, except on license price, of
    >course.

    I will let the customer's testimony of their experience and reason why they switched to JBOSS speak for itself.

    The justification for using JBOSS that I heard from the panel was compelling and overwhelming.

    After listening to them, I would say, "I see no reason why I shouldn't drink JBoss's Kool-Aid."
  26. JBOSS not enterprise ready[ Go to top ]

    I will let the customer's testimony of their experience and reason why they >switched to JBOSS speak for itself.

    >
    >The justification for using JBOSS that I heard from the panel was compelling >and overwhelming.
    >
    >After listening to them, I would say, "I see no reason why I shouldn't drink >JBoss's Kool-Aid."

    I have heard it many times in the forums here, that JBOSS should be a good, cheap alternative to the major players in the Appserver market.
    Having worked with Websphere, Weblogic and JBOSS, i must admit that for development JBOSS is really nice. I like the JBOSS way of making deployment fast and easy.

    On the other hand, i doubt, that the JBOSS EJB Container is really apted for all kinds of large enterprise applications like Weblogic or Websphere are.
    From my understanding (please correct me, if i should be wrong) the JBOSS EJB implementation has some limitations:

    1. EJB Locking Strategy for entity beans

    The EJB specification mentions two approaches how to deal with concurrent access on entity beans from multiple transactions (10.5.10 Concurrent access from multiple transactions). From my understanding of how JBOSS works internally, they have choosen the option, which is easier to implement:
    Only one transaction at a time gets access on an entity bean. This introduces a bottleneck (scalability gets limited) and furthermore makes development more complicated, because it introduces the possibility of deadlocks.

    2. Heavy usage of reflection based interceptors

    The advantage of easy and fast deployment due to the heavy usage of Java Reflection has also a severe disadvantage.
    Compared with plain old java objects, the whole reflection based interceptor chain which will be processed each time you access a method, slows down fine grained methods heavily. Its not the same magnitude like between remote and local calls, but i think it could have a severe impact on performance.
    I assume this will even get worse with all the AOP stuff they introduce for JBOSS 4.0.
    I think they could optimize some of the interceptor stuff, if they would use more bytecode-manipulation instead of the generic invoke( Invocation mi) code. Its a classical trade-off between flexibility and performance.

    Additionally i have never seen some numbers on performance and scalability of:
    - JBOSS clustering
    - the JBOSS JMS implementation (although some small tests indicate, that this really is not enterprise level)


    So i would claim:
    1. JBOSS is ok for development
    2. JBOSS might be ok for enterprise applications not using the EJB Container or only using stateless session beans (but then, whats the added value opposed to stand-alone tomcat or jetty???)
    3. JBOSS is not apted for enterprise applications which heavily use entity beans (although this might not be a good idea at all :-)


    I certainly know, that each application is different. Therefore the limitations i have mentioned may be important or not.
    But what i really do not like, are all those unproven claims of
    "JBOSS can do everything. Its faster and better than all the other application servers".

    So prove me, that i'm wrong with my statements and show me some great clustered enterprise applications with heavy usage of entity beans or messaging.

    Thomas
  27. Just to toss a comment into the mix, I think one point is missing.

    WebLogic.. WebSphere.. Oracle.. etc.. aren't just selling application servers. They are selling integration tools.. portal software.. single sign-on solution.. data mapping solutions.. and probably just as importantly (to them) professional services. Add to that developemnt tools and software, expansive documentation, and lots of tutorials. In other words, sure they have a J2EE container in there somewhere, but they have an awful lot wrapped around it to help in the development process, the integration process, and the deployment process.

    You can do many of these same features with current tools. Use OpenAdaptor for EAI sorts of features, JBoss for your container, Eclipse/IDEA/Netbeans for your Dev tools, Jakarta projects for other components and you can build a *reasonably similar* product offering. What you loose is the tightly coupled environment that one of the commercial vendors brings. You loose the unified and complete documentation and support. You loose a tight (or possibly any) integration into standard enterprise application management tools. (OpenView, Tivoli, etc.)

    So, the real question is, what do you need to accomplish your task? If you want a J2EE container I think JBoss serves that need quite well. For many, many tasks, thats all you need. (Heck, in another window here, I'm bringing up a new site on JBoss.. deploying the EAR right now.) But when you talk *ENTERPRISE*, many of the other features I've mentioned become much, much more important. They may not be critical to a particular project you are working on, in which case great! But if they are, there is a reason the other commercial vendors moved well beyong just offering a base application server as their central products.
  28. WebLogic.. WebSphere.. Oracle.. etc.. aren't just selling application servers. They are selling integration tools.. portal software.. single sign-on solution.. data mapping solutions.. and probably just as importantly (to them) professional services. Add to that developemnt tools and software, expansive documentation, and lots of tutorials. In other words, sure they have a J2EE container in there somewhere, but they have an awful lot wrapped around it to help in the development process, the integration process, and the deployment process.


    Do you really want to get everything from one vendor? This is not always a good thing. I think this approach can sometimes be short-sighted for several reasons. First, one vendor is *never* going to give you the best product in every category. Second, products from the same vendor never fit seemlessly together, no matter how slick to sales person's PowerPoint presentation is. Third, I have found this forces major upgrade churning in some case - if you upgrade to 4.0 of our app server, you need to upgrade to 3.5 of our portal server and 5.1 of our commerce suite and 6.2 of our messaging software...or you will be out of support. Gee, thanks!

    I think there is something to be said with a best-of-breed approach. As long as your applications expose some API that allow them to integrate with others in some way this can be done without a massive amount of effort. XML has helped integration come a long way. Plus, you get to choose you apps, not have then dictated to you.

    Either way is a reasonable solution. I just have been burned by the "one vendor" concept in the past.

    Ryan
  29. I think there is something to be said with a best-of-breed approach.

    Hear, hear. If we really want everything from one vendor, why not Microsoft? Part of the beauty of J2EE is that it means that we're not locked in. Also, it's much easier for smaller vendors to compete in a specialized market that they may understand better than the app server vendors than in building an overarching solution. So picking and choosing gives more choice and promotes innovation.

    In some cases vendors' integrated stacks result from acquisitions are held together with sticky tape, and the integration is mainly in marketing anyway.
  30. I definately agree.. it just depends on what you need. My base point is that when we talk about WebLogic for example, the container is a segment of that. You may or may not want to use their other products.. perhaps the portal server fits your needs, but you want WebMethods for EAI functions. Thats fine, but BEA has spent some time building some tools and solutions that are integrated. (I'm just using them as an example here.. obviously many "integrated" solutions are anything but..)

    I too am typically wary of a single vendor solution.. unless there is a real reason to go that way. Perhaps it *does* integrate well.. and perhaps it will better support the enterprise monitoring/management functions in place.. or whatever the capability is.

    Essentially, JBoss is a good J2EE container, but many people like to say "you never ever need these other "containers", when in fact, you would probably buy the other products in order to get a wider range of products to use. (Of course, I do know people who have purchased WebLogic to use as a servlet engine.. ouch!)
  31. JBOSS not enterprise ready[ Go to top ]

    2. JBOSS might be ok for enterprise applications not using the EJB Container or only using stateless session beans (but then, whats the added value opposed to stand-alone tomcat or jetty???)


    Well, there's more added value than just the EJB Container: e.g. JTA and JCA support. Jetty doesn't even have out-of-the-box JNDI DataSource support, they suggest to use JBoss for it... It's worth mentioning that you can add Tyrex to Tomcat 4.1 for JTA and JCA. But Tyrex seems somewhat unsupported, not being actively developed anymore. So for JTA and JCA, JBoss is a viable option, or one of the commercial app servers. Note that WebLogic Express does feature JTA - no JCA though.

    Of course, if you don't need distributed transactions with failover support because you are just accessing a single database anyway, then you don't need JTA. So Tomcat 4.1 or Resin would be fine choices, as the non-transactional DataSources offered by them are sufficient.

    A different issue is if you'd mainly like to leverage high-level transaction demarcation, be it programmatically or declaratively. The typical choice for this are Local Stateless Session Beans, requiring a full J2EE server with JTA and EJB - even for a single database. The Spring Framework offers a solution for this dilemma: Abstract high-level transaction management with multiple SPI options, ranging from JTA to implementations for Hibernate, JDO, or single JDBC DataSources. This enables convenient transaction demarcation without JTA, e.g. on Tomcat 4.1 with a single database. Or with JTA on multiple databases but without EJB, to avoid the expenses of Stateless Session Beans just to be able to leverage container-managed transactions for local service objects!

    The goal of Spring's transaction support with pluggable SPI implementation is simple: allowing for appropriate solutions without sacrificing application architecture or convenience. One-database web apps can use high-level transaction demarcation without unnecessarily requiring JTA or EJB, while multiple-database enterprise apps can use exactly the same mechanism for JTA transactions - just configured to a different SPI implementation.

    > 3. JBOSS is not apted for enterprise applications which heavily use entity beans (although this might not be a good idea at all :-)

    I agree, definitely not a good idea at all :-)

    Juergen
  32. JBOSS not enterprise ready[ Go to top ]

    Well, there's more added value than just the EJB Container: e.g. JTA and JCA

    > support. Jetty doesn't even have out-of-the-box JNDI DataSource support

    They do now since version 4.2.10. JettyPlus adds JTA, JNDI and DataSource support to Jetty.

    > It's worth mentioning that you can add Tyrex to Tomcat 4.1 for JTA and JCA.
    > But Tyrex seems somewhat unsupported, not being actively developed anymore.

    But you can use JOTM instead. JOTM is already integrated in Jetty to provide JTA support and can be integrated to Tomcat 4.1 as well.
    (However, there's yet no support for J2EE Connectors...)
  33. Performance and reflection[ Go to top ]

    <thomas>
    Compared with plain old java objects, the whole reflection based interceptor chain which will be processed each time you access a method, slows down fine grained methods heavily. Its not the same magnitude like between remote and local calls, but i think it could have a severe impact on performance.
    </thomas>
    Sure there will be an overhead compared to POJOs, but it will probably be comparable to (local) EJB invocation. Use AOP as an alternative to EJB and it's likely to perform, better, not worse. AOP-enable every POJO and you may have a problem.

    In my experience with AOP frameworks the overhead of intercepted invocation of a business facade (1 or 2 per web request, for example) is insignificant.

    I would not choose to advise (AOP-enable) every POJO in an application, or even a large proportion of them, for performance and other reasons.

    Rod
  34. JBOSS not enterprise ready[ Go to top ]

    From my understanding (please correct me, if i should be wrong)...

    1. EJB Locking Strategy for entity beans
     
    From my understanding of how JBOSS works internally, they have
    choosen the option, which is easier to implement:
    Only one transaction at a time gets access on an entity bean.


    No. The locking strategy is completely configurable on a per-entity bean basis. The base server ships with at least three strategies to choose from (no knowledge of internals needed): pessimistic locking (which you described), optimistic locking, and no lock. JBoss also provides a clearly defined interface by which you can plug in your own locking policies.

    2. Heavy usage of reflection based interceptors

    Compared with plain old java objects, the whole reflection based interceptor chain which will be processed each time you access a method, slows down fine grained methods heavily. Its not the same magnitude like between remote and local calls, but i think it could have a severe impact on performance.


    You think so? In JDK 1.2 perhaps. The use of reflection in modern JDK's is almost negligible. It certainly does not have a 'severe impact on peformance.'

    Additionally i have never seen some numbers on performance and scalability of:
     - JBOSS clustering
     - the JBOSS JMS implementation


    And this is an argument that the performance and scalability doesn't exist?

    So i would claim:

    Your argument seems to be: "I personally have not used JBoss in Production, therefore I conclude that it is unsuitable for production use."

    Not a strong basis for your claims.
  35. Actually, we just switched over from Weblogic to Jboss. I work for a large financial institution, and what caused us to switch was :
    1. The high costs for licensing weblogic.
    2. My weblogic apps deployed and ran on Jboss without any modifications.
    3. Jboss supports current java vm's. I was able to use new features, get bug fixes, and speed improvements.
    4. I had problems with Weblogic's database connection pooling not releasing connections. Jboss fixed all these.
    5. The speed improvements with Jboss over Weblogic in my particular application were very noticeable.
    6. I had terrible experiences with bea support. Trying to get updates or information on their site is like pulling teeth.

    Anyway, this is a small part of why I decided to drop weblogic and go with jboss. These are just my personal experiences and views. Maybe others have had better experiences with bea, or worse experiences with jboss.

    Later
  36. "2. My weblogic apps deployed and ran on Jboss without any modifications."

    Even the Weblogic proprietary deployment descriptors?
  37. 1. The high costs for licensing weblogic.

    > 2. My weblogic apps deployed and ran on Jboss without any modifications.
    > 3. Jboss supports current java vm's. I was able to use new features, get bug fixes, and speed improvements.
    > 4. I had problems with Weblogic's database connection pooling not releasing connections. Jboss fixed all these.
    > 5. The speed improvements with Jboss over Weblogic in my particular application were very noticeable.
    > 6. I had terrible experiences with bea support. Trying to get updates or information on their site is like pulling teeth.

    Funny, I had an almost identical experience with a different commercial vendor! Your item #6 was by far my biggest complaint, but the others were all factors in our decision to switch to JBoss. And yes, our application is also mission critical.
  38. because JBoss worked when the competition didn't.

    > Who was the competition, then? Maybe they did beat an old iPlanet version :-),
    > but I don't believe (yet) that there is a case where JBoss 3 really beats
    > WebLogic when it comes to 7/24 operations, except on license price, of course.

    It's been interesting reading the response to this comment, since at the exact same moment I read this thread our webhotel crashed. It's running Linux with JBoss 3.2. It took a lot of time and effort to get it going, and since one of our customers was preparing an event-website (which is going live any minute now) it was extremely bad timing.

    What was the problem? Well, it's a known issue but the bug has been marked as "Closed - Invalid". As we figured out the hard way it's certainly not invalid. The bug is discussed here:
    http://www.jboss.org/thread.jsp?forum=61&thread=24687&message=3761232
    This particular bug has come up on a number of different forums (do the Google to find more), but no solution has come up. We "fixed" it by clearing all temporary directories. Or at least that's what we think fixed it. All we really know is that at this moment the server is up. C'est la vie.

    I don't know whether this is fixed in the latest release, and since the bug has been marked as "Invalid" I will probably never know. All I can do is upgrade everything and keep my fingers crossed.

    /Rickard
  39. JBoss bug[ Go to top ]

    Umm.. Did you check your code for JDBC statements getting properly closed?

    Quote from the thread:
    > We had that problem and it turns out you have to make sure you close all the
    > jdbc objects in your database access objects. That means you need to close
    > preparedstatement, resultset, and ofcourse, the connection itself in the
    > finally clause.

    And the response:
    > Yes, yes, yes! Thank you. I have been trying to figure out what was creating
    > the /tmp/ddtbXXXXX files for ever now. I was closing my connections and
    > thinking that the ResultSet and Statements would be closed automatically.
    > Apparently not.
    >
    > Now if I can just figure out why JBoss hates the IBM JVM so much, life would
    > be good.
    >
    > Dennis

    Of course you can't do much about this if you're using CMP, but in BMP world you just fix the offending code.

    Personally I've never had this problem (using BMP), we haven't properly stress tested the server yet, but we have run 1..8 hour 'importing' sessions with tens of millions of database ops (all through the session - bmp - dao layers). Just one hour of this 'importing' work compares to weeks of real life usage.

    So I'd guess the problem could lie in the CMP code?

    P.S.
    from 3.0.6? onwards the JDBC wrapper layer detects unclosed connections. Haven't used 3.2.x yet because I trust the 3.0.7 -> to be more stable.
  40. JBoss bug[ Go to top ]

    Umm.. Did you check your code for JDBC statements getting properly closed?


    We don't use JDBC.

    > Personally I've never had this problem (using BMP), we haven't properly stress tested the server yet, but we have run 1..8 hour 'importing' sessions with tens of millions of database ops (all through the session - bmp - dao layers). Just one hour of this 'importing' work compares to weeks of real life usage.
    >
    > So I'd guess the problem could lie in the CMP code?

    We don't use EJB.

    > from 3.0.6? onwards the JDBC wrapper layer detects unclosed connections.
    > Haven't used 3.2.x yet because I trust the 3.0.7 -> to be more stable.

    Not really. We have found that JBoss spits out unclosed connection messages even though statements, resultsets and connections are closed. I don't trust it at all, and have had to filter out those log messages from log4j as they are essentially useless in the current form.

    /Rickard
  41. JBoss bug[ Go to top ]

    Not really. We have found that JBoss spits out unclosed connection messages

    >even though statements, resultsets and connections are closed. I don't trust
    >it at all, and have had to filter out those log messages from log4j as they
    >are essentially useless in the current form.

    I am not sure what technique you are using for persistent storage. You said you are not using JDBC, but perhaps it is used indirectly in your persistence technique -- JDO, etc.

    Whatever it is, perhaps it is not closing resultset, statement, and connection (in that order) in the correct order. Also make sure you put the "close" calls in a try/finaly block to make sure it really gets called even when exceptions are thrown. Depending on the undelying JDBC driver, the oroder of closing may be an issue, in which case, it is not a JBOSS bug, but rather a bug or improper use of the undelying JDBC driver.
  42. JBoss bug[ Go to top ]

    Not really. We have found that JBoss spits out unclosed connection messages

    > >even though statements, resultsets and connections are closed. I don't trust
    > >it at all, and have had to filter out those log messages from log4j as they
    > >are essentially useless in the current form.
    >
    > I am not sure what technique you are using for persistent storage. You said you
    > are not using JDBC, but perhaps it is used indirectly in your persistence
    > technique -- JDO, etc.

    Let me explain. Our product (a CMS/portal) does not use JDBC, but it allows for extensions (i.e. portlet applications) which may use JDBC. We have some examples (not in production, i.e. not on the webhotel that crashed) that use JSTL and even though the JSTL tags (from Jakarta) cleans up the connections properly we get those annoying messages.

    > Whatever it is, perhaps it is not closing resultset, statement, and connection
    > (in that order) in the correct order. Also make sure you put the "close"
    > calls in a try/finaly block to make sure it really gets called even when
    > exceptions are thrown. Depending on the undelying JDBC driver, the oroder of
    > closing may be an issue, in which case, it is not a JBOSS bug, but rather a
    > bug or improper use of the undelying JDBC driver.

    As above, in this case it's not up to us, since the JDBC stuff is implemented in the JSTL standard tags. I've reviewed their code and it seems to do things properly, hence the problem seems to be in JBoss connection wrapper code. Hence, I've turned off the log4j output from it.

    /Rickard
  43. JBoss bug[ Go to top ]

    Whatever it is, perhaps it is not closing resultset, statement, and connection

    > (in that order) in the correct order. Also make sure you put the "close" calls
    > in a try/finaly block to make sure it really gets called even when exceptions
    > are thrown. Depending on the undelying JDBC driver, the oroder of closing may
    > be an issue, in which case, it is not a JBOSS bug, but rather a bug or improper
    > use of the undelying JDBC driver.

    Closing a statement closes the resultset automagically. Unless there's a bug in the JDBC driver.
  44. It's been interesting reading the response to this comment, since at the exact

    > same moment I read this thread our webhotel crashed. It's running Linux with
    > JBoss 3.2. It took a lot of time and effort to get it going, and since one of
    > our customers was preparing an event-website (which is going live any minute
    > now) it was extremely bad timing.

    And to make things even more interesting the www.jboss.org website has been down for some time now...

    /Rickard
  45. Jboss is better[ Go to top ]

    I work for one of these companies -- Sakonnet Technology (www.sknt.com) -- and we switched from BEA Weblogic 6.1. JBoss is better. Sorry.

    Yonatan.
  46. The real action was at JBossTwo[ Go to top ]

    \English\
    One person on the panel was from a financial company with an energy trading application implemented on JBOSS. Another was from a billion dollar business supply company that implemented their e-commerce application on JBOSS. Another person was from a major company that perform airline travel reservations. Their enthusiasm and justification for using for JBOSS was very persuasive.
    \English\

    The point of view I'm getting here is that companies are somehow unified in their approach to technology, and I just don't see that in reality. For example "...a financial company with an energy trading application" and "a billion dollar business supply company that implemented thier e-commerce application on JBOSS". I have no doubt that JBoss is being used there. The more interesting question is "what's the technology mix of those companies?".

    Where I've worked, it's common for "app group A" to use one set of technologies and "app group B" to use something completely different. This is more true as you consider larger companies. To use an analogy - look at a big brokerage house, and find out what database they use. You'll find they don't use "a database" - they likely have Oracle and SQLServer and Sybase, and possibly DB2 and others, in use somewhere.

    Where you find out interesting stuff is when you look at the technology mix and trends. You may find, for example, that Sybase is entrenched but Oracle is slowly gaining share, or that SQLServer is worming its way slowly through the enterprise.

    Likewise, it's not interesting to hear that JBoss is used in some companies. I'd be surprised if it wasn't. What I'd like to know is what technologies a company is using across the board. Do they just use JBoss? Does Websphere or Weblogic or JRun or whatever exist anywhere else in the company?

    \English\
    I bought the plain vanila documentation and was able to deploy an application that was certified for WebLogic on JBOSS to evaluate JBOSS.

    In terms of the cost, you could probably get Marc Fleury himself to come for a training day at you company and still walk away spending less than the competition.
    \English\

    I don't need to buy anything to evaluate Websphere or Weblogic, and their docs are all free and on-line for anybody to peruse at any time. In fact, the big app server companies do everything they can to make evaluation easier. JBoss seems to do the opposite.

         -Mike
  47. This comment is such B.S.. I'm really starting to think the marketing folks at the big companies are hiring people to talk negatively about JBoss. I can't believe anyone who is a developer and delivers real world enterprise applications would say that an open source enterprise application server that gives 24/7 reliability is boring.
  48. \t g\
    This comment is such B.S.. I'm really starting to think the marketing folks at the big companies are hiring people to talk negatively about JBoss. I can't believe anyone who is a developer and delivers real world enterprise applications would say that an open source enterprise application server that gives 24/7 reliability is boring
    \t g\

    I have no connection with either JBoss or any app server vendor or Microsoft. If you'd like, google me and "bio" tacked on and you'll find my web site easily enough, which includes my background. Certainly it's far more verifiable than "t g".

    With that out of the way - there are machines running Xenix on 286's "24/7 for enterprise applications" today. I somehow doubt that fact will cause a stampede towards 15 year old chips and Xenix. Likewise, it's hardly surprisingly that some people are using JBoss 24/7 somewhere. As I said, any technology you can name is being used somewhere by somebody in production, whether it's a good idea or not. If it exists, you'll find somebody using it.

         -Mike
  49. Regarding EJB:

    <quote>
    Mapping standard: If you use CMP, and use multiple app servers, the mapping is totally different. Some people want to try to have some kind of base standard that would work as a default, and minimal information.

    Dynamic EJBQL: There was a hint that this will be in EJB 3.0.
    Would be nice to be able to run queries that return a data structure which spans multiple tables, without having to go to multiple entities. At the moment people use fast reader patterns to bypass EJB for this task
    </quote>

    The same mapping problem occurs with different JDO implementations - I believe that it is enough to have it there. Using Hibernate for persistence allows to have the same lightweight mapping descriptor in any J2EE container that you can think of, even without deployment descriptors and dedicated deployment steps. And persistence of lightweight objects, be it Hibernate-style POJOs or JDO PersistenceCapables, is preferable to using Entity Beans anyway - by far.

    So instead of making the EJB spec even larger than it is today (>600 pages) by adding even more fixes to the misguided Entity Beans and EJBQL, I'm all for deprecating Entity Beans completely, especially CMP. Compared to Hibernate or a decent JDO implementation, is there a single advantage of CMP? Personally, I'm convinced there isn't. And if you really need heavyweight components around your persistent objects, you can always add BMP wrappers for the latter.

    <quote>
    Interceptors: People really want to see these. Even the future (AOP) was mentioned.

    Deployment descriptor defaults: People would like to put in default values for the items that we always have to put into vendor specific files. For example, let us just put in the damn JNDI name, and <*-ref> end points etc etc.
    </quote>

    Let me note that the Spring Framework's bean configuration in combination with its AOP support allows for replacing the most important Local Stateless Session Bean service with an extremely lightweight solution: You can leverage declarative transactions with simple POJO beans that do not even have to be Spring-aware - they just have to implement some business interface!

    Adding custom interceptors to a Spring bean is very easy, and there isn't any need for a deployment descriptor because interoperation of multiple beans works via simple bean references instead of JNDI registrations.

    <quote>
    Transaction Timeout configuration: There are some times, when you know a certain operation needs a long tx timeout (as it will take awhile). Instead of having to drop to bean managed transactions, how about being able to use declaritive programming to set a longer timeout that the default for a particular method/bean.
    </quote>

    The Spring Framework's abstract transaction support allows for the full power of transaction definitions, including timeouts. It can be leveraged by templating, i.e. with a simple transaction callback implementation, or declaratively via Spring's AOP TransactionInterceptor.

    There are default implementations of Spring's PlatformTransactionManager SPI for JTA, JDO, Hibernate, and single JDBC DataSources. The latter two even support specifying custom isolation levels, via exactly the same high-level transaction demarcation mechanism!

    Juergen
  50. incompatible[ Go to top ]

    Please fix your site. Next time do your unit and system test across different browsers not just IE.


    In case no one has told you, firebird kicks the nightly binaries out of internet explorer.


    http://www.mozilla.org/projects/firebird
  51. incompatible[ Go to top ]

    right on n n!
  52. Do we need AOP at all in Jboss ?[ Go to top ]

    Granted, AOP is a cool programming paradigm but I chose Jboss primarily for is J2EE compatibility without the licensing costs . From what I can tell, Jboss J2EE feature implementation is great but I am concerned that with all the focus on AOP etc. , it may get distracted from its core purpose : LGPLed J2EE App Server that makes it easy to write J2EE apps.

    My apps run on Jbos and I dont think I will incorporate AOP in th near term . In fact , I buy into the J2EE standardization paradign 100% and I am not willing to be pulled into AOP until SUN/IBM/BEA add it to J2EE or some other standardized spec.

    Should I be concerned about Jboss future direction ? (Dont troll me with Jboss support, documentation issues etc. -- I am managing well thank you!)
  53. JBoss will continue to be committed to J2EE technologies. We love J2EE technologies as Marc's "Why I love EJB" paper discussed. All we're doing with AOP is opening up the container to the end developer so you can do EJB-like stuff without the constraints of EJB. So, no, you need not be concerned about our committment to J2EE technologies--it is very strong and will remain so.
  54. JBoss will continue to be committed to J2EE technologies. We love J2EE

    > technologies as Marc's "Why I love EJB" paper discussed. All we're doing with
    > AOP is opening up the container to the end developer so you can do EJB-like
    > stuff without the constraints of EJB. So, no, you need not be concerned about
    > our committment to J2EE technologies--it is very strong and will remain so.

    First of all, Marc's "Why I love EJB" paper should be renamed "Why I love caching", because that's what it's really about. And there are a ton of caching technologies that would work as good or better than EJB.

    Second, the important and crucial detail in your statement above is that you say that you "love J2EE technologies" as opposed to "love J2EE". This is important since adding AOP can be seen as simply an extension of *J2EE technologies*, whereas adding AOP as a *developer model* is really just another way to do vendor lock-in (and whether that technology is good or bad is really irrelevant), and this is quite contrary to the *goals and principles* of *J2EE*, i.e. the non-technical part of it.

    (NOTE: I don't want to get into a discussion whether this is good or bad, I just want to describe the situation as it is)

    In light of this, yes, your comment about commitment to J2EE technologies is quite correct, but it is also important to note that this does not mean that you are commited to J2EE, which contains both technological and non-technological aspects (no pun intended), such as not promoting a different developer model which would cause vendor lock-ins.

    The devil is in the details.

    /Rickard
  55. Mc Nealy's keynote[ Go to top ]

    I posted a summary of Scott Mc Nealy's keynote on my weblog.

    Very good session overall!

    --
    Cedric
    http://beust.com/weblog
  56. Um, did I read the original post wrong? I thought there would be discussion of day 2 of JavaOne, which I was interested in because I couldn't go this year. Instead I get yet another free publicity session for JBoss. I don't care how good the product is, I'm quite sick of hearing about it. Anyone have any impressions of anything at JavaOne BESIDES jboss?
  57. Um, did I read the original post wrong? I thought there would be discussion

    >of day 2 of JavaOne

    The orignal posting did mention JBossTwo towards the end.

    >>What did people think of the second day of Technical Sessions and BoF's? What
    >>were your thoughts on JBossTwo?

    The JBoss two event occurred at the the Sony Metreon just next door to JavaOne, which is why it is being discussed along with JavaOne.

    People are writing about JBossTwo because a revolutionary and tranformational application server technology was presented at JBossTwo, which is why the real action was at JBossTwo.
  58. Yeah, I'm sick of seeing this morph into another rah-rah session for JBoos. Peter Frenchie, JBoos is "evolutionary"? What are you smoking dude?
  59. ...another rah-rah session ...


    The quality of the application server speaks for itself.

    JBoss, with the current set of innovations, has become the yardstick by which other application servers are measured.

    The interesting technology that is being discussed here is the AOP technology. This is news, practical, intellectualy stimulating, and relavent to what this forum is all about.
  60. If the JBoss revolution is such a big deal, it should have its own post here. It would make it a lot easier for those of us who are sick of hearing about it. I have nothing against the product and it may be as great as everyone says, but enough already. There are a lot of other things that I'd like to hear the latest news about. I'd say that J2SE 1.5, J2EE 1.4, and Java Server Faces are all bigger news to me and will touch a lot more people. JBoss could be the best thing since Ron Popeil and it still wouldn't warrant all of this attention that its evangelists are forcing on the rest of us.
  61. Where is Day 3 coverage? I have tried to be good about not posting stuff about different days on each discussion but Java One is now over (I just attended the last session) and the coverage is still only up to day 1 and 2.

    David
  62. Day Three is coming :)[ Go to top ]

    Hi -

    Just as we were posting the day three comments the internet died at the Moscone, so we had to move.... it is coming up as I type :)

    Cheers,

    Dion
  63. Day Three is coming :)[ Go to top ]

    u r the man ;-)