Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Picking a server-side Java framework

By Prince Caspian in Technology
Thu Apr 19, 2001 at 08:16:01 PM EST
Tags: Software (all tags)

There are a staggering number of technologies available for building a Java-based web site, from pure servlets to full-fledged application servers. I have been researching open source options, and I'd like to present what I've found and generate some discussion based on your real life experiences with these technologies.

To provide focus for the discussion, here are some criteria (in order of importance for my particular project) for evaluating each framework:

  1. My primary concern is maintainability. This means that it should be relatively easy to add features as the site evolves. I have some very complicated systems (especially related to user preferences) in mind that may or may not be in the initial site. The flip-side is that initial development time is not as great a concern.
  2. Somewhat related is the requirement that there be a clean separation of code, presentation, and content, so that programmers can do their job while site designers to theirs and content producers do theirs. The site designers shouldn't need to know Java.
  3. Performance is a secondary but very important criteria, since I hope the community will grow quite large. A large percentage of the content will need to be dynamically generated for each user. So, to start, it would be great if serving requests doesn't require a legion of servers. On the other hand, as things grow, it should be possible to throw more hardware at the problem to fix it.
  4. The framework should have a bright future. In this respect, Sun is probably the safest. I just want to avoid being stuck with a framework that is no longer maintained.

(In case you're interested, I'm planning on building a web community with a similar structure (but different focus) as h2g2 or E2).

Here are what seem to be the best options:

  • Servlets and JSP - This is obviously the most standard option, which probably means it will be the most work, but possibly more flexible and supported in future.
  • Struts and JSP - This appears to be a set of servlets that provides a more structured framework within which to develop your site. Should reduce initial development time and encourage good design.
  • Turbine and Velocity - A template engine plus a replacement for JSPs. Seems to include everything and the kitchen sink. Seems a little more non-standard compared to Struts.
  • XMLC - This technology allows manipulation of XML/HTML pages through Java objects. I like how it separates design and code, but am unsure how elegant (and scalable) a solution it for the type of site I'm creating.
  • Barracuda - Billed as a "presentation-layer framework". I understand this one the least, but they claim it competes with Struts and Turbine.

There are several other subprojects within the Jakarta and Enhydra projects as well as a few other independent projects.

Before making a decision, I need input that only people with experience can provide. Can anyone share their experience developing large-scale dynamic sites using any of these frameworks (or any others I'm missing)? What has been most frustrating developing for a given framework? Have you experienced any real world performance issues? Are the development and user communities for the technology active?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


I've help build a site using
o Pure servlets and JSP 34%
o Struts and JSP 5%
o Turbine and/or Velocity 0%
o XMLC 1%
o Another template-based framework 1%
o Another DOM-based framework 5%
o Something completely different 12%
o VI 39%

Votes: 58
Results | Other Polls

Related Links
o Servlets
o Struts
o Turbine
o Velocity
o Barracuda
o Also by Prince Caspian

Display: Sort:
Picking a server-side Java framework | 50 comments (40 topical, 10 editorial, 0 hidden)
servlets and JSPs. (4.00 / 1) (#2)
by rebelcool on Thu Apr 19, 2001 at 01:35:02 AM EST

everybody supports these. They're beautiful. Virtually every server using them is open source (though not all are free..such as Resin, which is not free for commercial use).

Personally, i use Resin (caucho.com). Resin is beautiful, easy to setup, incredibly fast and extremely stable. It's free for non-commercial use. It's open source still, and uses the QT license.

For free solutions, a combination of apache + tomcat can be used. However, configuring the two of these to work together can be a pain in the ass. I used to run Jserv w/ apache (precursor to tomcat, and still distributed by some..such as oracle). Had all sorts of stability problems and it was a pain to configure.

COG. Build your own community. Free, easy, powerful. Demo site

are you sure? (none / 0) (#5)
by Garnier on Thu Apr 19, 2001 at 05:02:39 AM EST

However, configuring the two of these to work together can be a pain in the ass. I used to run Jserv w/ apache (precursor to tomcat, and still distributed by some..such as oracle). Had all sorts of stability problems and it was a pain to configure.

I thought it was remarkably easy to set up :-)
In less than a day I had a couple of Apache web servers talking to a number of JServ application servers, and transferred all my servlets from the development machine. mod_jserv also does very nice load balancing, and I never had any stability issues.

I haven't tried using Apache/mod_jserv with Tomcat though: I've only set up a very low volume site with Tomcat so I used it as the web server as well...

[ Parent ]

yep (none / 0) (#16)
by rebelcool on Thu Apr 19, 2001 at 10:55:14 AM EST

the thing would crash randomly too. I'm happy with Resin..never crashes and it's much faster than apache w/ jserv or tomcat. Hell, for static pages it's up there with apache on speed.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

No separation of logic, content, and presentation (2.00 / 1) (#14)
by Alhazred on Thu Apr 19, 2001 at 10:49:29 AM EST

JSP is no more advanced than ASP. They both suffer from the same problem, which is something the original author was apparently aware of.

By embedding logic in your presentation system like JSP does, you can't seperate the two. XML/XSL/XSLT (Cocoon) is the most comprehensive system for achieving separation.

Since it is itself a servlet, you certainly are not loosing the ability to do servlets and JSP pages in combination with Cocoon.

I haven't run it in a production environment yet, so I will not even attempt to comment on performance, stability, etc.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
uhm.. (none / 0) (#15)
by rebelcool on Thu Apr 19, 2001 at 10:53:53 AM EST

JSPs are servlets themselves, and most people put all their logic in servlets and only use the JSP to call information back from the servlet to do display.

I dont know where you're getting "no separation of logic and presenation" because that is very very wrong.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

mod_jk (3.00 / 1) (#19)
by Prince Caspian on Thu Apr 19, 2001 at 11:07:37 AM EST

I wonder if things are better now that mod_jk (a Tomcat-specific Apache module) can be used instead of mod_jserv. Can anyone compare the stability of the two modules?

[ Parent ]
My experiences with mod_jk (none / 0) (#30)
by Erbo on Thu Apr 19, 2001 at 12:49:11 PM EST

Recently, I've been working with an installation that uses Apache and Tomcat together, using mod_jk to connect the two. I've found that it does seem to be faster than connecting through Tomcat alone.

There is, however, a problem if you want to use multipart/form-data POSTs (say, for doing form-based file upload) with a mod_jk installation that uses the ajp13 protocol. There's a bug in Tomcat 3.2.1 that prevents it from handling this case properly. Upgrading to Tomcat 3.2.2b3 fixed it for me; you could also drop back to using the ajp12 protocol, but it's not as flexible for the long term.

It's also worthwhile to design your Web application so that, when you move to Apache/Tomcat integration, you can configure the static pages and graphics to be loaded through Apache alone rather than through Tomcat. This gives an additional performance boost. Some creative use of the Apache Alias directive can be used to do this.

I hadn't used mod_jserv in the past, but I'm pretty happy with the mod_jk setup.

Electric Minds - virtual community since 1996. http://www.electricminds.org
[ Parent ]

this is why i like resin (none / 0) (#35)
by rebelcool on Thu Apr 19, 2001 at 06:51:22 PM EST

its all in one very fast, easy to setup package. Sure, for commercial use it does cost a moderate amount, but for a business the savings in the labor of configuring the servers to work together properly makes it well worth it.

Plus, its much much faster than tomcat for java serving, and its static speeds approach apache's

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Jakarta/Tomcat - Servlets/JSP (4.00 / 1) (#3)
by arheal on Thu Apr 19, 2001 at 02:05:40 AM EST

I have done quite a bit of work with these. Jakarta/Tomcat is currently the reference implementation (state of the art), is very easy to build and install and painless to use. My exeriences with WebSphere (IBMs JSP platform) are a much different story - pain to install and use (but some nice features like remote installation of new JAR files). JSP is THE standard. Servlets are nearly so. Tomcat is the reference implementation. So the choice is clear....
There can be only one!
This doesn't exclude Struts (4.00 / 1) (#4)
by Garnier on Thu Apr 19, 2001 at 04:28:18 AM EST

Struts is just a framework for developing JSPs and servlets which helps you separate the view from the controller so you don't end up filling up your JSPs with Java code.

Furthermore it looks like Struts will become a standard: Craig McClanahan who built Struts is now the technical lead at Sun for the JSP and Servlet reference implementation. This means that Sun will soon be recommending Struts. As a matter of fact they are already doing so.

[ Parent ]

Why not try Cocoon... or something like that (4.50 / 2) (#9)
by neuneu2K on Thu Apr 19, 2001 at 06:53:05 AM EST

For tidy separation of content and presentation, XML+XSL is very good (but if you do not have a BIG machine, forget about speed !), Cocoon (from xml.apache.org) is a good framework for a dynamic PAGE server. If you want something more site-oriented (anybody say "portal" :-), Building from scratch the navigation, user account and customisation system and using XSL for presentation (xml.apache.org should be your friend) is the most tweakable system i know.

- "And machine code, which lies beneath systems ? Ah, that is to do with the Old Testament, and is talmudic and cabalistic..." - Umberto Eco
XSLT, XSP yet another technology to learn (none / 0) (#40)
by kellan on Fri Apr 20, 2001 at 10:16:42 AM EST

I would suggest starting with servlets, and JSPs, which have a much simpler learning curve (for me at least) before jumping into the esoteric world of XSLT.

I've found XSLT slow, difficult to use and debug. I also found the model inappropiate for building highly dynamic apps, perhaps I simply don't grok it, but it seemed much more focused on publishing a site, then an application. Safari from Oreilly seems like the perfect project for XSLT/XSP because they already had all their books in XML (DocBook) and wanted to generate a web page from them. Something like K5 for example would probably be horrendous.

Some people love it, think its the way to go, maybe I had a bad expirence, but I hated it, and sound I gained nothing over JSP. Also I've yet to see a good book on the subject, where I found an excellent one on JSP, one I could learn from, but more importantly one I could give my team, and feel confident they would learn from.


[ Parent ]

Why Java? (2.00 / 6) (#11)
by spinfire on Thu Apr 19, 2001 at 07:37:11 AM EST

What is the reasoning behind doing server side scripting with Java, as opposed to Perl or PHP/ASP? I can see an argument of "Java is a more sophisticated language", but so is Perl. Also, in my experience, JSP and Java based websites are often slow and poorly done. There are also web based application servers such as Zope.

I fail to see what the clear advantage of Java is.

Freelance Hacker. spinfire on FooNET.

Relentless language religion (4.00 / 3) (#12)
by slaytanic killer on Thu Apr 19, 2001 at 09:14:58 AM EST

I think there should be a study of K5 engineering. One precept would be that when writing an article where K5'ers have various religions, there should be something serving as a disclaimer early in the article.

After all, a statement like
"I fail to see what the clear advantage of Java is."
could be applied to Perl, ét al. There really IS no worldshaking, lovekilling reason why one should pick Java over Perl, but the very point of asking what server-side frameworks Java has is to learn about the advantages of Java over others. One has to start somewhere, and not get bogged down in questions like, "Why are we using digital machines instead of analog systems for serving content?"

[ Parent ]
re: Why Java? (none / 0) (#21)
by Prince Caspian on Thu Apr 19, 2001 at 11:20:26 AM EST

I answered some of this above, but as for the specific languages you mentioned, here are my reasons: For Perl, since the language is not as structured, I find the resulting code can become a little less well designed. I realize coding standards can be imposed, but with Java it is earier for someone unfamiliar with your system to understand the pieces.

As for the others, I'll admit I don't know much about them. It is my impression, though, that they are less programming languages and more a form of server-side scripting. Since I'd like to create some rather complex structures and algorithms, I would be more comfortable using a full-fledged language.

[ Parent ]

JIT, persistance (none / 0) (#38)
by hany on Fri Apr 20, 2001 at 04:02:51 AM EST

Few advantages of Java Servlets over Perl (Perl as classic CGI script language):
  • JIT: Java bytecode is compiled into native machine code which is running faster then interpreted language
  • persistance: servlet is initialized once (after server start-up), not with every request (as classic CGI); also it can share resources over multiple requests (for example DB connection)

Of course, it is possible to serve something faster and better with Perl CGI than with Java Servlet.


[ Parent ]
Frameworks (3.50 / 2) (#13)
by Kinthelt on Thu Apr 19, 2001 at 10:32:33 AM EST

I'm writing my co-op workterm report on this. I'm comparing XMLC, Cocoon, and our in-house EasyPub. If your need for open-source isn't too important, I'd give my company a call.

BTW, EasyPub is much better than Cocoon, which is much much better than XMLC.

appservers, and alternatives (5.00 / 4) (#17)
by kellan on Thu Apr 19, 2001 at 10:56:26 AM EST

Really wish you had contributed a little more then just asking a question, but oh well.

You don't break the choices down quite right.

First you've got to decide if you want to go with a full blown application server or not. Examples include Enhydra with its XMLC markup language, but there are others as well. (BEA for example) With an application server you get a number of fancy features, connection pooling, object-relational mappings, caches, etc. All useful features for building a large website, and all features which you can find elsewhere, but sometimes its nice to have them bundled for you.

Struts clocks in at something less complex then an app server, but more complex then anything else you've mentioned. Struts has some nice design patterns, and utilities that you'll find yourself recreating in any large servlet/jsp based applications.(How many people here have written a method to populate a bean from a request object, raise your hand) However I find its emphasis on taglibs a little awkward, and hard to feel comfortable with. So I would reccomend against Struts, but that is based on my shallow interactions with it.

Then it sounds like you are unsure if you want to use JSPs, or a template system, there are pros, and cons to both. The pros to JSP are its a standard, this means:

  • you can find people who know it
  • you can find good books on it
  • you can find people to steal code from
  • its actively being maintained and improved by the industry
the cons are that JSP is not perfect, and often encourages a mixing of presentation and middle layer. Javaworld has a good article on the cons of JSPs, that is also an introduction to my favorite of the templating soltuions, FreeMarker

A couple of other technologies you might look at our: Resin as a super fast servlet container, and JBoss or ExoLab for opensource J2EE implementations.


EJB servers (3.00 / 1) (#23)
by Prince Caspian on Thu Apr 19, 2001 at 11:35:53 AM EST

I have a feeling asking this question is going to lose me some respect (because it is obvious?), but how do EJB servers (like JBoss) fit in the picture? Are they a replacement for Sun's Enterprise Java SDK? So a solution might look like Apache+Tomcat(Servlets/JSP)+JBoss(EJBs), right?

no loss of respect :-) (none / 0) (#25)
by Garnier on Thu Apr 19, 2001 at 11:46:35 AM EST

It depends on the server:
The j2ee sdk comes with Tomcat 4.0b which serves the servlets and JSPs, and j2ee which is an EJB container/server.

IBM's WebSphere (Advanced & Enterprise editions) is a Servlet, JSP, and EJB container/server in a single package. The Standard edition doesn't do EJBs.

[ Parent ]
Separation (none / 0) (#26)
by SlydeRule on Thu Apr 19, 2001 at 12:14:24 PM EST

how do EJB servers (like JBoss) fit in the picture?
In a nutshell, they address this:
requirement that there be a clean separation of code, presentation, and content
A properly separated and layered system uses:
  • JSPs for UI presentation
  • servlets for UI logic
  • EJBs for business logic and DB access
  • a database for business data
In addition, as this article points out, your Web server has to be accessible to the public Internet, so you must assume that despite your best efforts, someday, somehow, your Web server is going to be cracked. A couple of quotes from that article:
Your web servers SHOULD NOT, under any condition, have a database on them, or be passing ODBC calls straight to an ODBC-compliant database. Your web servers should not have the access, across the network, to even connect to your databases in this manner.
Best Practices tell us that we do not put core application logic in our ASP, ASP+, JSP, or otherwise scripting-powerful web code.
Any stuff that is too risky to go in the Web server goes in the app server as EJBs. An EJB should mediate any DB access. And contrary to what might seem obvious, you don't want Entity EJBs doing that job. Actually, you probably don't want Entity EJBs at all. Stateless Session EJBs are the workhorse EJBs; the other types are for very special circumstances.

On a separate subject, Struts looks very good, at least on paper. If it works like it says, it's something to be seriously considered for helping to maintain the separation between UI logic and UI presentation.

[ Parent ]

Oops (none / 0) (#27)
by SlydeRule on Thu Apr 19, 2001 at 12:22:29 PM EST

Before anyone gets too riled, when I said
A properly separated and layered system uses:
I (obviously?) meant:
A properly separated and layered J2EE system uses:

[ Parent ]
containers, and lingo (none / 0) (#28)
by kellan on Thu Apr 19, 2001 at 12:43:11 PM EST

"EJB containers" man, not servers. just call them containers, and everybody will assume you know what you're talking about.


[ Parent ]
MVC litmus test (4.00 / 1) (#29)
by Prince Caspian on Thu Apr 19, 2001 at 12:47:47 PM EST

This article, suggested earlier in the discussion, provides a good test for code/presentation (model/view) seperation. I'll let you read it yourself for the complete example, but here's the basic idea:

You would like to display a list of items (say, the contents of the ubiquitous shopping cart). As always with MVC, there should be no code in the View (eg. the JSP). Also, it should be possible to change the presentation of the list (say, from an ordered list to a table) without changing the code.

The article demonstrates that this is not possible with JSPs. Either iteration code must be placed in the JSP, or, worse, HTML put into a custom tag.

FreeMaker handles this problem well. How do other frameworks handle this situation?

EasyPub (none / 0) (#32)
by Kinthelt on Thu Apr 19, 2001 at 04:10:21 PM EST

I just noticed that the web page for easypub is down right now. I'll have to sick the sysadmin on that.

EasyPub doesn't need any code changes if you're going from a list to a table. Its templates are 100% seperate from its business logic. And its business logic is seperate from the data source. We have a demo here. The URL on the front page is for the WML version of the same application, the only difference between the WML and HTML version are the template used.

[ Parent ]

MVC is not a goal in and of itself (none / 0) (#33)
by GusherJizmac on Thu Apr 19, 2001 at 06:10:38 PM EST

MVC is a way to attack certain problems. You cannot therefore conclude that if something doesn't meet the requirements of MVC that it is bad. It is simply irrelevant.

If you use JSP to do what you are talking about, you can do it pretty easily with custom tags:

<mytags:foreach list="theList" item="oneItem">
<td><mytags:property item="oneItem.name" /></td>
To change this to a drop-down or bullet list, just change the HTML part of it. Yeah, the "foreach" is code, techincally, but you are trying to make a working website, not an MVC demo.
<sig> G u s h e r J i z m a c </sig>
[ Parent ]
Keep it simple and standard (4.00 / 3) (#34)
by GusherJizmac on Thu Apr 19, 2001 at 06:21:37 PM EST

Using things like Struts, Turbine, XMLC, Barracuda, and other things that are not widely used makes it hard to find people who can work on it. This hurts your maintainability.

Also, do not obsess over OO or MVC or any design pattern just for the sake of having an OO-compliant design. Do not obsess over separationg of code and content, except where it makes sense.

Worrying about these things will distract you from the task of getting your website to do what you want. I'm not saying you have to hack it, just make it simple and make it meet your needs

I would suggest using Jakarta Tomcat, as it is the reference implementation of servlets and JSP, and I would suggest outlining a simple, lightweight architecture and data model.
<sig> G u s h e r J i z m a c </sig>

Need more details (none / 0) (#36)
by donaldp on Fri Apr 20, 2001 at 01:36:54 AM EST

Which framework you choose really depends on what you want to do. For instance

* how data driven is it (ie do you access N different items per page)
* how much dynamicism do you need
* how many people do you want to work on it

Out of all the frameworks Turbine is by far the most mature and you can use it with Velocity/JSp/FreeMarker/ECS/other. It has a relatively tight nit community who you can work with. Negatives include it is has yet to have a release (though I believe they were talking about releasing come June).

If you want non-technical people to work on your site then I would highly recomend a template based solution. JSP/ASP/PHP/Other all completely and utterly suck for this job. I am familiar with Velocity and it is a good solution for new users. You can't do any nasty processing in page and is thus *safe*. It also is relatively fast. Other alternatives include FreeMarker and WebMacro.

Assuming you don't plan to use server/db farms I would recomend turbine and some form of templating system.

The other alternative to look at is Cocoon2 from xml.apache.org. It would be useful if you plan to build the site to multiple different clients (ie some HTML, some WAP+WML etc). If thats not a useful feature then stick with turbine - it's simple and works.

The only time I would change my recomendation is if you had to hire a lot of low cost workers to maintain the site. JSP being a standard is more likely to have developers around and they are likely to be cheaper (though a little less intelligent).

Data, dynanmicism, and workers (none / 0) (#41)
by Prince Caspian on Fri Apr 20, 2001 at 10:23:47 AM EST

Which framework you choose really depends on what you want to do. For instance
* how data driven is it (ie do you access N different items per page)
* how much dynamicism do you need
* how many people do you want to work on it etc
As I mentioned, I'm planning something along the lines of h2g2. If anything, though, it will have much more dynamicism, since I'd like each user's view of the nodes to be based on their preferences. For example, if a user tends to like punk rock, and a node about a punk rocker has been added, it may show on the user's front page and the page of music nodes (but not the page of movie nodes).

As far as people working on it, it will start with me doing the code and someone else doing the design (the HTML and graphics). If things grow, though, I'd like to be able to throw others into the mix.

Your comment plus one below makes me think I might have jumped the gun on the rigid "must have clean seperation of design and code" thing. It looks to me if I really wanted that, I would use Cocoon, but that may be overkill for what I need.

[ Parent ]

Cocoon2 (5.00 / 1) (#43)
by Prince Caspian on Fri Apr 20, 2001 at 10:56:19 AM EST

The other alternative to look at is Cocoon2 from xml.apache.org. It would be useful if you plan to build the site to multiple different clients (ie some HTML, some WAP+WML etc). If thats not a useful feature then stick with turbine - it's simple and works.
I took a good look around the Cocoon site yesterday, and was almost sucked in. ;) I'm a real sucker for idealistic designs, but experience is teaching me that the effort I put into creating pure-OO/pure-MVC/pure-anything is often greater than what I would have spent maintaining a less-than-perfect design.

From what I can see, I would have the following practical problems with Cocoon:

  • I would like to use Cocoon2, since Cocoon1 is self-identified as a dead-end (has too many bad designs). But Cocoon2 isn't released yet, and there's no indication when it might be.
  • Although I think XML/XSL are sexy, it is one more technology that developers of my site would have to learn.
  • I fear for the performance of thousands of dynamic hits on a system like this.
  • It looks like I would be writing custom Java code for the Producers/Processers/Formatters. If I ever needed to move to a new framework, something tells me that code would be too Cocoon specific.
  • I wonder if the Cocoon2 model is really suited to the type of structure I want. Let's just say the structure will be much more complicated than K5, with connected nodes and discussions beneath the nodes.
Can anyone confirm/deny any of these concerns?

Like you mention, I can't forsee being interested in the other translations -- it will be a community site. I can't see people using WAP+WML to access it on their cell phone any more than I can see someone doing that for K5. As soon as I say this, though, I get a shiver thinking I may regret this decision two years from now when I want exactly that functionality for some new reason.

[ Parent ]

Re: Cocoon2 (5.00 / 1) (#50)
by donaldp on Fri Apr 20, 2001 at 08:49:49 PM EST

Cocoon2 is supposed to be released on the 1st of May. XML is useful regardless of what format you end up using (I hate XSL though ;]). The content producers would only need to learn XML and forget about XSL though ;)

Re: Performance

Cocoon2 uses a bit more memory than most systems but speed wise performance is not really an issue. It has been pegged at beating many of existing comercial templating solutions. It is still not as fast as Velocity/WebMacros style systems but it is comparable with most other things.

Cocoon2s model is fine for what you want - they have actually implemented aggregation recently which is perfect for such things. (ie building portals).

Something like C2 is the future (Both Sun and Microsoft have started researching equivelent systems) whether you need it now is another question ;)

[ Parent ]
Follow up question (4.00 / 1) (#37)
by tunesmith on Fri Apr 20, 2001 at 03:33:46 AM EST

All right, so what would you all say is a good learning path for these technologies?

I worked for two years writing servlets for a custom application server, using Apache Jserv (no JSP). Now I'm unemployed and realizing how far away I am from J2EE, scrambling to catch up.

My strategy so far - get apache going on my linux box, download tomcat 3.2.1, install mod_jk, also install cocoon 1.8.2. What I've been doing first is learning XML/XSL - should I just be skipping that and looking at the other Jakarta sections instead, or even making sure I understand JSP? (I've been skipping that, assuming I could convince employers I can pick it up in no time since I've already got servlets). Or maybe I should go straight for Jboss and tearing into that? I'm not aiming for any particular job opening, I just want a skill set that has the best combination of broad experience and seniority.

Man, I wish there were roadmaps written up for these sorts of things. I can learn quickly when I have the time, the problem is finding the most efficient path.


Yes, I have a blog.

do a little online research, buy some books (none / 0) (#45)
by kellan on Fri Apr 20, 2001 at 12:21:43 PM EST

Are you wanting to learn J2EE technologies or XSL/XSLT technologies? They aren't the same.

I have a well publicized (at least in this thread) dislike for XSLT, so I'm going to say unless it is specifically what you want to learn, steer away from it.

Absolutely make sure you have a good understanding of the JSP, and servlets, and the "model 2" jsp architecture (MVC). If you're in a rush, or finding it difficult, buy the Manning book book on them.

Then if you're serious about wanting to move into J2EE technologies (as opposed to just building some websites w/ servlets and jsp, which is also cool) get JBoss installed, and talking to Tomcat. From there, Javaworld has some excellent EJB articles, sorry no links, but you'll find them. And work through Sun's tutorials. Once the ideas behind EJB start clicking they really aren't that complicated.


[ Parent ]

Some roadmap (4.00 / 1) (#46)
by emmanuel.charpentier on Fri Apr 20, 2001 at 12:32:32 PM EST

First, forget apache, you don't -need- it to start developping. That's because Tomcat has a (small) web server integrated, which will perfectly fit your needs.

JSP... they are effectively easy to master, once you understand how the web works, why you should strive to reduce the amount of scripting code in your pages, how pages are related one to others (model 1, model 2). Taglibs are not required, but a nice way to reuse the nonetheless necessary code.
Servlets are not necessary either, except as a central point where to handle forms, data fetching and redirections. You generally use javabeans for processing.

EJB are the next step for your resume, they are not complex in themselves, considering they are only libraries. But the philosophy behind them is a must have in order to reach any capability. Be aware that you don't get full relational/object mapping, and the code is overloaded with exceptions :-(
JBoss and Jonas (in enhydra) are good free ejb servers.

Before or after that you can get some XML knowledge. You are required to go at least once on W3C, if only to consider how arid their specs can be. Then go to ZVon :-) It's full of turorials, examples and references. The "must go" to pick basic skills.
Try not to read everything in one go, because it's simply too much. Just learning the abbreviations is too much for one day >:-) Try to get one night sleep between each spec :-) But you don't need to read them all, just start with XML, and sometimes later get XSL/XSLT. You will pick up XPath along the way, XLink (and XPointer) when you want to create "standard" links, RDF when you want to reference your web site. DTD or schemas will come when you'll try to communicate with others about the structure of your XML documents.

There are different ways to have XML/XSL on your web site:
- JSPs and the XSL taglib ;
- Cocoon and its XSP particularity ;
- Enhydra and its XMLC.

[ Parent ]
Oooops (none / 0) (#47)
by emmanuel.charpentier on Fri Apr 20, 2001 at 01:13:37 PM EST

its W3C and ZVon...
I... need... to go... home...

[ Parent ]
Eat me (none / 0) (#49)
by emmanuel.charpentier on Fri Apr 20, 2001 at 01:20:00 PM EST

A worm hole opens up, and the devil reaches out and picks the parent message which obviously escaped from hell (evil twin).
Hit me!

[ Parent ]
Oooops (none / 0) (#48)
by emmanuel.charpentier on Fri Apr 20, 2001 at 01:14:22 PM EST

its W3C and ZVon...
I... need... to go... home...

[ Parent ]
SQL/EJB/Servlet/JSP/XML/XSL (none / 0) (#39)
by emmanuel.charpentier on Fri Apr 20, 2001 at 06:25:39 AM EST

That's the different techs (abbreviations really) that are used in the VeniVidiVoti Library.

I've been working on jsp/servlets/JDBC for two years now, and I absolutely wanted to go the EJB and XML road. The VVV library project is quite happy with it, and offers a superb programmation model (from my biased POV of course:).

Data is handled by the SQL database (PostgreSQL, but it could be another one).
Business logic, database access and some security is managed by JBoss. I can't emphasize enough the ease of installation and use JBoss bundled with tomcat offer. It's a wonderfull experience... once you understand the EJB philosophy...
Servlets to conduct the logic for data retrieval and data storage (EJB calls are made here).
JSP to manage the presentation. They are very easy and pratical to use, but require some discipline in order to minimise the amount of code in it. JSPs can be used to generate XML!!!
Then, using the XSL taglib from the jakarta project, you can use a XSL file to transform that XML in HTML, or wap, or rtf... etc.

Using those technologies will give you an insurance for the future, because they are simple and standard! In opposition to Cocoon or Enhydra which relie on processes particular to themselves...

JBoss will even give you SOAP in the future, and might extraordinarily decrease your amount of database work, if you rely on its automatic table creation feature :-)
When you use JBoss and Tomcat integrated in the same Virtual Machine, you obtain a very tight coupling reducing interprocess calls, and resulting in a very fast and almost J2EE environment.

Too bad JBoss is not (yet) packaged for debian :-(

CU (and sorry for any orthograph or grammatical or style faults)

apt-get install jboss? ugh (none / 0) (#42)
by kellan on Fri Apr 20, 2001 at 10:24:52 AM EST

Too bad JBoss is not (yet) packaged for debian :-(
I would be scared to apt-get install something like jboss. I know people do it all the time, but for this sort of thing (and apache, tomcat, and mysql) I really prefer to do a hand install. Just feels so out of control to trust someone elses setup for something that is going to be at the heart of my app.

What do you think? Am i being unreasonable?


[ Parent ]

Yes you are (none / 0) (#44)
by emmanuel.charpentier on Fri Apr 20, 2001 at 11:37:46 AM EST

Well, for most uses, apt-get install "everything" is fine. After all, that's it exists.
Your competence should shine in the configuration domain, where every single variable has to be tweaked for maximum efficiency.

The previous statement should of course be taken with a grain of salt whenever compilation tweaking becomes important :-( I don't know what to think about that, is it good? is it bad? Should everything be set as a module or inline??? It most probably depends on the problem at hand (as usual).

Anyway, you can already do apt-get install tomcat/cocoon/jikes, and I'm seriously thinking about packaging JBoss. Its installation is simple, the VeniVidiVoti installation script (a silly shell script really) actually attempts it (it downloads JBoss/Tomcat with wget, install it in the directory you wish, modify one or two config files, create a vvv.ear file and place it in the "jboss/deploy" directory for deployment).

And if JBoss was part of debian, I could also package VVV as a debian package, and maybe try to sneak it into sid... that way some people might actually install it onto some server, and create a library for their own community (dream on).

Reasonable people are not those changing the world anyway ;-)

[ Parent ]
Picking a server-side Java framework | 50 comments (40 topical, 10 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!