Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sun 'Calls JBoss bluff' on J2EE compliance

Posted by Hemos on from the battle-royale-begins dept.

joshmccormack writes "According to c|net's news.com Sun has finally responded to JBoss Group's request for J2EE compliance testing. Simon Phipps, Sun's chief technology evangelist stated in the article he thinks JBoss Group is bluffing, that their code won't pass the tests, and that some of the code is just copied from Sun."

43 of 216 comments (clear)

  1. Go get em JBoss! by ChaoticChaos · · Score: 5, Insightful

    I'm surprised that Sun put any kind of a negative spin at all on this. An Open Source J2EE compliant Container would be a Cruise Missile right into the Microsoft camp. It's un-friggin ridiculous how damn much IBM, et all, wants for a J2EE compliant server. Honestly, it's outrageous for small companies and your partners you want to deploy to. Honestly, I'm surprised IBM charges as much as they do with all the payroll savings they now have from sending jobs over to India. Where are the savings going? ;-)

    1. Re:Go get em JBoss! by hawkestein · · Score: 4, Insightful

      Dude, welcome to the wonderful world of economics. They're only going to charge less if it means that they'll sell more units and make more money overall.

      --
      -- Will quantum computers run imaginary-time operating systems?
  2. Sun's code by mcrbids · · Score: 5, Funny

    ... that their code won't pass the tests, and that some of the code is just copied from Sun.

    Meaning, that Sun's code won't pass the tests either?

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.
  3. Compliant or not? by The+Bungi · · Score: 4, Insightful
    For example, a company that writes a billing application using J2EE software and tools should be able to run that program on any J2EE-compliant software without extensive manual coding.

    ...

    But the company asserts that its software is compatible with J2EE because applications written for commercial Java applications servers can be reworked to run on JBoss in a matter of hours or days.

    So... what is compliance in this case? It seems to me that if the application has to be reworked and the J2EE standard says otherwise, then there's no issue - JBoss is not compliant? Is that what the J2EE certification actually dictates?

    1. Re:Compliant or not? by BrianB · · Score: 5, Interesting

      The problem is that J2EE servers usually implement the standard and then have non-standard extensions. So, the reworking would basically involve removing the calls to the vendor specific pieces.

    2. Re:Compliant or not? by mightycthulhu · · Score: 5, Interesting

      Each vendor has custom deployment descriptors that tell teh app server "how" to deploy the j2ee app.

      These need to be custom written (or generated with xdoclet) for each app server.

      Each vendor also may more or less strictly enforce the j2ee spec or have hidden proprietary features which freshman developers may unwittingly rely upon.

    3. Re:Compliant or not? by lewp · · Score: 4, Insightful

      There's virtually no non-trivial J2EE application you can just take from one J2EE server to another. Even if both of the servers are officially compliant, say Websphere to Weblogic, there's still enough things left up to the container vendor in the J2EE spec that you're going to need to make modifications for everything to work properly.

      Anyone who tells you that you can just deploy a J2EE app on any J2EE server is either lying to you, has never used J2EE, or is deploying apps where someone already put in the necessary time ensuring it works on a bunch of different servers.

      The current main idea is to isolate the needed modifications to the application deployment descriptors as much as possible, rather than having to change the actual code.

      I'm fairly comfortable editing Java code, and don't have any plans to begin making money off of Java code, so it doesn't do much for me. But in a large enterprise where the developers are far removed from the administrators or for a company trying to make money selling closed-source Java, I suppose this element of J2EE could be a big win.

      Additionally, J2EE is fairly young in a lot of ways, and continually evolving. The more widely-implemented vendor-specific features will almost certainly gain official support in later versions of the spec, so as time goes on the situation should continue to get better and porting between servers should only get easier.

      --
      Game... blouses.
    4. Re:Compliant or not? by dancornell · · Score: 5, Informative

      Even beyond discussing non-standard extensions, there are facets of application development/deployment that are not covered by the J2EE spec. Therefore, in order to provide the environment the application expects, there is application-server specific configuration that must go on.

      Specifically, this is often the case in setting up the JNDI tree for the application and for the individual components (java:/comp/env/) as well as configuring features like EJB 2.0 CMP where you must map database fields to Entity EJB fields, and configuring the specific JMS queues and topics that you want to connect your Message Driven Beans to.

      JBoss uses a jboss.xml config file, BEA WebLogic uses a different configuration file, and other application servers use their own file formats and tools. JBoss offers a tool that helps migrate WebLogic configuration files to their XML format. This doesn't cover non-standard extensions, but it does cover converting many of the application-server configuration options.

  4. It'll pass, no problem by FortKnox · · Score: 5, Insightful

    Those of us that have used the "big 2" webapps (weblogic + websphere) and jboss can tell you that jboss will pass J2EE compliance without any issue.

    JBoss isn't necessarily as efficient or as fast as the "big 2", but its always first in adapting new versions of J2EE and JSP. JBoss is always on top of new java technology, and doesn't have the vendor specific code that the "big 2", unfortunately, have.
    JBoss is really gaining serious popularity in the Java world. Its really a nice product and is true to the "non-vendor specific code" that other app servers claim to have, but don't.

    --
    Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    1. Re:It'll pass, no problem by lewp · · Score: 5, Insightful

      I can't see a problem with having helpful vendor specific features if you're clear about the fact that they are vendor specific.

      Scenario 1: You want the ability to easily move between servers. You avoid using the vendor specific features of the various servers. Everything works out fine.

      Scenario 2: You don't care about moving between servers. You use handy vendor specific feature A and are able to get up and running faster as a result. Again, everything works out fine.

      In 99% of cases I'd go for scenario 1, but I certainly wouldn't be pissed to have scenario 2 available to me, just in case.

      --
      Game... blouses.
    2. Re:It'll pass, no problem by timeOday · · Score: 4, Interesting
      I've been bitten by scenario 2, with CORBA. There was some vendor-dependent code in our stuff, but it's a good product so who cares, right? Well, one year they assigned us a new sales rep and he decided we hadn't been paying nearly enough, or maybe he just wanted a bigger comission and thought we couldn't migrate, who knows. So they tried to quadruple the price.

      We ended up porting to TAO. It wasn't THAT bad, but we did end up writing some stuff twice - first vendor dependent, then vendor neutral. Not money well spent.

      On another but related topic, since TAO was free, the management couldn't believe it would be any good, so we had to give the impression we were just using it for a while until we found something more expensive. Of course, TAO was more standards compliant, open source (fabulous for debugging), and the developers would respond to questions on the same day (much better service than from our very costly support contract with the "other guys.") It made a great impression on me and everybody else for open source, and I gather JBoss is just that sort of project too.

  5. Good news! by Joe+the+Lesser · · Score: 4, Insightful

    Regardless of the outcome of the tests, the only way to make progress is to let things happen. Even if they can't pass the tests, they'll come out of it more experienced and have feedback.

    Perhaps Sun finally felt some heat from the tech community? (pun intended)

    --
    "I only speak the truth"
    Karma: null(Mostly affected by an unassigned variable)
  6. Sounds like a setup to me by bmongar · · Score: 5, Insightful
    From the article

    However, Phipps said he doubts that JBoss software will pass the compliance test. Basing his opinion on public information, he said, JBoss software does not appear to implement all of the J2EE specification.

    Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable. My guess is they were pouring over the spec next to JBoss with a fine toothed comb to find things that weren't implemented and add the to the suite before it is released.

    --
    As x approaches total apathy I couldn't care less.
    1. Re:Sounds like a setup to me by Tailhook · · Score: 5, Insightful

      Sun should already know if JBoss can pass the test since sun already had the test suite and JBoss is freely avaliable

      Sun probably does know. If you were Phipps, would it be better to simply proclaim that JBoss is not compliant and create an Open Source "martyr" or merely suggest it isn't and let the JBoss Group prove you wrong?

      Personally I doubt it is actually compliant. The test suite is very thorough and pokes around in obscure areas of the various specs, some of which are ambiguous. The big vendors spend a lot of time massaging their products to comply with the spec with the benefit of the licensed test suit at their disposal. JBoss hasn't had this luxury. They'll need to go through this process before all the light turn green. Don't be surprised if it takes the JBoss Group a year to get there.

      I don't blame Sun for withholding certification from JBoss. They have managed to get powerful vendors to sign on to the J2EE platform based on the promise that there is a payoff in terms of licenses. Now that these big vendors have established a credible market for the platform, Sun can let JBoss play and provide a low cost point of entry. Had a "free", certified compliant implementation existed early the big vendors may have thought better of it. Sun now wants JBoss compliant because it makes the platform stronger to have a solid low-cost implementation.

      JBoss is not threat to the big J2EE vendors. Implementing a single server side class in J2EE requires writing at least three separate bits of Java code for the home, remote and bean interfaces/classes. There may also be local variants of these to overcome marshalling overhead. XML metadata must also be maintained. This is for a single EJB. If you have many EJBs, you have a very large number of source files and bits of metadata that must be kept in sync. The big commercial vendors sell tools that make this easy. You can do it with vi, but you don't want to. If JBoss is really compliant and really as good as its hype, the vendors will just incorporate it into their own products, just like they did Apache. Their "value add" still remains, because JBoss does little or nothing to relieve the sheer development burden of distributed J2EE development (aside from good dynamic deployment.)

      J2EE is now technically credible and supported by real vendors with real products. Now Sun wants to make it cost effective by allowing JBoss to compete after getting its certification ducks in a row. Wise move.

      --
      Maw! Fire up the karma burner!
    2. Re:Sounds like a setup to me by Tailhook · · Score: 4, Interesting

      XDoclet is a code generator. It uses metadata in JavaDoc tags to generate source files that make a complete EJB. This is merely one function of an integrated environment. XDoclet does not provide integrated version control, integrated UML design, server side debugging or any other of a large number of features you get with a typical J2EE development tool such as JDeveloper 9i.

      I'm not knocking XDoclet or JBoss or anything else. I'm only pointing out that there are obvious advantages to the commercial platforms. When a project grows beyond a handful of geeks you need "high-touch" tools.

      I know J2EE developers that could just barely manage to install J2SE+J2EE properly on their local machine on a good day. You can not expect these people to adopt XDoclet/Ant/CVS/ArgoUML/etc and make it all function productively. You can expect them to write perfectly good business applications from within an integrated environment.

      --
      Maw! Fire up the karma burner!
    3. Re:Sounds like a setup to me by steve_l · · Score: 4, Interesting

      Sun dont want to let jboss near the tests, but apache forced them in to it last year, when they threatened to stop working with Sun unless open source projects got access to the test kits (not the reference impls) under various terms and conditions. Axis is the first Apache project to do this, and it has been beneficial. Except when their tests are different from the spec, which happens sometimes.

      A certified JBoss (it'll happen eventually) will hurt BEA and IBM, and Sun via licensing fees. But it is good for Java.

  7. Finally! by delirium28 · · Score: 5, Interesting

    "Call their bluff"? Come on. JBoss has been waiting for almost a year for this test. Will everything pass without a hitch? Probably not, but that doesn't mean that they won't get the certification right away.

    I love JBoss, I've used it for pilot projects for a few years now, but I've never been able to get it into production, and one of the reasons is that it wasn't "certified" by Sun. All hail the day when JBoss is certified!

    ---
    I read your email...

    --
    Who is John Galt?
  8. Sun: "They copied us" by stratjakt · · Score: 4, Funny

    However, Phipps said he doubts that JBoss software will pass the compliance test. Basing his opinion on public information, he said, JBoss software does not appear to implement all of the J2EE specification. Phipps also noted that JBoss appears to be using software written by Sun

    translation:

    "They copied us, and we suck!"

    I will never ever say JBoss out loud. I can imagine what it would sound like, and it's frighteningly lame.

    --
    I don't need no instructions to know how to rock!!!!
    1. Re:Sun: "They copied us" by abigor · · Score: 5, Funny

      "I will never ever say JBoss out loud. I can imagine what it would sound like, and it's frighteningly lame."

      Unlike "stratjakt", which just rolls off the tongue.

  9. Re:Cruise Missle into Microsoft?? by ChaoticChaos · · Score: 5, Insightful

    Uhhh, have you heard of .Net? It's popular with many shops because of the lower cost of entrance. The cost of a J2EE Container is a big obstacle for many shops.

  10. Sun/Phipps needs to show more class by Kefaa · · Score: 5, Insightful

    "I predict that now that we're calling their bluff, they will make up another excuse for not doing the tests," Phipps said.

    A comment like this from Sun is unnecessary and appears childish. This kind of remark is unprofessional and serves no purpose except to build animosity.

    What will he say if it does pass? If it does not pass, did his comment serve any purpose except to give JBOSS a reason to believe the test was biased?

    1. Re:Sun/Phipps needs to show more class by sprytel · · Score: 5, Insightful

      Sure it does... remember, its all about perception.

      When JBoss doesn't pass (as has been pointed out before... its Sun's test and a free product... so they must already know the outcome), then Sun can say:

      "See JBoss is an interesting little diversion, but if you want a REAL J2EE-COMPLIANT APP SERVER, then you need to buy a commercial product."

      Undoubtedly, JBoss will fix the areas where they are not compliant. But by the time they do, a new J2EE spec will probably be out, and they won't be able to pass again. Keep in mind that all the major app server vendors define the specs via JCP... so JBoss is necessarily going to always be playing catch up.

      Its a pretty smart move by Sun. It keeps them from looking like the bad guy, or "anti-open source", but at the same time serves to marginalize JBoss as a competitor to "legitimate" commercial app servers.

    2. Re:Sun/Phipps needs to show more class by Trailer+Trash · · Score: 5, Funny

      A comment like this from Sun is unnecessary and appears childish. This kind of remark is unprofessional and serves no purpose except to build animosity.

      Gee, childish, unprofessional remarks from a Sun employee? What's next? Lies from Redmond?

      --
      Do you have ESP?
  11. Config files, etc... by lordpixel · · Score: 5, Informative

    The J2EE standard doesn't cover everything you'd ever need to do to get an application off the ground.

    eg, most enterprise applications allow you to connect to a database. J2EE defines a way of naming the database connection ("DataSource") with a logical name. Say "MyBigDB". This is a name bound into a JNDI tree - basically a directory. Give the directory "MyBigDB" and you get back an instance of DataSource that can connect to your database.

    At some point these convenient names "MyBigDB" must be mapped to actual parameters (hostname, username, password, port number) of the database.

    J2EE doesn't really specify this. Each vendor has their own config file syntax for doing this mapping.

    So this is the sort of thing they mean when they say it takes "hours" to port. You find out where JBoss keeps its config files, what the syntax is, and how to map MyBigDB to the hostname etc.

    Hopefully none of your code changes, its just a matter of defining mappings in config files. The more complex your application, the more points of contact with "the real world" or "the bare metal" it probably has. J2EE hides a lot, but it can't hide everything.

    --

    Lord Pixel - The cat who walks through walls
    A little bigger on the inside than out

  12. Copied Code?!? by bokumo · · Score: 5, Insightful

    If Sun thinks the JBoss group copied code, then why don't they prosecute them under copyright law?

    --
    Physicists do it with a big bang!
    1. Re:Copied Code?!? by rossjudson · · Score: 4, Insightful

      If they think the JBoss guys copied code, why don't they just point out the file and line numbers. It's open source, isn't it?

  13. Hold on one second... by jaaron · · Score: 4, Informative

    This may not yet be a chance for rejoicing. See the ServerSide article on this same issue:


    Phipps' remarks are bizarre since it is obvious that no vendor can pass the J2EE 1.4 test suite, since J2EE 1.4 itself is not in final release yet.

    There's something not quite right about all this, so it may be a setup by Sun to put JBoss in a difficult position.

    --
    Who said Freedom was Fair?
  14. Still useful by mysterious_mark · · Score: 5, Insightful

    Even if it isn't 100% J2EE compliant, it still works as bean container, and is in general easier to use and way less expensive than the commercial alternatives, there are some of us who like to use java based web platforms, but don't have six figures to spend on it. And if it isn't J2EE compliant, this isn't such a big issue if the points of non-compliance are openly known. Viva the OSS MM

  15. How does that help Sun? by sterno · · Score: 4, Insightful

    Sun makes money by charging for the testing and certification and licensing of the J2EE standard to the likes of IBM and BEA. If I can download a free product, that's licensing fees that don't go to Sun. Sure, I'm not buying Microsoft's products, but it's not like Sun would be benefiting either.

    --
    This sig has been temporarily disconnected or is no longer in service
  16. Evangelist? More irony? by cdthompso1 · · Score: 5, Insightful

    Isn't it ironic that this guy Phipps' job title is given as "chief technology evangelist" yet he snidely quips that he doubts JBoss, a product that has done much to advance J2EE in the small to mid-size business arena, will even pass the tests?

  17. JBoss and others by dagooncrn · · Score: 5, Informative

    I used all 3 most popular containers (JBoss, WebLogic, Websphere) and seems that JBoss is the best choice. Websphere was always late with standards and Weblogis was always ahead (Websphere was EJB1.0 + some 1.1 compliant when Weblogic had almost all EJB2.0 features), but Weblogic had many errors in it's bleeding edge versions. JBoss was developed fast and with latest specs in mind but I didn't encountered any real problems.

    --
    -- mg
  18. Re:Shouldn't Sun by HoneyBunchesOfGoats · · Score: 4, Funny
    .backwards is everything Russia Soviet In
    Does this mean that Yoda was a communist?
  19. No joke. by CatOne · · Score: 5, Interesting

    We (IONA) certified our app server on Sun, and we failed something like 50 tests which we investigated and found the tests were acutally bad. The thing is, others had passed these same tests -- what we found is that the J2EE reference implementation had bugs which "passed" these bad tests, so obviously everyone else who was certified was using large parts of the reference implementation in their test suite. Heh.

  20. Re:Cruise Missle into Microsoft?? by lewp · · Score: 5, Interesting

    He's right, though.

    This hurts IBM and BEA a lot more than it will hurt Microsoft. Moving a Microsoft shop to J2EE is hard. They're two totally different things. It's like trying to turn a toy factory into a car factory.

    Re-training and re-certifying all your developers is likely to hurt your pocketbook a lot more than the cost of a Windows license, or even a Websphere license, even if it is (and it is) ridiculously expensive. Thus, we're not going to see a mass exodus away from .NET, no matter how much I'd love that.

    Moving a Weblogic shop to JBoss is easy. You just start dealing with a different company. Most smart companies do this all the time when they see a better deal. You call a different support number, maybe spend a week or so in a class learning what's different, and save a lot of money. Of course, the fact that JBoss is widely regarded as being more developer-friendly than the big commercial servers is great, too.

    I'm glad Sun is offering to do this. I'm not surprised they had to think long and hard before doing so.

    --
    Game... blouses.
  21. Re:Cruise Missle into Microsoft?? by Anonymous Coward · · Score: 5, Insightful
    Uhhh, his point is that .NET is cheap while J2EE is expensive, and that Sun therefore benefits from the arrival of JBoss.

    Bringing up Mono supports his point.

  22. You are right! by vchoy · · Score: 4, Funny

    Quote: "...Phipps also noted that JBoss appears to be using software written by Sun."

    ./run.sh
    .
    JBoss Bootstrap Environment
    .
    JBOSS_HOME: C:\jboss-3.0.6\bin\\..
    .
    JAVA: c:\j2sdk1.4.1_01\bin\java
    .
    JAVA_OPTS: -Dprogram.name=run.bat
    .
    CLASSPATH: ;c:\j2sdk1.4.1_01\lib\tools.jar;C:\jboss-3.0.6\bin \\run.jar
    .
    ------
    .
    09:01:01,453 INFO [Server] JBoss Release: JBoss-3.0.6 CVSTag=JBoss_3_0_6
    09:01:01,468 INFO [Server] Home Dir: C:\jboss-3.0.6
    09:01:01,468 INFO [Server] Home URL: file:/C:/jboss-3.0.6/
    09:01:01,468 INFO [Server] Library URL: file:/C:/jboss-3.0.6/lib/
    09:01:01,468 INFO [Server] Patch URL: null
    09:01:01,468 INFO [Server] Server Name: default
    09:01:01,468 INFO [Server] Server Home Dir: C:\jboss-3.0.6\server\default
    09:01:01,468 INFO [Server] Server Home URL: file:/C:/jboss-3.0.6/server/default
    /
    09:01:01,4 68 INFO [Server] Server Data Dir: C:\jboss-3.0.6\server\default\db
    09:01:01,468 INFO [Server] Server Temp Dir: C:\jboss-3.0.6\server\default\tmp
    09:01:01,468 INFO [Server] Server Config URL: file:/C:/jboss-3.0.6/server/defau
    lt/conf/
    09:01 :01,484 INFO [Server] Server Library URL: file:/C:/jboss-3.0.6/server/defa
    ult/lib/
    09:01: 01,484 INFO [Server] Root Deployemnt Filename: jboss-service.xml
    09:01:01,500 INFO [Server] Starting General Purpose Architecture (GPA)...
    09:01:01,687 INFO [ServerInfo] Java version: 1.4.1_01,Sun Microsystems Inc.
    09:01:01,687 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.

    -------I admit as a user it's my fault in using "Sun's" Sdk. I will correct this mistake as soon as possible. -----

    09:01:01,687 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
    09:01:01,718 INFO [ServiceController] Controller MBean online
    09:01:01,796 INFO [MainDeployer] Creating
    09:01:01,812 INFO [MainDeployer] Created
    09:01:01,812 INFO [MainDeployer] Starting
    09:01:01,812 INFO [MainDeployer] Started
    09:01:01,812 INFO [JARDeployer] Creating
    09:01:01,828 INFO [JARDeployer] Created
    09:01:01,828 INFO [JARDeployer] Starting
    09:01:01,828 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeplo
    yer@12d3205
    09:01: 01,828 INFO [JARDeployer] Started
    09:01:01,843 INFO [SARDeployer] Creating
    09:01:01,843 INFO [SARDeployer] Created
    09:01:01,843 INFO [SARDeployer] Starting
    09:01:01,843 INFO [MainDeployer] Adding .....

  23. Re:Cruise Missle into Microsoft?? by Paradise+Pete · · Score: 5, Funny
    Uhhh, have you heard of Mono?

    Yes, but only in one ear.

  24. sun speak by kungfoobar · · Score: 4, Funny

    sun speak: I predict that now that we're calling their bluff, they will make up another excuse for not doing the tests, Philips says.

    Translation: 'We may have *modified* the tests a little so you guys can't pass. Best of luck!'

    sun speak:JBoss appears to be using software written by Sun.

    Translation: 'We at Sun never use other people's codebase for our products (apache regex), it's wrong that JBoss does.'

    sun speak: making the compliance test available will make it clear that Sun does not want to intentionally obstruct JBoss Group's efforts to gain J2EE compliance

    Translation: 'We pray every night to the same God Microsoft does that JBoss burns itself to the ground. Linux should die to.'

  25. Sun is afraid of JBOSS; So is BEA by cfury · · Score: 5, Interesting

    I just spent a night at BEA eWorld speaking to a sales rep and developer at a dev2dev Open Source Software roundtable. I thought at first this would be a good thing... You know, how to use OSS tools and software, getting BEA to acknowledge that it's cool, and that, most importantly, developers WANT OSS tools and software.

    But the evening turned into a whole BEA vs JBoss debate. The sales guy was kind of rude and cocky about JBoss... and everytime we tried to change the subject (to the benefits of OSS, for example), he kept going back to slamming JBoss.

    I was very disappointed in the BEA sales rep, I expected a much more professional and conversational attitude. His partner, whom I think was a developer, had a much better view and kept trying to calm his friend down.

    Admittedly, I can see where JBoss is a potential threat to BEA, but really, they have nothing to be afraid of (so far.) Their products are positioned for large applications and large enterprises, and JBoss would have trouble supporting that right now... (unless a large application needed to support a smallish to medium sized app...)

    The plus side was there was a whole table full of people who were *for* OSS, including other tools, not just JBoss. In fact, I was later told that our table (in a room full of discussion groups) was the most active and interesting. Maybe someday those guys will be managers, directors, etc and will make decisions based on wisdom and common sense, and not sales and marketing pitches.

    [Disclaimer: I love BEA's products. They're doing some great stuff -- they just need an attitude adjustment when it comes to OSS and other tools.]

    And while I'm rambling... I just spent the last two days trying to get corporate approval to run the Tomcat based servlet container that comes with the Actuate 6.0 Reporting tool. There are a whole slew of valid business reasons why this is a Good Idea, but it was a no go. Instead, we have to link that product into our BEA servers, which aren't load balanced or very well protected for failover right now. Big Corporations seem to be afraid of OSS, and have extremely arbitrary rules for choosing software. This is something the OSS community needs to work hard to change. We're making headway, especially in terms of operating systems (RedHat), but we need to push even harder for other products.

  26. JBoss architecture vs Sun code by Roullian · · Score: 4, Informative

    Jboss is based on a revolutionary architecture, using extensively AOP. This is completly different from Sun's own application servers (the J2EE reference implementation and Sun ONE).
    I *really* wonder which code could have been copied from Sun???
    As JBoss is open source, I guess Sun could point out which specific parts where copied?

    Concerning Jboss's J2EE compliance, it is widely known that Marc Fleury hates Web Services (and RMI too..). So obviously there are chances that JBoss will not be compliant in that field. But that will only matter to the very tiny part of the population that uses SOAP... I mean, as long as my EJBs are running ok, I don't really care if some obscure part of the spec is not respected...

    1. Re:JBoss architecture vs Sun code by catch23 · · Score: 4, Informative

      Ya know, they really haven't done anything with AOP yet. I mean, they do use the whole dynamic-proxies thing, but that isn't really AOP. They are about to "try" doing some AOP stuff but they're encountering lots of speed bumps because they're discovering that they can't create a custom class loader that the Sun class loader will actually load. (chicken-egg problem, see JBoss-AOP forums for more details). Basically they're trying to rewrite the Java system classes but are finding that they either have to hijack the Sun class loader, or they have to statically modify the classes beforehand. They're trying to use concepts of AOP so that they can (in the future) convert every single basic java object into an EJB and implement transparent caching features without the programmer explicitly specifying it in code. They are not actually using Aspects, AOP is just one of those buzzwords for anything dealing with reflective programming languages or MOP related. They're trying to make use of Chiba's Javassist package to do bytecode rewriting as their own form of AOP, but what they don't realize is that Javassist is just not capable of doing the things they want, yet they are too stubborn to try and use something like BCEL which may be harder to use, but can offer a lot more.

  27. Tempest in a Teapot by JohnnyCannuk · · Score: 4, Insightful

    Read this and try forming opinions other than "Sun sucks" or "Go JBoss, you rock".

    I love JBoss. I use it daily. I even contributed some patches to it back in the 2.4.4 days. I like
    Sun stuff. I use it daily. The company I work for is a Sun iForce Partner (we're also and MS partner, in case you think I'm realy biased). I look at this issue, and read the above article (which I was pointed to on the JBoss forums, ironically) and I see two sets of people acting incredibly childish. I won't say the two companies or organizations, because I know there are people on both sides of this issue that don't share these opinions. So Sun won't certify JBoss? Big woop. I'll still use it. So will most of the developers I work with. And we'll still use it for dev and then port to BEA or OC4J because it's easy to do (Websphere bites and is incredibly hard to port to...yet certified!). If JBoss "goes beyoind J2EE" and doesn't support the standard anymore (J2EE 1.4 in the future, it complies to 1.3 as far as I can see), I will stop using it.

    Period. End of story. I'll use OC4J...not open source but free for development and certified. It's also easy to use.

    I don't give a rat's ass about AOP, or even JMX or micro-kernel crap. I care about writing EJB's (Session not entity...we've discovered Apache OJB),JSP's and servlets to the J2EE standard that are easily moved from one app server to another. I care about using the latest features of the spec. As soon as I can't do that, I'll stop using that server. If JBoss goes to far beyond J2EE they will lose. If they don't like the current spec, maybe they should get involved with the JCP to affect some change, like Apache.

    As for Sun folks thumbing their nose at JBoss, perhaps they should remember that without JBoss, there would be hundreds of thousands less J2EE developers out there and likely .Not would be much more prevelant. They should also thank JBoss for technical innovations like drag and drop deploy of .ear's and hot deploy (is anyone at IBM reading this?), which has been picked up BEA and Oracle to varying degrees because of the competition.

    Given that, and the exchange in the above article, maybe I'll switch to Jonas or OpenEJB (or another Open Source server if it exists).

    This whole thing is ridiculous. Stop whining and start working to beat out .Net

    --
    Never by hatred has hatred been appeased, only by kindness - the Buddha
  28. Re:Open Source Question by Wavicle · · Score: 5, Insightful

    So now please answer why JBoss needs to be compliant other than allowing legacy to run?

    Because if JBoss is not compliant, nobody will use it. The fact that it is open source is a really poor argument for not needing standards compliance. Should GCC's cc be non-ANSI C since if you needed it to be ANSI C you could just open up the source and make it conform? The Apache HTTPD server is compliant to the HTTP spec. Tomcat is a reference implementation of a servlet container.

    There's an ocean of difference between being able to access the source code and being able to effect changes to that source code. Open source should conform to standards.

    --
    Education is a better safeguard of liberty than a standing army.
    Edward Everett (1794 - 1865)