IBM buys Gluecode

karvind writes "After acquisition of Ascential, Big Blue has bought the application management firm Gluecode. From the article: IBM plans to allow its customers to download Gluecode software, develop their own application server software, and begin using it -- all at no cost. IBM also said it will become an active contributor to the Apache Geronimo open source project and will expand the existing community of developers."

Comments

Diabetes

[Anonymous Coward]

I got diabetes from too much glucode.

Amazing technology!

[Anonymous Coward]

... download Gluecode software, develop their own application server software, and begin using it -- all at no cost

Next up from IBM -- they mail you sand, which you can use to develop advanced microprocessors and chipsets, and begin using them, all at no cost!

Followed by their patented 4k GIF reading "WORK FASTER," intended for use to develop your own source code control system, and begin using it -- all at no cost!

For the coup de grace, an online whiteboard, allowing you to jot arbitrary equations and thus evewntually develop amazing new branches of quantum physics, revolutionizing modern thought. All for just two percent of royalties (plus naming rights)!

Thanks, IBM!

Re:Amazing technology!

[Afrosheen]

"I think they really understand what our computer and tech culture is becoming."

Yeah they sure do. It's a source of great income for those with deep pockets like Dell, Microsoft, and IBM. IBM is just leveraging their power to stay alive and grow. They invested heavily in Linux from a number of angles to benefit themselves first and the rest of us second. I don't have a problem with their methodology, just pointing out that their the primary benefactor of the technology they purchase and open up like this.

More info

[kbahey]

Editors: articles are increasingly lacking context. Please editorialize a bit more.

The company's web site and Product overview for Gluecode SE would help next time.

Re:Job Losses

[Anonymous Coward]

This is part of their overall plan to return to profitability: Give stuff away and make it up on volume.

Apache Geronimo

[Nik13]

For all of those who didn't know, it's a J2EE server.

Apache Geronimo Homepage

I knew of [apache jakarta] tomcat, but not geronimo. Sorry, I guess I've been living under a comfy rock for too long.

Re:Apache Geronimo

[TopSpin]

...it's a J2EE server.

So is Websphere...

o.O

Gluecode actually goes beyond J2EE; Apache Derby is supplied as a DBMS. It merges all of these independent parts into a cohesive, turn-key J2EE stack with a few extras, like a web based configuration/management interface.

Jetty is the HTTP listener. I really like Jetty. For most small J2EE apps, if you need something that isn't in Jetty Plus (besides the database,) you need to think hard about whether you're over engineering. If you can live within Jetty Plus, your life will be far more pleasant; you need a JVM, tar/winzip and vi/notepad to manage that server.

Why has JBoss moved away from Jetty anyhow? It use to be the default HTTP listener and servlet engine, but it looks like they've diverged. NIH?

Re:Why not use JBOSS?

[carlfish]

I know. We should all just use JBoss and ignore any other attempt to make an open source Java application server. Competition is a terrible thing to have in any market, and should be discouraged at every opportunity.

Charles

The enemy of their enemy...

[brasten]

Of course they would support Apache Geronimo. It's in IBM's best financial interest to protect WebSphere, and protecting WebSphere means not allowing JBoss to become the de facto open-source AppServer standard. At the same time time, they want to appear friendly to open-source to attract developers.

So, they support Apache Geronimo to compete with JBoss.

Apache Harmony

[olafura]

IBM has campaining for open source J2SE.
When Classpath is turning almost compliant, Apache tries to help it's accepance by requesting
them to move the code to the Apache Licence.
The man behind it is a VP at Gluecode.
IBM buys Gluecode.

Also there was a rumor on jpackage about an undisclose three letter company that
was getting them to test a free j2se impementation.

Re:Apache Harmony

[Thumpnugget]

IBM has already written their own JVM. But they made the mistake of looking at Sun's source code and signing a license agreement with Sun for said source code. Now they can't write an actually free-as-in-speech one themselves without Sun suing that JVM out of existence for 'contamination' issues and IBM proper for breaking licensing agreements.

So, all they can do now is encourage other people to hurry up and write a free-as-in-speech JVM and, for example, provide financial incentive to that end without actually providing anyone to do the work itself.

Gluecode?

[Anonymous Coward]

IBM plans to allow its customers to download Gluecode software, develop their own application server software, and begin using it -- all at no cost.

Does that mean there's a lot of cutting and pasting involved?

First thought about "IBM buys Gluecode"

[renrutal]

Larry Wall sold Perl?!?!

Re:Why not use JBOSS?

[dsgfh]

very single application server has classloading quirks. with BEA/WAS,etc you get to call them bugs and cry and shout that things aren't working right, then wait two weeks for a potential patch from support, that may or may not work.
Yup... they're bugs b/c they're documented to work one way, and actually work another. However the class-loading heirachy is very clear (until you start deploying applications that do their own class-loading as well ala Sun Portal Server).

Any application server that, when it doesn't find the class it's looking for in your deployed application, goes looking for class files in other deployed applications (& yes, I know you can turn this behaviour off, but recall experiencing other problems when I did).

i think the specs are farily clear regarding the application container provider's responsibilities regarding classloaders.
Actually, the spec is very loose when it comes to class loading. It does state that applications shouldn't assume that classes will be loaded by a different classloader, but doesn't state that the servers shouldn't work this way.
By convention amongst the major vendors, it seems you get a heirachy of classloaders, where your application can only load classes deployed with itself or its ancestors. JBoss by comparison flattens it out, so you can load things from other applications.
Clear specification, rather than phrases like "should not assume that each component is loaded in a separate class loader and has a separate namespace" and "Typically this will require the use of a separate class loader for each application.", where the classloading behaviour/heirachy is mandated would be preferable in my books. & while I'm ranting, so would getting rid of app server specific deployment descriptors.

if you read the jboss docs/examples, you'll see that there's a simple ant execution to setup multiple server instances without port conflicts.
I'm obviously running a different version to you, as I've not seen this in the docs. Instead, I've found that I have to enable the bindmanager (which isn't used by default in 3.2.x), then grep the rest of the server structure for all the ports it could possibly be using (hasingleton comes to mind as one offender). This is as per the instructions on the jboss.org website. Possibly it's changed in the latest versions. Unfortunately my corp clients don't like rapid upgrade cycles.