do's and dont's with servlets

[Greger]

alright,
about to start a project with java servlets. I would appreciate if someone
would highlight do's and don'ts regarding web based apps in java. My plan
is to create a web based database based application with java j2ee, further
I plan to use XML for output ( formatting with XSLT ).

I guess there are some best practices regarding this, if some of you have
experience then post and share your thoughts. Thank's.
Greger

 

[Mladen Adamovic]

about to start a project with java servlets. I would appreciate if someone
would highlight do's and don'ts regarding web based apps in java.

My tip is simple :
always split presentation and business layers.
Don't mix a large amount of HTML with large amount of handling data in
single class.

 

[Ed]

Greger skrev:

alright,
about to start a project with java servlets. I would appreciate if someone
would highlight do's and don'ts regarding web based apps in java. My plan
is to create a web based database based application with java j2ee, further
I plan to use XML for output ( formatting with XSLT ).

As with all OO, "Encapsulate the concept that varies."

Encapsulate as much code as possible from knowing that it's running as
a servlet; you never know when you might switch running-environments.

Encapsulate your data layer; don't allow most of your code to know
anything about the database.

Encapsulate your output formats: XML is flavour-of-the-month but
nothing lasts.

Secon Mladen's recomendation and further propose looking into MVC;
browse here:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs100.html

Think concurrency and serialisation from the beginning, they're a pain
to retro-tweak.

Finally, if you're going J2EE, then you'll need to read a lot more than
just servlets: start small and build for extension.

..ed

 

[Chris Brat]

Quick one - dont make use of static variables in servlets.

Remember that servlets are single a instance with multiple threads and
your app will work wonderfully during development but you'll get very
interesting and incorrect results during testing.

 

[Mladen Adamovic]

Quick one - dont make use of static variables in servlets.

Remember that servlets are single a instance with multiple threads and
your app will work wonderfully during development but you'll get very
interesting and incorrect results during testing.

Hm, I'm using static object in Servlets.
I have some objects which are REALLY memory consuming, so I thought
it would be good idea to instantiate them only once. In some cases
making of those objects needs time. And I'm using methods on them which
are not changing their stance (just querying...).

One of those object is dictionary which I use in static way.
dic.getHTML(String lemma) which returns String.

I think it is a good idea.

 

[Juha Laiho]

alright,
about to start a project with java servlets. I would appreciate if someone
would highlight do's and don'ts regarding web based apps in java. My plan
is to create a web based database based application with java j2ee, further
I plan to use XML for output ( formatting with XSLT ).

I guess there are some best practices regarding this, if some of you have
experience then post and share your thoughts. Thank's.

Some comments on transferability;
- don't hardcode the deployment directory path into your application
- better yet, don't assume that your application is deployed as
a directory hierarchy -- use the documented interfaces for referring
to resources within your web application
- avoid hardcoding any external directory paths (or URLs, for that matter)
into your application
- pass information on external dependencies as some kind of configuration
variable (system property could be a good way to point to
a configuration file, which then contains data for all external
dependencies)
- use JNDI and container-provided pooling for obtaining database connections
- don't hardcode the application deployment name (context path) into
the application; retrieve it dynamically when/if needed; oftentimes,
the application code shouldn't need it - there are interfaces for
creating proper self-referential URLs

.... at first, the above may feel like unnecessary burden ("this application
will never be relocated"). My experience is that all kinds of reorganisations
happen (directory structures on servers get reorganised, server names or
IP addresses change, external URLs change, database servers change, ...).
If the application has all kinds of external (or even self-referential)
references hardcoded, each transfer will be plainful. On the other hand,
if the application has always been written as transportable, all these
changes are a breeze.

Transportability also eases developing the application with varying
environments (f.ex. separate development, testnig and production
environments). A transportable application doesn't need any change
when taken from one environment to another (thus, there's no risk
of missing a required per-environment change breaking things).