Rod Johnson has an SMD moment

JRod is in the house! Matt Asay linked to my post on Spring Source earlier today echoing the sentiment of "how is this an application server?" He thereby attracted the wrath of the Rod.


Matt: I just don't understand why it's an application server. I'm probably too ignorant to appreciate the applicability of the nomenclature, but to me it doesn't fit.

Rod: Indeed, you do not understand. It is an application server because it provides a complete runtime environment that is an alternative to existing application server products. Spring is a part of it. It's sad to see you quoting the bitter FUD of Marc Fleury. He also doesn't understand the technology enough at this point to comment; he clearly has a vested interest in attacking SpringSource; and he's irrelevant to the future of the industry. Rgds Rod


Rod, I know you have a hard-on for JBoss, but keep your sprocket in your pocket. Funny how somebody with the personality of a cold cucumber sandwich suddenly finds his picante! Later in the thread the man lashes out at a Spring user for saying "this is not an app-server, why should I pay you for Spring?"

You haven't been in OSS any time at all if you haven't felt the urge to lash out at a customer, er user who refuses to pay his protection money, and that's the point. Open Source is a bitch. I sympathize. At JBoss, we called this the SMD moment.

Rod is wrong on a couple of things: I DO understand the technology enough to call it out for what it is "an emperor has no clothes" attempt to monetize his ISV base. I will respectfully point out that all this mumbo jumbo about modularity being a "quantum leap to the next generation" is just bullshit. We were peddling modular application servers with JBoss and its JMX base back in 2000, except we had real run-time substance behind it. This is almost 10 years old. We are looking at Tomcat and Hibernate (both from JBoss developers) with Spring, a modular kernel and a little bit of marketing bullshit sauce on top. What is new is the licensing gimmick. Licensing schmicensing. Your users are not dumb, they see right through this flat footed license change, don't get mad and patronize them when they call you out.

He got one thing right, though. I am becoming irrelevant to the industry. I have no troops to command any longer, I just write this blog. On the other hand, I did have the good taste to become irrelevant AFTER I exited the industry.

Comments

Anonymous said…
If all of this is old news, then show me an application server to which I can deploy my app as an OSGi bundle. It's certainly not possible with JBoss, even though JBoss AS5 uses OSGi for modularization *internally* (just like WSAS, WLAS, GF, etc.).
adt43wt342 said…
Who cares. JBoss used JMX to do just that with SARs in 2000. I was excited as a fly on shit talking to the press about modularity and how we were targeting monolythic application servers and what a leap in innovation it was. Some will argue that OSGi isn't even the right user API, which is why Spring has to go to great length to make is semi-consumable. Using a different API to do something that has been around for a decade isn't news. There is no news here but the license change.
Anonymous said…
Are they shipping Euquinox with this platform?
If so, isn't Equinox EPL software? How can that be repackaged as GPL? Check the GPL FAQ.

Good thing, OSGi is not an important part of this and can be left out.
adt43wt342 said…
Yeah someone pointed out that problem to me. It is kind of embarrassing really, means they are flying by the seat of their pants, which is to be expected.

There are other implementations of OSGi besides eclipse, there is JBoss MC :) This way they can get Tomcat, Hibernate, JBossMC, call it Spring and be done with this bullshit.
Anonymous said…
@anonymous

The app server to which you can deploy your apps as an OSGi bundle is BEA WebLogic Event Server. It is also based on OSGi (Equinox) and Spring-DM (though the servlet engine is Jetty). I hope BEA will extend their micro-Service Architecture (OSGi-based) and expose it in regular WebLogic Server. I am sure most of the established app servers will do the same in a 3-6 months timeframe. Then the advantage of Spring App Server will dissapear. As somebody wrote on TSS: it will be again like comparing Tomcat to WebLogic...
Anonymous said…
Sorry for the ignorance, what's SMD?
adt43wt342 said…
It is an inside joke.

One night, I am in London, this is 2002? It is 3AM I am drunk after a dinner with the second EU training. I come to my room, there is a message from my wife, she informs me that she is pregnant with twins. Then I read my email.

This guy, called Trawick James, is complaining that we are charging $10 for our documentation! $10 freaking dollars!!!! He worked at Nielsen Media Research so clearly could afford BEA yet was there lecturing us about how this "was not open source and we were going to fail".

The only response I could muster that late at night was:

"Mr Trawick James,
Suck my d*ck,
marcf"

Of course, it made the rounds, first by the competition, which spread this saying "this is what you get for free!" I woke up the next morning thinking "ooops". Then it became an inside joke at JBoss used to describe that moment where you reach the point where you are really really tired of the "free" in free software. It really gets to you. Our sales force would reach these moments after an initial period of euphoria. I remember this guy writing "when I read "there are synergies between our companies" I know they don't want to pay. Today someone talked about "extreme synergies" I knew it was time to run". Which was a PG13 version of the SMD moment for sales guys.
Maybe we should package Guice + Warp under GPL and start selling massive support contracts for it.

We had to innovate all kinds of cool shit to get Hibernate sessions running inside Guice. It's a new technology you have never heard of: I call it the ThreadLocal.

Dhanji. =P
adt43wt342 said…
Thread Local variables are a great way to pass implicit associations. We used to use them everywhere in JBoss to pass information under the API radar. You should GPL your threadlocal variables and sell it for billions!
Anonymous said…
Mark
I actually think you feel threatened. In the past few years JBoss has been talking a lot about standalone JBoss MC - a platform which was supposed to address development and deployment of POJO based systems without dependency on JBoss API while maintaining component architecture to assemble other platforms (e.g. JEE). Generally I'd say not a bad idea. . . You already had almost that with current JMX Micro container and SAR based services. All you needed to do is achieve non-invacivenes.
However, since JBoss didn't have non-invasive and configurable POJO based application framework you had to start working on your own and with JBoss's complex of superiority you could not possibly use somebody else's. . . As for the runtime core, OSGi was also not considered, but now, since you can no longer deny its importance you are working on providing modules to address OSGi class loading model and integration. But still, you decided not to take on any of the existing OSGi implementations for such core, motivating JBoss's decision as "The current OSGi service registry lacks the features we need. . ." - understood. And if you were to commit to one ". . . it would probably take the same amount of effort, if not more, to put everything together . . ." (see JBoss MC interview). - Well I guess it is nice to know that Spring has better engineers, because they did just that and they did it faster then it takes JBoss to release version 5 which was promised Q2 2006 . . . (I still have the slides. . .). They also did it based on standard (OSGi) that actually makes sense while also taking existing implementation (Equinox), while JBoss MC as proprietary as it gets. . . so who is the hypocrite here?

So, what you really tried to do looks ironically similar to what Spring has actually done and basically beat you to the punch, and now with fully featured run-time environment, completely overtaken the lead role in terms of Enterprise Java innovation. And all you left with is being as colorful in your attitude and language as you've always been. And God bless you Mark, by being so colorful you've contributed to more loss business for JBoss then any competitor could ever dream off, so please remain the way you are and don't change a thing.


Casual Blogger
JBoss certified JEMS Master Architect and Instructor - who no longer cares
adt43wt342 said…
Anonymous,

You must mistake me with someone STILL involved with Red Hat. I left a few years ago with a lot more than "my attitude". It is funny how so many people are still upset about it all.

You are right that AS5 is taking longer than it should have.

Please remember that Tomcat, Hibernate are JBoss products. The packaging in OSGi is irrelevant and this is only a license change play. THEY think you are a sucker.
Ales Justin said…
@Casual Blogger

"you could not possibly use somebody else's"

We would have used somebody else's if it did what we want it to do.

You seem to miss the idea of MC.
It's not just about POJOs, it's about any component model, any environment out there.
If you can find me any other framework/kernel that does what we do in MC, I'll change my statement.

Look at MC homepage, all its sub-projects, and let me know who does something similar.
And no, it's not Spring and their new SSAP toy. ;-)

"Well I guess it is nice to know that Spring has better engineers, because they did just that and they did it faster"

This is what you do when you don't have anything - no existing runtime env or legacy things. Then you do what you're good at, wrapping around existing solutions and spread some fud how anything else is obsolete.

OSGi is nice, but it again doesn't do all one needs when you're writting app server. You can either hack around or do things how they should be done. And we chose the 2nd option.
What we have in MC regarding dependency control, ease of use of classloaders, deployment flexibility with new deployers, VFS, ... It's so beyond any OSGi out there, it's the likes of you who don't care about to look under the hood and just complain how we don't care about anything else.
It's just the opposite, with MC we're giving out again something completely new - a very much enhanced kernel. Probably something that everybody is gonna copy like they did previous MicroKernel. ;-)

"while JBoss MC as proprietary as it gets"

Where do you see the usage of MC?
You're again missing the point.
MC is completely transparent for the user. Even when you're constructing your own runtime on top of MC, mostly you don't see MC.
Like any good framework it exposes the hooks but not internals. And we make very sure we expose just what's needed and hide the impl details behind the right modifiers.
And the separation of artifacts is as clean as it gets; spi, api and plugins. Meaning you can change the impl at any time.
Again, you don't care to look, just complain and making yourself look like a prophet on who's leading the innovation.
Anonymous said…
@Anonymous and Ales:

Anonymous Master JBoss Architect,

I think what Ales meant to say was "SMD"!

;-)
adt43wt342 said…
Shit bill, you have some latency on your line :)
Anonymous said…
85cc免費影城85cc免費影片免費 a 片台灣論壇免費影片線上免費a片觀看85cc免費影片線上觀賞a片免費看免費A片A片-sex52085cc免費影片免費卡通影片線上觀看小魔女免費影城免費看 aa的滿18歲影片免費a片卡通sex888影片分享區520sex貼片區aaaa彩虹頻道免費影片sex520免費影片後宮0204movie免費影片免費色咪咪影片網成人a影片論壇免費影片下載aaaaaa片俱樂部sex520免費影片sex888免費看影片馬子免費影片免費線上a片gogo2sexaaa片免費看短片免費 a 片aaa片免費看短片免費線上avdvd成人圖片區18成人avoooaaa的滿18歲卡通影片免費線上歐美A片觀看sexdiy影城plus論壇dudu sex免費影片85cc成人影城臺灣情色網線上免費a長片免費卡通影片線上觀看彩虹頻道免費影片洪爺影城浪漫月光論壇bbs x693 com sex888 sex383線上娛樂場85cc免費影片sex888 freebbs hksogo 成人論壇sex999日本美女寫真集日本 avdvd 介紹免費觀賞微風成人av論壇aaaa 片俱樂部免費影片下載a亞洲免費影片線上直播卡通美女a片免費試看免費成人視訊視訊情色遊戲援交av080影片sexdiy影城sex520免費影片sex888movie影城情色小說 杜蕾斯成人一本道 a片 東京熱情色影片本土辣妹34c影片直播吉澤明步sex888免費看影片論壇a 免費影片觀賞aa的滿18歲影片av080免費試看sex888 freebbs hk免費aa片試看免費影片觀賞av博物館aaa免費看影片亞洲禁果影城免費a片aaaaa片俱樂部影片5278論壇金瓶影片交流區383movie成人影城aio性愛dvd辣妹影片直播免費a片線上觀看,sex520貼片ut13077視訊聊天avdvd無碼情色電影日本 avdvd 介紹免費觀賞台南援交友留言hi5 tv免費影片1314視訊成人論壇成人免費視訊 完美女人hilive tv 免費電影34c蒼井空影片下載avdvdsex383線上娛樂場aio交友愛情館sex383線上娛樂場JP成人網免費視訊聊天室微風成人

Popular posts from this blog

$6.66B for BEA: Larry goes Shopping

Thug vs Thug: Porsche 1, Hedge Funds: 0

Quickies #3, protecting IP in OSS