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

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.

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?

[dsgfh]

JBoss is great when you only want to deploy a single application on a single box. Start needing to deploy multiple applications on a single server instance & you quickly get into classloader hell (damn ambiguous specs, and JBoss deciding to take a unique approach to just about everyone else).
Try & set up multiple JBoss instances & ask yourself why pre-packaged JBoss components in the deploy directory (where you deploy your applications) refer to specific ports configured elsewhere, and you have to change a half dozen obscure files to get it to work.

Don't get me wrong, I think JBoss is great. I could just do without some of it's quirks.
The Apache Foundation has become a commercial Java developers best friend, esp license wise. Regardless of how compatible other licenses are to internal development, minimal restrictions on what a client can do with their IP gives them a warmer, fuzzier feeling & lets me get on with not re-inventing the wheel.

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.

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.

JBoss and Jetty

[mparaz]

JBoss moved away from Jetty because Mort Bay is part of the Core Developers Network which forked from JBoss. Jboss now supports Tomcat.