Glassfish Vs Tomcat (Java app servers)

tomcat java glassfish application-server

226

Solution 1

Glassfish is an application server as it handles EJB requests (EJB Container) while Tomcat is a Web Container - it can't handle EJB components. So, what are the components of the application you plan to run. If your application uses Servlets and JSPs, then GlassFish is an overkill. If you have EJBs then you can't use Tomcat anyway. So, I think it starts with your requirements first.

Solution 2

Don't forget to consider Jetty. I like very much:

its ease of configuration and deployment (just unzip it and optionally edit one config file)
the fact that it's easily embeddable in other applications (with a single jar)
its support for continuations a lot before the Servlet 3 spec is ready

Check this comparison out, it's done by a Jetty dev, but it's very fair.

Some other comparisons:

226

Craig Francis

Updated on September 17, 2022

Comments

Craig Francis over 1 year
I have a base object (form_field_base) that is extended/inherited by other objects in the form of:
```
class form_field_base {
    // Lots of code
}
class form_field_text extends form_field_base {
    // Lots of code
}
class form_field_email extends form_field_text {
    // Extending the text object to update validation, and set input type="email"
}
class form_field_file extends form_field_base {
    // Lots of code, for example uploading files
}
```
The "form_field_base" provides helper methods that all of the form field types use, for example a html() function calls the specific object (form_field_email::html_input) to get the field, then put that in a string with the standard tag, etc.

All of these objects are used by many projects.

However, this latest project I'm working on requires the "form_field_base" object to be customised to allow the setting of some help text, a feature that no other project requires, and if future projects do, it will probably be done differently.

So how should this have be organised?

Ideally I won't have a complete copy of "form_field_base", as that would cause code duplication.

And it does seem like quite a bit of overhead to have dummy intermediate objects:
```
class form_field_base_common {
    // Lots of code
}
class form_field_base extends form_field_base_common {
    // By default is empty
}

class form_field_text_common extends form_field_base {
    // Lots of code
}
class form_field_text extends form_field_text_common {
    // ...
}

class form_field_email_common extends form_field_text {
    // Extending the text object to update validation, and set input type="email"
}
class form_field_email extends form_field_email_common {
    // ...
}

class form_field_file_common extends form_field_base {
    // Lots of code, for example uploading files
}
class form_field_file extends form_field_file_common {
    // ...
}
```
Taking that each one has it's own file, which is auto-loaded (either a from a project specific location, if it exists, or from a common folder that all projects can access)... that is already 8 files that need to be found, opened, parsed, etc, just for supporting a form.

Surly there has to be a better way?
- J0HN over 12 years
  
  have you tried private methods and data? Or what do you mean? Do you need to hide new features from descendants, ir form other projects that use the same codebase?
- Craig Francis over 12 years
  
  It's more that the "form_field_base" is already pretty large, and adding more functionality/code to it just for one little project (when it's being used by many projects) does seem to be a waste.
Pascal Thivent almost 14 years

What is an "heavy weight" application server?
Craig Francis over 12 years

Thanks for your suggestion, I must admit I was hoping not to edit the existing code in this way, as while your way would allow custom help text that could be handled in (some?) different ways, I'm sure there will be other random (one off) features appearing in the future which will also need this kind of editing.
Craig Francis over 12 years

Hi Igor, this does sound very interesting... I'm just going to look at the documentation, but do you have more of an example on how this would work... if your saying that I could drop the "extends form_field_base" from the text/email/file/etc classes, so that they can somehow inherit from either that class, or another (custom) one which in turn inherits from form_field_base, then that would be great.
Igor Zinov'yev over 12 years

I have updated the answer, see the code snippet. See how you use your regular form object and pass it into the constructor of the new object.
Craig Francis over 12 years

Just wanted to say thank you for the example, in the end I didn't use this method because adding an extra wrapper to every field (the project contains a few hundred fields), but it's a good solution which may help in other projects.
Craig Francis over 12 years

Thanks Jens, while I've probably done things slightly differently, this is basically how I solved it... although I do find that the more I use object orientated programming, the more complicated solutions you seem to need to use (maybe that's just me though).