Slashdot Mirror
The Apache/Sun Relationship Worsens
d6y writes "Over on the O'Reilly weblogs there's an entry on the relationship between Sun's Java Community Process and Apache. Sun have been rubbing people up with wrong way (the problems of licensing open source J2EE containers; stuts v. JavaFaces; log4j v. JDK 1.4 logging....) and I hope this gets sorted out real soon.
See also the original VNUNet article and Apache's position paper."
People who write to and use these platforms get what they deserve, and, presumably, what they want.
One thing I don't understand, but I'm sure that many people in the \. community do:
Is there any point to non-certified but highly compliant implementations? I'm sure the lack of certification would scare away commercial users, but what about others? Are they worth the trouble? Would they even want to use the stuff?
Sun's relationship to the OSS community is extremely difficult. Within Sun there is a lively corporate culture and a will to produce a high quality, performant and comfortable UNIX system. Unfortunately, the very same culture also fosters a special kind of NIH syndrome - what pain it was to get Sun to include current popular OSS tools like Perl, Bash and the like into their standard OS distribution!
From a strategic POV, Sun is being increasingly cannibalized in the low end market by Linux and BSD solutions, and at the same time forced to include stuff for free that is differentiating them from Linux like SDS, Sunscreen, ACLs and similar because Microsoft offers such features in their OS for free as well.
At the same time, Sun is not ready to embrace the OSS movement like, for example, IBM does. They fear that giving away code and ideas that they see as differentiation and advantage in an increasingly difficult market would harm their position and they would like to have some security and control, which the OSS process inherently cannot offer at all.
So basically what we have here is a corporation with a fear to "let go" coming under more and more pressure in a difficult economic situation.
I work for a company that has chosen to deploy J2EE applications using JBoss, and has seen substantial success from doing so. The applications running in JBoss bring in hundred of thousands of dollars for us, and support multi-million-dollar vendor/customer data exchanges.
As for the certification, more and more it comes with too high a cost. The price tag on the other "compliant" packages is way, way out of scope, and returns only minor additional results for us. You must also view certification from Sun's point - how much have they charged other major players for certification? How would those companies react if Sun now certified *for free* an open-source J2EE container given away *for free*. Where, for example , would BEA's pricing put them? Grossly overpriced, perhaps?
Sun is caught in a rough position. If they reverse their position and certify JBoss, they run the risk of alienating current partners. If they don't certify them, open source communities will continue to take jabs at their so-called support for open projects.
In the end, we don't really care. By our analysis, JBoss returns the best ROI of any of the J2EE containers. Certification is just a respectful (and expensive) nod from Sun. It doesn't define the real-world value of a product.
JBoss is *not* ready. The single fact that I had to change my code when going from 2.4.3 to 2.4.4 means that there are new bugs with point releases that I have to work around. Granted, I do a lot of heavy transactional-based work and touch much of the container, but with WebSphere, WebLogic or even Orion, I've never had to "fix" my stuff after they've fixed theirs.
Also, JBoss comes bundled with Catalina, Jetty or Tomcat. That's great. Did you know that, up until 2.4.4, the Catalina release wouldn't allow you to change your root context for web applications? You could fix this by maintaining your own source of JBoss, but, when you're trying to manage your own project, the last thing you want to do is manage your own revision control for the application server. They fixed it in 2.4.4, but
Missing little crap like that makes we worried about the *very* complex transactional nature for the EJB's and the upcoming clustering solution. That stuff is hard! Even BEA, with all its time and money, has had a hard time with its clustering/failover implementations.
JBoss' implementation was written up on onjava.com. Want to know their suggested solution? Write your application to not need clustering and use a Cisco load-balancer. That's because their solution doesn't work.
What about the auto-deployer? Don't try to update your EAR or WAR by overwriting the archive if the file's larger than 4MB. JBoss'll undeploy your aplication and fail to redeploy it.because it doesn't know how to wait until the copy operation is over. There's some settings to help alleviate this problem, but it's not perfect. I don't expect it to be from JBoss...I would from BEA, for example.
So, let's think a bit before handing the crown to JBoss. Is it well docuemented, code-wise? Yes. Is it fast? For the most part. Does it behave as advertised? No. Will Marc Fleury make sure JBoss succeeds through sheer will? Yup. Will he step on toes? Yes, don't get in his way (for better or worse).
The Baron
Every time someone runs apache on Solaris, Sun sees that as another iplanet sale lost.
Then why did Sun package Apache as part of the default install of Solaris 8?
Solaris now ships with Apache, Perl, and Java. Out of the box, it is a pretty potent web-serving OS. And it can be downloaded for free or delivered to your front porch for about $50US (only Free operating systems are more cost-effective; M$ Windows doesn't even come close).
iPlanet is expensive enough that it really doesn't compete with Apache directly. Typically iPlanet is used in "enterprise" environments alongside J2EE and Oracle. When a company can throw a ton of money at a big server and Oracle, iPlanet is just the icing on the cake.
Healthcare article at Kuro5hin