Discussions

News: Hard Core Tech Talk with Marc Fleury Posted on TheServerSide

  1. A new Hard Core Tech Talk with Marc Fleury, President of the JBoss Group, has been posted on TheServerSide. In this interview, Marc talks about the current state of JBoss and the open source landscape. He looks at JBoss' microkernel design, client interceptors, and fault tolerance in JBoss. He describes the open source way of life, how JBoss functions as a business, and gives his take on .NET.

    Watch Marc Fleury's Interview Here

    Threaded Messages (66)

  2. Well, he is much more relax.
    May be finnaly his business started doing well :-)
  3. Looks Cool and Have the Right Idea For .Net
    Any how its all about Marketing.Market Jboss at the level of microsoft and People will forget BEA or IBM.Jboss is a defacto and its really a mind blower(Some time it blow off your head with its Nested Exceptions).All in All a Great piece of work from Jboss.
    Keep It Up(And try not to blow the heads;-))
    Faisal Khan
  4. Please post transcripts!!!!!!![ Go to top ]

    I would like to add weight to the request for text transcripts of the brilliant interviews you guys post.

    Thank you for a brilliant app server, designed properly from the ground up, unlike the vendor bulls**t built into some of the other offerinfs.

    Tristan Bergh
    iluvatar at mweb dot co.za
  5. Please post transcripts!!!!!!![ Go to top ]

    I would like to add weight to the request for text transcripts of the brilliant interviews you guys post.


    Each question has a 'text'link next to it.

  6. Can we have these "Hard Core Tech Talks" posted as transcripts as well?

    Most of us work in a corporate environment, where bandwidth is at a premium and streaming video is a no-no.
  7. Hi mike,

    there is a "TEXT" link beside each question. It works, I just read the full interview 2 minutes ago.

  8. Definitely agree with some parts of the interview:

    1) Jboss needs to be certified. I've spent a fair amount of time working through the different versions of jboss to find out that some things weren't working. Take Jboss2.4.4 for example, their JMS durability feature just did not work at all. Granted they came out with a patch available on sourceforge and version 2.4.6 addressed this I believe but I certainly had no time to go digging and testing what worked and what didn't. We're currently using JBOSS in development for a wall st. financial firm but until they get certified, I know that management will have doubts about going into production with JBOSS. I've rather not learn that some feature was missed or not implemented or spend the time finding that out.

    2) .NET is a real threat. Maybe not right now, but they've got everything j2ee has with the exception of entity beans (which isnt a convincing arguement for me to chose j2ee over .NET).

    Hopefully Marc has matured and is looking at JBoss as a very viable services business and perhaps treat it with a bit more professionalism. Too many people have been turned off at his JBoss is free so F**K you if you have a problem attitude.



  9. <QUOTE>
    JBoss is free so F**K you if you have a problem
    <QUOTE>

    But that is how it should be. You got the server for free, if you have a problem with it you can either a) fix it yourself or b) pay someone else to fix it for you.

    If you think any of the developers will jump at your whim, and work for you for free, then "**** You" is exactly what you should expect to hear from them.

    /T
  10. I'm always a fan of NOT telling people who are trying to get to know your product to f**ck off. I don't think a little professionalism can hurt anybody, and it seems to me that simply explaining that there is only so much that the developers can do for free, and commercial support options are available, I think people will get the message. If a user on the forum get abusive at that, ban them. It's that simple.
  11. <QUOTE>
    If a user on the forum get abusive at that, ban them. It's that simple.
    <QUOTE>

    Actually it is not that simple. It requires human intervention. You can create new identities faster than any one person can ban them.

    Internet-101

    /T
  12. <quote>
    Actually it is not that simple. It requires human intervention. You can create new identities faster than any one person can ban them.

    Internet-101
    </quote>
    Thanks for clearing that up. I hadn't thought of that one before.

    If someone is going to go to all the trouble of creating new identities just to plague your forum and harangue you for not offering free support for every one of their questions, then telling them to f**k off is not going to be any more effective than banning them. But I guess at that point I can sympathize with the desire to do so.
  13. <QUOTE>
    JBoss is free so F**K you if you have a problem
    <QUOTE>

    For you guys that feel offended by this, I am truely sorry. Having said that, I think its best to only pay attention to what really matters, the bottom line. Judge what app vendor you want to go with by the one that meets your business requirements in the least costly way.

    99 times out of a hundred, paying huge license fees is NOT the least costly way of meeting your business requirements. Its that simple, for those 99 times, JBoss is the way to go - it will meet your business requirements in the least costly way and thats true even if you need to pay for custom support.
  14. Why is it that every time JBoss comes up as a topic of discussion on this site, all anyone wants to talk about is the occasional graphic insult on the forums?

    1)These types of replies are a very small percentage of what gets discussed in the forums, and usually followed some provocation. But it will be a cold day in hell in this vendor-dominated space before any user mentions the times they actually got free help from developers or JBoss users.

    2)These are free forums and no one is charged for using them or compensated for answering questions. I don't use WebLogic or WebSphere, but I doubt you have direct access to the core developers the way you do on the JBoss forums and if you do, you probably paid $10K for that priviledge so of course they're going to treat you with kid gloves.

    4)JBoss Group probably will start censoring the JBoss forums and then you know what will happen--a lot of the good developers and users will go away and start communicating on their own private internal channels where no one cares about what kind of language they use.

    5)This is the professional/corporate message you guys are talking about. "Dear so and so, we have noted your bug #6789 on our log, it will be fixed in the next version of our product, which will come out in 6 months. Thank you for your patronage."

    6)Finally, those of you who object to the language should go ahead and use SunOne or Oracle since Scott McNealy and Larry Ellison are such shining examples of verbal self-control. With the money they have, they should have mellowed out a whole lot more than Marc Fleury.
  15. Ok, so what convincing argument would you use to select .NET over J2EE?
  16. I hardly can understand why people waste their time on this VERY POORLY documented JBOSS app server. If you need an app server for development purpose I strongly urge you to take a look at Oracle's OC4J container. It's very well documented and fast.

    Francis.
  17. <q> VERY POORLY documented JBOSS app server </q>
    I understand that you can buy the full documentation for as little as $10.
  18. I have used both. JBoss is simply ahead of the curve when it comes to implementing things like EJB2.0, etc.

    OC4J/Orion is a very fast/great product without a doubt but I don't find that the support is neccessarily better. JBoss documentation has come along way.

    We shall see though with regard to developer productivity using things like JDeveloper/Oc4j/TopLink. But having said that, the more one uses the wysiwyg devices the less problem solving skills one will be ultimately left with. The same is true for skills transfer to another firm that mandates/uses other tools.

    If you use JBoss you will understand EJB.

    Cory Adams
  19. <But having said that, the more one uses the wysiwyg devices the less problem solving skills one will be ultimately left with.>

    Extrapolating from that statement it could be argued that the more wysiwyg devices there are, the less knowledge and problem solving skills a person has to have, thus making the engineer a commodity. Heh, pay a lot of money to the app server vendor and get any numskull to engineer your app.

    JBoss takes the opposite approach. Commodotize the software, not the engineer. Give away the source. The real value lies in the expertise of the engineer that can make it work.

  20. <quote>
    JBoss takes the opposite approach. Commodotize the software, not the engineer. Give away the source. The real value lies in the expertise of the engineer that can make it work.
    </quote>

    And amen to that approach! I don't care how many GUI deployment tools the big guns create to admin their app servers. If you but a dumb ass behind the wheel, it will get screwed up.

    JBoss has a giant learning curve. But you have the config files in a clear-to-undersand XML format. You have the source code. If you want to how it works, you CAN. And once you DO know how it works, you can appreciate its modular architecture. As a bonus, you get a lesson in OO design :-)

    Professionally, in production I use WebSphere. I am not a big fan. It is a pain in the ass to do ANYTHING with it. Long live JBoss!

    Ryan

    P.S. As for telling people to f--- off in the forums... I have seen these threads in the JBoss forums. 9 times out of 10 it is a person asking a question that has been answered a thousand time before. They just never took the time to research it in the first place. Laziness and lack of initiative DESERVES an f--- off in my book.
  21. Yesterday I had a couple of problems to deploy a CMP bean under JBOSS 3.0. I've added a couple of System.out.println() in JBoss sources and 10 minutes later I had my CMP up and running ! It was -of course- an error in my deployment files ...

    I could also have found my problem by re-reading the CMP specifications, but I could not afford to spend 10 hours to find my problem .

    Open Source is just perfect to provide you with quick shortcuts , and you learn *a lot* of things in the process !

    As a developer, it was a pleasure to read (part of) JBoss sources


  22. Maybe I should clarify my posting. ;)

    I've never had any real issues with getting Jboss to work other than spending a day debugging application code when the error was that Jboss did not support certain features.

    With a bit of sleuthing around the mailing list and forums, I was able to get jboss up and running with ldap security, ejbs, mdbs and jms under a week - However, I have seen people on the forums and in the mailing list ask questions and get blasted for it. I can understand when someone says that the server is free so don't expect support etc. and perhaps Marc will step up the emphasis that support comes with a services agreement - but meanwhile - alot of people are being turned off from JBoss because of the unprofessional nature of some of the jboss people - Marc included.

    Someone else mentioned that chosing the most cost effective solution was the goal - I agree. But understand that for alot of the firms i work for, the cost of the server was nothing (less than 5%) compared to the development support maintenance contracts. Alot of the vendors are moving towards this model of free appserver and selling services. So if the cost of the server is negliable compared to the overall cost, what app server would they choose? Now throw in the fact that documentation (yes the $10 one) for jboss is still behind weblogic or websphere and the caustic nature of some of the jboss people and you will see that Jboss will lose out.

    Free is wonderful and good but if Jboss wants to have enough clients to build a viable services business - they need to address these issues.






  23. "
    and the caustic nature of some of the jboss people and you will see that Jboss will lose out"

    Really caustic.

  24. I never has a problem with the JBoss people. When I had a problem with the product, I went to the www.jboss.org web site and searched their forum and 9 times out of 10, someone already solved the problem. If I don't find solution there then I post a question and usually within a week, someone replies to it. I also find postings of people who had a problem with the product that I know how to fix then I reply to it.

    The only time I saw the JBoss people telling someone to f*** off was some guy trying get the jboss trademark to steal people away from the JBoss community so he can start his own support site. I don't condone using the "f" word, but JBoss worked out extremely well for me and I highly reccommend it.
  25. JBoss: rocks. Deserves the stamp!

    Marc Fleury: a man, who dare to have an opinion. All the best!

    F**k: Who the hell put the stars in the ****?
  26. <snip>
    But understand that for alot of the firms i work for, the cost of the server was nothing (less than 5%) compared to the development support maintenance contracts. Alot of the vendors are moving towards this model of free appserver and selling services.
    </snip>

    5% ??? Hmmm. I wonder. Perhaps. The more a client is paying huge CPU license fees, the more JBoss is an alternative. But what I want to know is what other vendors are moving towards free appserver? I mean, according to the press, the competition consists virtually of Websphere and WebLogic and .NET. Outside of JBoss and these 3, the effect of any of the other vendors is zilch.

    I am sure there are some people turned off by the replies to questions on the JBoss forums and user list. But I doubt that its that much. I mean if JBoss were really losing out because of this, then Scott McNeally would not be running so scarred of JBoss, as evidenced by the recent thread in these forums.



  27. <snip>
    5% ??? Hmmm. I wonder. Perhaps. The more a client is paying huge CPU license fees, the more JBoss is an alternative.
    <snip>

    Yes, that surprises me too. I'd have thought that licencing fees of the app server came in at significantly *less* than 5% of development cost.

    I think the apps I've worked on for the last couple of years are typical EJB apps (that may be my mistake, but they sure look like typical enterprise applications). They take over 10 developer-years. Which means at least 5 tester-years, at least 3 Business-Analyst-years, and at least 4 of years of general support (DBAs, project managers, dev support, etc). So that's at least 22 person-years.

    At 300 days per year, 25 person years and $800/person-day (hey, I'm rounding to make my maths easy) we're talking about $6,000,000.

    5% of that would be $300,000. Nope, our clients don't spend nearly as much as $300,000/project on app server licences.

    Our experience is that licence fees are nothing. Systems that improve developer productivity by providing easy development and (especially!) easy maintenance are everything.
    BUT: ease of use crucially includes ease of use for experienced developers, not just fancy gui wizards for neophytes.

    Sean
  28. <quote>
    Systems that improve developer productivity by providing easy development and (especially!) easy maintenance are everything. BUT: ease of use crucially includes ease of use for experienced developers, not just fancy gui wizards for neophytes.
    </quote>

    Isn't this yet another reason to use JBoss over some of the commercial alternatives :-)
  29. At least someone sees .Net as a threat to J2EE. I agree wholeheartedly with Marc that Open Source implementations like JBoss are the only real counterr to Microsoft in the mass market.

    The design of JBoss 3.0 is alos one of the sexiest things to grace the java world. The ability to hot deploy services within the app server itself offers some really different possibilities.
  30. Well, for all the talk about JBoss, its billions of downloads and how it's being used everywhere, I'm forced to say this isn't quite the case in the "desert of the real" (to keep with Marc's "Matrix" quotes).

    I love JBoss, but for the last couple of months I've been looking for a J2EE job, and I'm sorry to report I have seen very few mentions of JBoss. I mean, J2EE positions require to know an app server or two, and it's almost always Weblogic or Websphere, not JBoss (or anything else for that matter). Oh wait, I should convince my future employer they should be using JBoss?!

    I have great respect for Marc and his group, and I pray the cowboy attitude doesn't ultimately ruin their efforts. Marc insists on doing it his way and taking the high road (shunning Jakarta because it isn't a true open source business according to his definition), more power to him. I don't agree, but respect his will to fight.

    Unfortunately, the cowboy tune may attract naive technologists, it is a sure turn-off for professionals and decision-makers. And ultimately, the JBoss product will need them to survive: they hold the purse strings.
  31. <snip>
    Unfortunately, the cowboy tune may attract naive technologists, it is a sure turn-off for professionals and decision-makers. And ultimately, the JBoss product will need them to survive: they hold the purse strings.
    </snip>

    Blah, blah, blah. I will say it once again. The ultimate driving force will be the economics. Which app server best suites your business needs for the least amount of $$. And for that, 9 times out of 10, JBoss is the way to go.

    But wait. Maybe you have convinced me. Maybe where I say business needs, I should substitute "need to get feelings stroked and soothed". If that is the way it is, then you are right, JBoss will probably not be the winner.

  32. >>Which app server best suites your business needs for the
    >>least amount of $$.

    ...while remembering that license costs are a fraction of the overall cost of most projects.

    -Nick

  33. We can what we want to. One thing we have to remember is a bit of professionalism in taking on any other technology rather than Java j2ee. To say that .NET is a "fiasco" doesn't make J2ee and Jboss any better. As far as I am concerned I never heard Bill Gates saying that J2ee is
    such and such.
    Faisal
    UK
  34. Which app server best suites your business needs for the

    >>>least amount of $$.
    >
    >...while remembering that license costs are a fraction of the >overall cost of most projects.

    ... while remembering that license costs are (usually) only a fraction of the real costs of an application server. Don't forget the obligatory support/"update" programs that you sometimes *have* to sign.

    /Rickard


  35. >>... while remembering that license costs are (usually) only
    >>a fraction of the real costs of an application server.
    >>Don't forget the obligatory support/"update" programs that
    >>you sometimes *have* to sign.

    Yes. Typically, these are about 10-20%pa. These usually give you upgrades and unlimited tech support.

    But even then, when you compare the full cost of running a development team (not just salary, but salary, tax, insurance, pension, admin, accounting, utilities&services, etc, etc) the license costs (inc maintenance) are still small, by comparison, for a lot of projects.

    If a development team has to code around missing features, or has to waste time working out how to use flakey or poorly documented features, then any license costs savings are eaten very quickly.

    -Nick
  36. From the business perspective congratulations, you are totaly right because you can afford to be a technical freak only at home and not using the time-money spent by a company; try to go to a business manager and tell him "sorry but I needed 3 days to spend only for understanding that the error was a deployment one with the workaround mentioned in I donĀ“t know what newsgroup " ... if you are a project manager you will receive a kick in your ass in the next 3 seconds ;-) for sure ...
    Best regards,

  37. Then buy the commercial support. The bottom line here is that you have a choice. If you have a GOOD team, they can get around deployment etc problems on their own very quickly, and don't need to pay millions to BEA or whoever to deploy on a big machine with a couple dozen CPU's in it.

    If on the other hand you're too STUPID to figure out deployment on your own, then you have to compensate your lack of knowledge with money.

    Depends where you work, how good your team is, etc. With JBoss I get full control of how much money I want to spend and what do I spend it on. To me that is its biggest strenght. Wanna try BEA licensing on a 64 CPU machine? I don't. I rather go with JBoss.

    /T
  38. don't sugar coat it; what do you really think?


  39. >>If you have a GOOD team, they can get around deployment etc
    >>problems on their own

    I agree. However, I dont think most projects do have good teams. Its not necessarily because they are stupid, as you suggest - it might be that they lack experience. They may know plenty about the business domain, but have been C++ developers until now. You cant shoot them for that.

    In any case, mightnt the GOOD developers be better off working on something more complex?

    -Nick
  40. <q>
    but have been C++ developers until now. You cant shoot them for that.
    </q>
    Nick,
    You trying to say that person who knows C++ very well is stupid and don't know how to design and write code? Maybe person who knows Smaltalk or Objectiv C stupid too? Do you think that language shows actual kung-fu skills of developer ?
    If so, then go back and continue with a java translation of "crime and punishment" all within a single handle method.

    Giedrius
  41. First of all, calling production JBoss users "technical freaks" is absurd. It is a viable production server.

    Second, you can waste time screwing around with deployment issues with commercial app servers as well. TRUST ME. You can piss hours upon hours away with commercial support and not find a simple solution to a problem. If you give me a choice between commercial/closed source + third party, paid support and open source + free docs + news groups, I'll take the latter. Besides, I get my best help for commercial app servers from free news groups, NOT the vendor!

    People are making the assumption that developers who need an app server are working for a specific company and making a single app-server decision. What about those who want to bundle an app server WITH their product. What about those who consult/develop applications for several companies, most of whom cannot afford WebLogic/WebSphere (e.g. schools, non-profit organizations). These groups may have critial applications that need a reliable app server, and JBoss fits PERFECTLY. What other solution is there in these circumstances?

    Also, if you ARE developing multiple projects, spending time learning JBoss with have big time payoff down the road. After a couple iterations, you will know your way around developing/admin'ing/deploying with JBoss, but you will NEVER pay for a license. Great ROI of time.

    Not all software needs are backed by deep pockets. JBoss serves this need.

    Ryan
  42. Yes. Typically, these are about 10-20%pa. These usually give

    > you upgrades and unlimited tech support.
    >
    > But even then, when you compare the full cost of running a
    > development team (not just salary, but salary, tax,
    > insurance, pension, admin, accounting, utilities&services,
    > etc, etc) the license costs (inc maintenance) are still
    > small, by comparison, for a lot of projects.

    I'm selling apps using J2EE, so this doesn't hold for me. The costs of the server, including any support deals, are *EXTREMELY* important.

    /Rickard

  43. Yep. Quite right - I agree. In this scenario, license costs would be all-important.

    But, are you finding that organisations already have standards in place viz appservers? Dont they want you to deploy your app on their standard platform? They would have security integration infrastructure in place etc etc. I am genuinely interested to know how customers are buying J2EE apps.

    -Nick
  44. Most don't care. Some want Apache/IIS in front. We use LDAP for security, so that's buzzword compliant. Some want to deploy on iPortal. That's easily fixed though.

    That said, since our app is a standard WAR it should be trivial to deploy to pretty much anything. Also, we are mostly targeting the mid-market clients though, which usually don't have any weird requirements in terms of infrastructure.
  45. Rickard Oberg,

    I thought you were working for TheServerside.com? What happened?

    Francis
  46. <snip>
    But, are you finding that organisations already have standards in place viz appservers? Dont they want you to deploy your app on their standard platform?
    </snip>

    My company is an ISV that embeds JBoss in it's products and we haven't seen this as an issue. If you market your product as a shrink-wrapped turn key solution, most companies don't even ask what makes up the system. We've found that potential clients who bring up this issue aren't really interested in a shrink-wrapped solution in the first place. They want development libraries instead.

    I think that some of the people posting in this thread are locked into the belief that J2EE is only used in corporate cube farms. There are plenty of small to mid sized companies out there who just can't afford to spend 10k, 20k, 30k or more per year on licensing fees. The ability to add this amount to one of my less than stellar programmer's salaries to allow me to hire someone of architect ability is very attractive.

    If Sun is only interested in J2EE being used in the Fortune 1000 companies, we might as well just hang up our Java hats and start learning .Net. The saturation for this market is already 100%.

    For the vast majority of businesses out there, the question isn't between WebLogic, WebSphere, JBoss and .Net. It's strictly between J2EE and .Net. If I'm a business owner already running Windows servers, (as the vast majority of businesses out there are) why in the hell would I spend 10-15 times what the machine cost on an app server when everything I need for .Net is included in the operating system I'm currently running (or available through a free download from Microsoft).

    The big question for Sun is how can they bring in the cash with Java while embracing the only thing out there that can hope to survive Microsoft's onslaught in the long term. They are looking at two less than desirable options. Embrace open source J2EE servers and see their licensing revenue decline or shun them and see .Net steamroll J2EE.

    --Paul
  47. <quote>
    If Sun is only interested in J2EE being used in the Fortune 1000 companies, we might as well just hang up our Java hats and start learning .Net. The saturation for this market is already 100%.
    </quote>

    Who isn't? I for one am glad for all those millions of development dollars flowing from Fortune 1000 to the likes of Sun, IBM, BEA, Oracle etc. The general vein of the various threads seems to be that its only a matter of time before .Net dominates. I do not feel this is a given for two simple reasons, the eco-system that cocoons Java is a whole many orders of magnitude larger than the one that nurtured Word Perfect, Lotus or Ashton Tate. Microsoft (or for that matter the JCP) is yet to demonstrate a internet analogue for their WIN32 API (more important question is can they?). O for one am a lot more optimistic having worked with OS/2, OpenDoc, Raw Corba and NEXTStep. The amount of effort and time I have put into Java and J2EE are just a couple of years from exceeding all of them combined. Plus given the fact that MS is harping on application interoperability (doesn't EJB do IIOP?) via SOAP are they not in fact saying that they only hope for a cut of the pie?

    My 2 Eurocents
    Suhail
  48. For the vast majority of businesses out there,

    >the question isn't between WebLogic, WebSphere,
    >JBoss and .Net. It's strictly between J2EE and .Net.
    >If I'm a business owner already running Windows
    >servers, (as the vast majority of businesses out
    >there are) why in the hell would I spend 10-15
    >times what the machine cost on an app server
    >when everything I need for .Net is included
    >in the operating system I'm currently running
    >(or available through a free download from
    >Microsoft).

    Actually, the question is which architecture will allow me to develope an enterprise solution that can run on any hardware in the future. .Net locks me into Windows XP, a properietary architecture, and Intel Pentium computers, and has not been proven in the marketplace. J2EE allows me to run on anything and there are multiple providers of the solution. J2EE has been around for years and major IT departments have syccessfully deployed J2EE solutions. .Net does not mee my needs which is why I choose J2EE.

    Companies are willing to spend money for a solution that solves their problem. .Net does not solve core enterprise computing cross platform requirements and is risky so I am not interested in it even if they give it away for free or pay me to use it. So the question for me boild down to, "Which J2EE implementation do I use -- WebLogic, WebSphere, iPlanet, Macromedia, Oracle, or JBoss?"


  49. Paul, Rickard,
    Do I take it that as part of the shrink-wrapped product, its you guys that support JBoss as well as everything else? Do you do it yourselves, or do you sub it to Jboss grp?

    >>I think that some of the people posting in this thread are
    >>locked into the belief that J2EE is only used in corporate
    >>cube farms. There are plenty of small to mid sized
    >>companies out there who just can't afford to spend 10k,
    >>20k, 30k or more per year on licensing fees

    Perhaps. However, I used to work for a small cash-strapped company - a regional office, working on tight margins against cheaper competitors - we didnt even have a development budget, and the pay was shite. However, it used to infuriate me that we would always try and take the cheap option on sourcing hardware/software and it would always cost us dearly in the end. It always cost us in extra engineering effort - which killed us when competing with companies with lower overheads.
    It was a case of saving the cents while the dollars were burning.

    But, having said that, I can see how licensing would affect your margins pretty quickly.

    -Nick
  50. Do I take it that as part of the shrink-wrapped product, its

    >you guys that support JBoss as well as everything else? Do you
    > do it yourselves, or do you sub it to Jboss grp?

    We install a "black box" on our client's machines, including JBoss. We don't even mention J2EE and JBoss in our product sheet, not yet anyway. If anything goes wrong, we take care of it. If it's something in JBoss, we will forward it to JBoss (Group). Since we're not using anything fancy in JBoss (e.g. no EJB and no JMX) it's not much in JBoss that can fail for us though.
  51. Rickard,

    I wonder why you use JBoss at all if you use neither EJB nor JMX. Doesn't this leave plain Jetty, basically? Why don't you use standalone Jetty or Tomcat, for simplicity's sake?

    The only possible reason concerning features that comes to my mind is JTA (i.e. explicit usage of UserTransaction). JTA can be enabled in Tomcat via Tyrex but not in Jetty AFAIK.

    We install Resin on our clients' machines as part of our product. We do mention it but do not really discuss the choice with our clients. BTW we also support Tomcat internally but do not have any production environment based on it.

    Generally, I tend to choose an environment of appropriate complexity, meaning no EJB container if not necessary. In the open source (Tomcat, JBoss) and low price (Resin, JRun) worlds, this is not driven by budget but simply by management issues. Web containers like Tomcat and Resin are simpler to handle than JBoss, which is especially important if you have to train external staff.

    Juergen
  52. Currently we could run with just plain Jetty or Tomcat. What we're using right now is the logging and deployment features in JBoss. And yes, in the future the idea is to use JTA, but I thought about using Tyrex directly in order to deploy on any server.

    I'm not religious any way really. It was just convenient to use JBoss for now. We can change it if we really have to, at least as long as we're not using anything fancy. It *would* be nice to use the new classloader stuff in JBoss down the line though, since that would make it easier to do upgrades in running systems.
  53. Jetty does not prevent you setting up JTA and Tyrex. It
    just does not set them up for you, just as it does not setup
    JDBC, JCA, JAAS, etc.etc.

    Stand-alone Jetty stays on subject (HTTP & Servlets) but is
    open and easy to configure with anything.

    If you want all that stuff, use Jetty in an app server like JBoss. Note that JBoss is itself pluggable, so you can strip it down to just the components that you want.

    cheers
  54. Do I take it that as part of the shrink-wrapped product,

    >its you guys that support JBoss as well as everything
    >else? Do you do it yourselves, or do you sub it to Jboss
    >grp?

    Like Rickard, we install a black box. So far we've handled support bumper-to-bumper. If we run into anything we can't find a way through, we'll hit the mailing list archives or (haven't yet had to) call on the JBoss guys. We're using BMP stateless session, message driven beans, home grown JMX MBeans and JCA adapters.

    >However, it used to infuriate me that we would always
    >try and take the cheap option on sourcing
    >hardware/software and it would always cost us dearly in
    >the end. It always cost us in extra engineering effort

    I've used WebLogic and JRun while contracting for large firms and have found their documentation/support to be less useful than having access to the JBoss mailing list and being able to run the source code for the app server in a debugger.

    --Paul

  55. >>I've used WebLogic and JRun while contracting for large
    >>firms and have found their documentation/support to be
    >>less useful than having access to the JBoss mailing list
    >>and being able to run the source code for the app server
    >>in a debugger.

    Yes, having the source is extremely useful when you have a weird problem. It does require an understanding of what is going on, but if you do, then its invaluable. Hopefully though, you shouldnt have to do this too often if the documentation and error reporting is good enough.
    I have found Weblogic's documentation to be pretty good - and their newsgroup is excellent - better than going through the official support channels. (For some threads, the core Weblogic developers spend a significant amount of time answering questions and picking up bugs. If not them, then there are really helpful, and knowledgeable users)

    To be honest, I think that the newsgroup support model is the way to go. It has got to be money well spent by any software vendor.


    -Nick

  56. <snip>
    My company is an ISV that embeds JBoss in it's products... </snip>

    Ok, that's different from what I'm used to, and I hadn't thought much about that situation. So I'd like to back down a bit from my claim that app server licence cost aren't very important.

    I still think they aren't very important for typical enterprise projects where you are developing your own custom solution. But if I was building shrink-wrapped products written on top of an app server, I'd use a free app server too.

    Sean
  57. <I still think license fees aren't very important for typical enterprise projects>

    Then, why oh why is Scott McNealy saying Open Source is destroying J2EE revenue model ??????

    The fact of the matter, they are important and people are increasingly refusing to pay them and opting instead for Open Source and it is huring their revenue model.

  58. whole heartedly agree. I've worked for small companies that have wanted to standardize on a technology/platform and to go down the J2EE road. For some of these companies who may have an internal development staff of a half dozen or so, paying out the relatively large license fees is untenable. The economy is still driven by small businesses, and there are many developers working in these small shops, with "inboxes" full of requests for applications that keep them steadily swamped :-). At least in this scenario, the productivity of these developers can be enormous. I'd agree that in some larger companies/corporations, the relative costs of the development team may be a larger ratio and that advocating the use of jboss or anything open source ( the "can't use it bc we can't pay for it so we can't yell at someone when it doesn't work/we can't figure it out" syndrome ) is frowned upon ( of course many of these companies will pay thousands or million+ for commercial products bundled with lots of open source tools that won't be supported by the vendor ). Still, IMHO jboss has a definite place and role alongside the commercial app servers and is serving the Java community well. For those developers keeping the backbone of the economy alive, multi-thousand dollar licenses are an unreachable dream, and jboss may very well be the answer.
  59. <quote>
    license costs are a fraction of the overall cost of most projects
    </quote>

    Indeed, MOST projects. But suppose I am selling a piece of enterprise software. I want to be able to give my customer "shirk-wrapped" solution. One that I can come in, deploy on their server (or a seperate-managed server), configure, and they are off in running.

    Now suppose this is an application backed by an app server. I want to bundle this app server with my software. Can I do this with a commercial product? Seems like forcing my customers to buy a commercial license each time would SERIOUSLY eat into by margin. Not a very "scalable" business propostion :-)

    With JBoss, this is a not issue. I invest the time learing it. I invest the time developing a solution around it. I make the money selling my solution that uses JBoss.

    In THIS space, JBoss kicks everybodies ass, no?

    Ryan
  60. I like JBoss, and I have only one complaint. I spent the better part of a day trying to figure out what was going wrong at one site. It turns out that JBoss sends the server's IP back to the client, where it over-rides any IP you may set there. This can be a major problem if you need a remote system to connect to JBoss through any kind of firewall or even on a LAN if JBoss thinks it's IP is 127.0.0.1. This may be the way it's supposed to work to deal with HA clustering, but in those circumstances, I think there really needs to be a configuration for this kind of thing :) I hear that you can edit the run.bat to define the rmi server's IP, but that doesn't help if you have multiple interfaces (the network kind).

    It's not a horrible thing for most people, I was just annoyed that I actually had to spend time figuring it out. If you install Java and JBoss on a Linux system, it won't work remotely until you A) override the rmi server ip in run.sh; or B) change your /etc/hosts entry for /etc/hostname to point to the real IP of the machine instead of 127.0.0.1.

    Still, I'm very happy with JBoss. I wouldn't be using J2EE in any of my projects if it were not for JBoss. The bottom line is too great to mass deploy systems with any alternative other than Jonas. I have been unsuccessful in all my attempts to get Jonas up and my beans deployed.

    I'm going to see what I can do to get my university to teach an enterprise Java class using JBoss. At least I know a prof. that I can probably get to work it into his class a little (coming by next week about Java in a class). It's not a complicated technology to use. A lot of the students would end up using .Net and not knowing the alternatives if they don't get it sometime before they graduate. MS has already begun their campaign here, but I have quite a bit of influence, and they are already picking up some mandatory Java classes next semester. (A lot of faculty and students alike got free software from MS... XP, 2000, VS6, VS.Net, misc .Net software, and 2-3 .Net books that do nothing but bash Java every other paragraph.) I think I can combat that with (I already set up a Linux lab) Eclipse, NetBeans, and JBoss. If JBoss had the stamp, it sure would make it a much easier sell.
  61. Exist some ECperf results for JBOSS?
  62. No application server as a whole can be compared with JBoss, it is perfect that all the others.

    You want to learn JMX and EJB? Use JBoss with its source. This is another advantage!!

  63. Video format[ Go to top ]

    Since we're on a web site about a cross-platform development language here, is there any chance you guys could post these video clips in a cross-platform video format like mpeg? Does anyone know of a Linux Mozilla plugin that can handle application/x-mplayer2 format?
  64. I'm can't see how JBoss's business model will make sense to corporate buyers.

    JBoss gives away their core product for free, and the user only pays for support.
    To make money, JBoss needs to make sure their product stays 'difficult' enough to
    sustain a continuous revenue stream derived from support.
    Basically, they're telling customers that 'Look, here's our product for free, but you gotta pay us if you have any questions'

    Now, compare this with BEA - Compared to their licensing costs, their support earnings must be peanuts. This gives them no incentives to 'complicate' their product.


  65. First of all, I don't think the JBoss developers are purposefully making their software difficult in order to generate revenue. That's silly to suggest this. There is big difference between "support" and "training". I think they focus on training - something you will need no matter what app server you use.

    Second, I don't see how their model is that much different from commercial app servers. In the end, customers buy support, not the functionality of the product.

    For example, let's say it costs $10k to purchase some company's app server today. Tomorrow, that company pulls an Enron and goes belly-up. Do you think that app server is still worth $10k the next day? It should be, right? It is STILL the same software it was two days ago.

    People buy support! JBoss simply cuts through the crap and says, "Let's make app servers a commodity. Let's let companies put money where it belongs - talented people administrating app servers, writing software for these app servers, and deploying software on these app servers." If they happen to be some these talented people getting paid for this, so be it.

    Besides, this isn't the first time somebody has used this model. Surely there are a FEW people of there who get paid to admin Linux machines or Apache web servers.

    Ryan
  66. The JBoss folks deserve a lot of credit for what they have done. And it takes guts to take risks.

    Their business model creates a paradox. The geeks who realize that JBoss is a good product don't need to pay for support. They can figure it out themselves.
    The people who do need the support don't even know about JBoss. I'm sure that BEA and IBM spend a good deal on marketing and sales. I don't see the same with JBoss.
  67. There is one additional piece about JBoss support that you guys did ot mention. Suppose your business needs required a feature not supported by the app server. If you go to WebLogic or WebSphere, even if you are a huge corporate client, you will get a response that says, "oh hum. well maybe in a year from now we might stick that feature into a release." With JBoss, you can either immediately implement that feature yourself, or pay a core developer, a core developer to do it for you !!