Geronimo! Part 1: The J2EE 1.4 Engine That Could

An anonymous reader writes "Java-based open source development has come a long way since the early days of developers sharing GUI libraries. Geronimo is a large-scale project attempting to create a certified J2EE 1.4 server based on existing open source components. Take a tour through the Geronimo maze with Sing Li as your guide. Gluecode Software CTO and principal Geronimo contributor Jeremy Boynes shares his perspective on Geronimo and go here to learn how to use the new Eclipse plug-in for Apache Geronimo."

Re:How about Java 1.5?

[MoonFog]

What are you talking about? Using JSP is pretty close to PHP. If you're talking about using servlets .. well, best tool for the job. You don't use Servlets if your resulting page has a lot of pure HTML. Also, J2EE is a server suite with support for EJB's. If you haven't tried these, then you haven't really tried J2EE either.

What do you mean by the code "does not look intuitive"? It's Java, nothing more, nothing less.

Java 1.5 has been renamed to Java 5, and despite the name change, Java 5 is still part of

Re:How about Java 1.5?

[2*2*53*4127]

Java 1.5 has been renamed to Java 5 ... [and] is still part of Java 2. The change was marketing based.

obviously :(

Re:How about Java 1.5?

[Tim C]

You don't use Servlets if your resulting page has a lot of pure HTML.

Well now, that really depends on your architecture. For example, where I work our inhouse framework uses a single Dispatcher servlet to dispatch actions to the relevant Handler classes. Those classes do more or less processing, but the end result is *always* displayed by a JSP - we *never* use a Java class to output an entire page.

You can do the same with Servlets - just put anything the JSP needs into the request, then get a reference

Re:How about Java 1.5?

[Minute Work]

"our inhouse framework uses a single Dispatcher servlet to dispatch actions to the relevant Handler classes. Those classes do more or less processing, but the end result is *always* displayed by a JSP - we *never* use a Java class to output an entire page."

That's a lot of words to say "We use STRUTS"

Re:How about Java 1.5?

[Tim C]

We *dont'* use Struts, we use a framework we developed ourselves. When we first started doing Java projects, around 5 years ago, Struts wasn't really up to the job. It's matured a lot since then, of course, but so has our framework, and so far we've not found a compelling reason to switch.

Re:How about Java 1.5?

[chochos]

for compelling reasons, how about:

• a large user and developer base, which means better support. Your framework is only used by your company, so only you can support it.
• Struts is a popular framework, so you can hire developers who already know it instead of having to train them on the use of your own propietary one. This one is even a selling point to the PHB's, since they know that no training time means the newbies can start being productive sooner.
• It's open source, so if you ever leave your current job and go work somewhere else, you can take that knowledge with you, and use it anywhere else. The knowledge you have about this propietary framework will be useless since it's the company's property (yes, even if you wrote it, since it was on the company's time, unless you had a written agreement saying otherwise)

I'm not even a Struts advocate, I prefer Tapestry myself. But I once worked at a company where we (mostly I) developed a framework for web applications and guess what... I can't use it now that I don't work there. Oh and I had to keep training people on the use of the framework. And I was the only one giving support to the other developers. And these guys licensed said framework to every customer they had where it was used for their projects, and I got nothing for it besides my paycheck.
If I had worked on improving Tapestry or Struts or something like that, instead of concocting a propietary framework, I would still have access to that work today, it wouldn't have gone to waste. That's yet another reason why Open Source is good and one of the reasons I like most (being a developer, I take advantage of a lot of open source frameworks that mainly benefit the developer and contribute back whenever I can, either by promoting said frameworks or sending patches, etc).

Oh and that propietary framework I wrote? I don't think anyone even uses it anymore. Few people really understood how it worked and most of them have also left that company, so now they're left with a useless product, they can't support or upgrade the projects written with that framework. I know that they have even contracted ex-employees for maintenance on projects they worked on while being there... so in the end it wasn't even a good thing for the company either. The use of an open framework would have meant they could hire anyone who knows it for upgrades, maintenance, bug fixes, etc.

Re:How about Java 1.5?

[Minute Work]

Does your *framework* use a lot of *custom* characters to *emphasize* certain variables? :)

Re:How about Java 1.5?

[Anonymous Coward]

If you are copying-and-pasting code, then an object-oriented language is not the tool for you.
Come to think of it, if you copy-and-paste code, the only tool for you is a CS course.

Re:How about Java 1.5?

[chochos]

More like: if you are only copying-and-pasting code, the only tool IS you...

JVM is dime a dozen. Classpath is the key.

[Anonymous Coward]

None of these free JVMs would be anywhere without the fine work of the Classpath contributers. Any sufficiently motivated individual can make a JVM in a year. It may not run quickly - but it will run. Writing the Java libraries on the other hand is a monumentous undertaking requiring dozens of people and many years of work. This is where Classpath comes in.

Let's hear it for Classpath!
Hip hip hooray!

Re:JVM is dime a dozen. Classpath is the key.

[The Mayor]

These aren't JVMs, they are application servers. *Very* different things, really.

Geronimo, JOnAS, and JBoss all work with Sun's classpath. They may also work with the open source Classpath stuff. But these aren't intended as JVM replacements.

Re:JVM is dime a dozen. Classpath is the key.

[NeoBeans]

Also, consider that for mission-critical applications, most vendors will only certify their application server running on specific JVMs.

Part of that is the familiarity they have with the inner-workings of the Sun-provided J2SE classes.

It will probably be a while before we see GNU Classpath leveraged in a commercial application server, but it would be interesting to see if Geronimo or JBoss attempts this before the commercial players do.

Re:what about tomcat?

[s100w]

Tomcat is just a servlet container. A J2EE-compliant app server like Geronimo is a servlet container + a whole lot more.

Granted, most people only use their app server as a servlet container.

Those people would be better off with just Tomcat or Jetty. Interesting/nice to see Jetty included with Geronimo.

Re:what about tomcat?

[The Mayor]

Yes, the Jetty lead works for Gluecode now, I think. That's one of the reasons the JBoss/Jetty integration has been dropped. There's bad blood between JBoss & Geronimo.

JOnAS

[Joff_NZ]

JOnAS [objectweb.org] is our there... free, and LGPL'ed and is already J2EE 1.4 certified

It's also not too bad at all...

Re:JOnAS

[hritcu]

It would be interesting to see a neutral evaluation of the three open source app-servers: Geronimo, JOnAS and, of course, JBoss [jboss.org]. Judging just by the number of users JBoss should be ahead, but which one is actually better?
... my vote still goes to JBoss but I haven't even tried the others. Should I?

Re:JOnAS

[Joff_NZ]

I'd definitely check them out... in our project, we did 80% of the development on JOnAS, but eventually moved to JBoss because of it's more mature clustering implementation. If we hadn't needed that, we were going to go with JOnAS all the way into production.

JBoss?

[wft_rtfa]

Doesn't JBoss do everything Geronimo does? I don't know a lot about Geronimo, but way would anyone pick Geronimo over a more established open source J2EE App server like JBoss?

different directions

[wzzzzrd]

i know all these sayings "why another app server?". the interesting thing is, while relying on and using the j2ee standards the different servers take different directions. jboss is strong in it's persistence layer (ejb3 and/ or hibernate, we'll see), the queueing is also not bad. let's see which way apache is going, ie the GBeans thing is not that bad.