please help me get started with building a website

[mr_wu]

Dear Group,

Can you kindly give me suggestions on using Java as the main component
in website building? I'm especially interested in using it in backend
as well as front end and incorporate hopefully AJAX. Webserver I'm
familiar is apache, sql server will be postgres.

My background: I've already built a long running successful site with
mod_perl/apache/dbi as backend/front end with very little javascripts.

I wish to build on my java skills. I have already built a few
original desktop apps using j2se and in terms of lines of code my
experience with java is higher than perl. But I have known perl much
longer and I can build a website very fast in perl.

I am looking for something equivalent to mod_perl with perhaps a
templating feature built-in. I've looked into Tomcat but after
reading their intro + a bit more i'm not clear whether they have what
i want or even how it fits into apache if at all. Is glassfish an
alternative to Tomcat? What about jboss?

I've also written a tiny java applet on my mod_perl site and I notice
that the applet takes its time to load the first time. It's because
the browser has to load JVM the first time? I'm afraid that this type
of problem will be present if I were to use java for interactivity
i.e. AJAX. True or false? If I use JAVA just for server side (JSP?),
I won't see the problem? Will it be more interactive than pure
mod_perl site? Just easier to develop? More scalable?

Sorry for the long post

Thanks in advance for any suggestions. Any reading material online or
print? Server will be on linux. Development on Windows/Linux/Mac
better?

 

[markspace]

I am looking for something equivalent to mod_perl with perhaps a
templating feature built-in. I've looked into Tomcat but after

JSPs are templates for Java EE. You want primarily Parts I and II of
this document:

<http://java.sun.com/javaee/5/docs/tutorial/doc/>

Look at the end part too for the sample applications. There are also
lots of good books on JEE (used to be called J2EE). Check out some
reviews on Amazon.

reading their intro + a bit more i'm not clear whether they have what
i want or even how it fits into apache if at all. Is glassfish an
alternative to Tomcat? What about jboss?

Yes, Glassfish, JBoss and Weblogic all do basically the same thing as
Tomcat. Tomcat is very popular, free, and used by lots of ISP and
companies. Note that Tomcat primarily does just JSP and Servlets, which
is the real core of the JEE spec. The rest of the spec (EJP, etc.) is
not implemented by Tomcat. There are tons of books on Tomcat out there.

To "fit Tomcat into Apache," use mod_jk:

I've also written a tiny java applet on my mod_perl site and I notice
that the applet takes its time to load the first time. It's because
the browser has to load JVM the first time? I'm afraid that this type
of problem will be present if I were to use java for interactivity
i.e. AJAX. True or false?

True. Most Java websites use HTML and JavaScript for the front end, not
Java applets. You might want to look into Java Server Faces.

If I use JAVA just for server side (JSP?),
I won't see the problem? Will it be more interactive than pure
mod_perl site? Just easier to develop? More scalable?

Generally easier to develop with Java, I think, and more maintainable
and scalable. Perl turns in to a big ball of ... something pretty
quickly. Java tends to be more organized.

Sorry for the long post

Thanks in advance for any suggestions. Any reading material online or
print? Server will be on linux. Development on Windows/Linux/Mac
better?

I think Windows/Ubuntu pretty much the same. Check out the JEE features
of a good IDE. For example:

<http://netbeans.org/kb/trails/java-ee.html>

 

[Tom Anderson]

The rest of the spec (EJP, etc.) is not implemented by Tomcat.

I knew Esmond was a vital resource for java development, but i didn't
realise he was mandated by the spec!

tom

 

[markspace]

I knew Esmond was a vital resource for java development, but i didn't
realise he was mandated by the spec!

Yeah that was supposed to be "EJB," just so the OP isn't totally
confused by my typo.

 

[mr_wu]

Thanks for very informative reply. JEE does have rather steep
learning curve. But I believe it will pay off in the end.

 

[Arne Vajhøj]

Can you kindly give me suggestions on using Java as the main component
in website building? I'm especially interested in using it in backend
as well as front end and incorporate hopefully AJAX.

Do you want to use Java both in frontend of the server side and backend
of the server side or both at client and server?

The first rules out AJAX unless you plan on using GWT.

The second is very standard Java EE.

Webserver I'm
familiar is apache, sql server will be postgres.

My background: I've already built a long running successful site with
mod_perl/apache/dbi as backend/front end with very little javascripts.

I wish to build on my java skills. I have already built a few
original desktop apps using j2se and in terms of lines of code my
experience with java is higher than perl. But I have known perl much
longer and I can build a website very fast in perl.

I am looking for something equivalent to mod_perl with perhaps a
templating feature built-in. I've looked into Tomcat but after
reading their intro + a bit more i'm not clear whether they have what
i want or even how it fits into apache if at all. Is glassfish an
alternative to Tomcat? What about jboss?

Tomcat, Glassfish and JBoss are all servers. Tomcat only implements the
web part of Java EE while Glassfish and JBoss implements everything (and
actually Glassfish and JBoss usually comes with Tomcat embedded for the
web part).

All of them give you the option of:
- speaking HTTP directly with them
- speak HTTP with Apache HTTPD and have that speak AJP with them

I've also written a tiny java applet on my mod_perl site and I notice
that the applet takes its time to load the first time. It's because
the browser has to load JVM the first time? I'm afraid that this type
of problem will be present if I were to use java for interactivity
i.e. AJAX. True or false? If I use JAVA just for server side (JSP?),
I won't see the problem? Will it be more interactive than pure
mod_perl site? Just easier to develop? More scalable?

Java applets do come with a small load time. But on a new system
it should not be that bad.

Server side Java obviously does not have this problem.

Server side Java is good for:
- large sites with lots of code
- sites with stateful clustering
- sites with transaction requirements
- sites that needs to integrate with web services, message queues and
ERP systems

Thanks in advance for any suggestions. Any reading material online or
print? Server will be on linux. Development on Windows/Linux/Mac
better?

It should not matter that you develop on another platform than
the one you deploy at.

Arne

 

[Tom Anderson]

Do you want to use Java both in frontend of the server side and backend
of the server side or both at client and server?

The first rules out AJAX unless you plan on using GWT.

Or LiveConnect. No school like the old school!

https://jdk6.dev.java.net/plugin2/liveconnect/

It should not matter that you develop on another platform than the one
you deploy at.

As far as everything inside the WAR/EAR is concerned, this is true.
Although if there's a lot of money depending on your app, i'd certainly
suggest doing QA on the same platform.

However, things outside the WAR/EAR may not be so portable. In my apps
i've worked on, there is a colossal amount of what we generically term
'build scripts', which is the stuff that takes a fresh checkout from CVS
on a blank machine and turns it into a running system: that's everything
from compilation, management and implementation of configuration options,
EAR/WAR assembly, configuration file preparation, database schema
definition, data load, app server startup and monitoring (and shutdown),
and post-startup configuration and activation steps. And running unit
tests.

It's possible to do much or all of that portably - ant was made to do this
(more or less), and what you can't do in ant, you can do in java (perhaps
by writing an ant task). The only places where you're in real trouble are
when you're interacting with different interfaces (eg the start scripts
for Tomcat and JBoss, which take different parameters), but that's just a
matter of isolating that and writing implementations for each interface.

Still, in practice what we end up doing is writing trillions of lines of
bash script. The trouble is that ant is an utterly, utterly appalling
language, far more verbose and fiddly than shell script, and agonising if
you want to anything even a bit unusual. So we write shell script. And hey
presto, while we can run on any linux machine with only minor tweaking (eg
the xmlstarlet command-line XML processor is invoked as xmlstar on Debian,
but xml on CentOS), and on OS X with a bit more tweaking (install lots of
GNU utilities from MacPorts, change readlink to greadlink throughout,
etc), you're hosed if you want to run on Windows. Luckily, our development
landscape is almost always linux from development to production, with the
very occasional sidestep onto OS X for laptops, so the pain is minimal.

Conversely, if you developed on Windows, but deployed on unix, if you
wrote your build system in batch script, you'd be stuffed. Luckily, batch
script is so awful that you wouldn't do this; you'd even use ant in
preference, so you'd have a better shot at being portable from the start.

tom

 

[Lew]

Still, in practice what we end up doing is writing trillions of lines of
bash script. The trouble is that ant is an utterly, utterly appalling
language, far more verbose and fiddly than shell script, and agonising if
you want to anything even a bit unusual. So we write shell script. And hey
presto, while we can run on any linux machine with only minor tweaking (eg
the xmlstarlet command-line XML processor is invoked as xmlstar on Debian,
but xml on CentOS), and on OS X with a bit more tweaking (install lots of
GNU utilities from MacPorts, change readlink to greadlink throughout,
etc), you're hosed if you want to run on Windows.

Not so much so if you use bash.

Luckily, our development landscape is almost always linux from development to production,
with the very occasional sidestep onto OS X for laptops, so the pain is minimal.

Conversely, if you developed on Windows, but deployed on unix, if you
wrote your build system in batch script, you'd be stuffed. Luckily, batch
script is so awful that you wouldn't do this; you'd even use ant in
preference, so you'd have a better shot at being portable from the start.

Fortunately you can use bash on Windows if you install Cygwin, which
restores your portability.

 

[Tom Anderson]

Not so much so if you use bash.


Fortunately you can use bash on Windows if you install Cygwin, which
restores your portability.

It's not just bash. It's bash and all the other unix utilities the scripts
use, and the existence of /tmp, the ability to ssh to another machine and
run commands on it, etc. It would be interesting to see if it could be
ported, but i'd very much prefer that someone other than me tried it!

tom

 

[Lew]

It's not just bash. It's bash and all the other unix utilities the
scripts use, and the existence of /tmp, the ability to ssh to another
machine and run commands on it, etc. It would be interesting to see if
it could be ported, but i'd [sic] very much prefer that someone other than me
tried it!

All of that is in the Cygwin suite. I've been doing it for a decade,
including port-forwarding X-Windows over SSH, database connections, using
"scp", whatever.

 

[Arne Vajhøj]

Or LiveConnect. No school like the old school!

https://jdk6.dev.java.net/plugin2/liveconnect/

That has nothing to do with AJAX.

As far as everything inside the WAR/EAR is concerned, this is true.
Although if there's a lot of money depending on your app, i'd certainly
suggest doing QA on the same platform.

However, things outside the WAR/EAR may not be so portable. In my apps
i've worked on, there is a colossal amount of what we generically term
'build scripts', which is the stuff that takes a fresh checkout from CVS
on a blank machine and turns it into a running system: that's everything
from compilation, management and implementation of configuration
options, EAR/WAR assembly, configuration file preparation, database
schema definition, data load, app server startup and monitoring (and
shutdown), and post-startup configuration and activation steps. And
running unit tests.

It's possible to do much or all of that portably - ant was made to do
this (more or less), and what you can't do in ant, you can do in java
(perhaps by writing an ant task). The only places where you're in real
trouble are when you're interacting with different interfaces (eg the
start scripts for Tomcat and JBoss, which take different parameters),
but that's just a matter of isolating that and writing implementations
for each interface.

Still, in practice what we end up doing is writing trillions of lines of
bash script. The trouble is that ant is an utterly, utterly appalling
language, far more verbose and fiddly than shell script, and agonising
if you want to anything even a bit unusual. So we write shell script.
And hey presto, while we can run on any linux machine with only minor
tweaking (eg the xmlstarlet command-line XML processor is invoked as
xmlstar on Debian, but xml on CentOS), and on OS X with a bit more
tweaking (install lots of GNU utilities from MacPorts, change readlink
to greadlink throughout, etc), you're hosed if you want to run on
Windows. Luckily, our development landscape is almost always linux from
development to production, with the very occasional sidestep onto OS X
for laptops, so the pain is minimal.

Conversely, if you developed on Windows, but deployed on unix, if you
wrote your build system in batch script, you'd be stuffed. Luckily,
batch script is so awful that you wouldn't do this; you'd even use ant
in preference, so you'd have a better shot at being portable from the
start.

The burden of a very complex environment is common.

But if it is managed properly it should not become a big problem.

KISS is good for the software itself. But it is even better for
the "home made tools" to support the software.

Arne

 

[Thufir]

It's possible to do much or all of that portably - ant was made to do
this (more or less), and what you can't do in ant, you can do in java
(perhaps by writing an ant task).

There are other build scripts besides ant, most notably maven. In java,
there's groovy. I've used ruby & rake, and there are a variety of java
build projects based upon ruby and rake which simplify things.

Would any of those solve that problem, I wonder?

-Thufir

 

[Tom Anderson]

That has nothing to do with AJAX.

It connects java applets and javascript, in both directions. AJAX uses
javascript. It could be used to build a front end which used applets and
AJAX. So it has something to do with AJAX, and it's relevant to the OP's
question.

However, things outside the WAR/EAR may not be so portable. In my apps
i've worked on, there is a colossal amount of what we generically term
'build scripts', which is [...]

The burden of a very complex environment is common.

But if it is managed properly it should not become a big problem.

I wouldn't say it's a problem. But managing it properly is itself a
significant amount of work. That's just the nature of the beast - the
complexity has to go somewhere, it can't just go away.

tom

 

[Tom Anderson]

There are other build scripts besides ant, most notably maven.

Maven's not an alternative to ant, AIUI, it's more of a wrapper - it does
a lot of standardised donkey work (fetching dependencies, compiling,
building JARs, running tests etc) for you, as long as you submit to its
rules for laying out packages, but if you want to do something that isn't
standardised donkey work (and i'm not certain how far that goes, but i
think things like loading databases, starting app servers etc are not
covered), you're back to writing your own ant job.

In java, there's groovy. I've used ruby & rake, and there are a variety
of java build projects based upon ruby and rake which simplify things.

Would any of those solve that problem, I wonder?

Yes, if you're willing to use one of those. I would absolutely love to
move our build process over to groovy (and gant, which is a groovy API to
ant's tasks, which are themselves often pretty useful), but that would
involve adding a new language to the project - a language which nobody in
our office knows, and which our clients don't know (so far, at least). At
least with the bash-ant-java hybrid we have at the moment, when we hand a
system over to a client they have a hope in hell of understanding it based
on their existing knowledge.

Yes, groovy is easy to learn. But that doesn't really matter, because when
a project manager or a less-inquisitive developer sees the bullet point
that says 'build system written in groovy', they go ballistic.

That's the argument that's stopped us moving to groovy so far, anyway.
There is a faction here which does not believe it, and continues to
agitate for groovy, but so far he hasn't won out.

tom

 

[Tom Anderson]

It's not just bash. It's bash and all the other unix utilities the scripts
use, and the existence of /tmp, the ability to ssh to another machine and
run commands on it, etc. It would be interesting to see if it could be
ported, but i'd [sic] very much prefer that someone other than me tried it!

All of that is in the Cygwin suite. I've been doing it for a decade,
including port-forwarding X-Windows over SSH, database connections,
using "scp", whatever.

Your brain may know all that, but my gut tells me otherwise.

Okay, sounds like i should give cygwin a shot. Or rather, get one of the
contractors who has a windows laptop to give cygwin a shot.

tom

 

[mr_wu]

Thanks for all replies which are very informative.

Ideally I would like to develop on git + Ubuntu and push to a redhat
server.
But I'm currently using Netbeans on Mac to learn jee since
virtualization
on this Mac isn't acceptably fast.

My other question is what packages must be installed on linux live
server
if I am not doing most development on there? In principle I don't
need to install
jdk right? I make jar or war or ear on development box and then push
these to live server where JRE there would take care of serving pages
and app?

Learning with IDE makes these issues not very obvious. Is there any
learning trail out there
which involves only shell and on linux?

 

[Roedy Green]

My other question is what packages must be installed on linux live
server
if I am not doing most development on there? In principle I don't
need to instal

You want to run your IDE/editor on a local desktop. You might consider
setting up a LAN with some old machines to do things like testing.
You will want your JDK on whatever machine you do your editing.