
Abandon fish! Leaving GlassFish for TomEE or JBoss - theotown
http://zeroturnaround.com/rebellabs/abandon-fish-migrating-from-glassfish-to-jboss-or-tomee/
======
twic
I am a little surprised to see an article like this on HN. I wouldn't have
thought the kind of person who reads HN uses anything as fusty as a Java EE
application server.

Am i mistaken? How many of us are using Java EE? Is it just those of us who
are toiling away in the code mines of megacorps? Or are some of us using Java
EE in cool and exciting startups?

~~~
Nanzikambe
I used it extensively, I wrote a suite of web based tools for an MMO with GF
3.12, at the time I started writing I had good familiarity with Java, but
none-with J2EE technologies, REST, JSON etc. Whilst I implemented what I set
out to do, when the time came to implement a significant ammount of new
features, one thing that amazed me was the labyrinth of code that I'd had to
create (beans, resources, factories, abstract base classes) - and how quickly
it was becoming a major chore to change the trivialest of things. Also I made
the unfortunate mistake of using JavaDB/Derby as the datastore, thinking I had
no need for a full RDBMS, I'll never make that mistake again, it's the most
pathetic excuse for a db ever (I've used Oracle, MSSQL, Sybase, MySQL and
Sqlite in the past, so I have some perspective on the matter)

So I began looking for alternatives, as a result v2 is written in Python
(Flask/REST producing JSON, a simple wrapper around TornDB querying a MySQL
db) which is consumed and presented by the Javascript/HTML front end using
AngularJS. I re-implemented everything V1 had from scratch in under three days
and was ready to begin adding the new features. By comparison the initial
implementation in Java had taken me several weeks. Obviously some of that is
to be expected, its easier to re-write than write. But I come away now feeling
that Java & Glassfish made me jump through hoops to accomplish something that
should have been simple, and I was certainly guilty of chosing the wrong tool
for the job, but Java was what I knew best at the time.

~~~
matt_heimer
> how quickly it was becoming a major chore to change the trivialest of things

This was more than likely just bad design on your part. GlassFish 3.12 support
Java EE 6 which supports a lot of POJO based development - between your
mention of abstract base classes, factories, and J2EE (which became Java EE
over 8 years ago) I have to wonder if you used a lot of legacy APIs and design
patterns.

> Also I made the unfortunate mistake of using JavaDB/Derby as the datastore

Derby is neat for an portable in-process relation db but no one in their right
mind uses it for a large or high-performance db. But most db changes should be
isolated to your persistence layer using Hibernate/JPA so changing database
vendors shouldn't have caused a big change in your code unless you had to
redesign your tables for some other reason.

~~~
Nanzikambe
> This was more than likely just bad design on your part.

Oh I won't deny that, as I mentioned, I approached the problem from a
background with limited exposure to modern web technologies. Still though,
lets take just one aspect, db interaction for which I used hibernate:

First I create my DB structure, then create an XML mapping, then create the
POJO model (replete with getters/setters) sure, most IDEs do this
automagically, but experience with switching IDEs and changing versions makes
me abhore IDE generated code, then hibernate's own XML config, then the
utility class (I called these factories, my bad). Not to mention the
prerequisites that made all this possible, glassfish, maven etc require their
own configuration etc. By now I have several thousand lines of code and I've
not even implemented any functionality. Time taken, no clue, but hours, lots
of hours.

The equivalent with Python + TornDb?

Create schema, extend torndb to pull credentials from environment variables &
connect to db (3 lines of code, wow), create flaskapp.py, bind path to a
method, begin writing the "real" code. Lines of source, under 100. Time taken,
less than an hour.

> J2EE (which became Java EE over 8 years ago) I have to wonder if you used a
> lot of legacy APIs and design patterns.

When you spend a considerable amount of time calling something by one name,
despite a rename you tend to continue. Apologies for using the incorrect name,
but the rest of your assumption are unfounded unless you're calling Glassfish,
Hibernate, Jersey, JSF and JavaDb legacy ..

> Derby is neat for an portable in-process relation db but no one in their
> right mind uses it for a large or high-performance db

Those were precisely the reasons I chose it, the example I gave isn't large or
high performance, and its pathetic at that role, I stand by my assertion.
You'd be better off using serialised objects, CSV files, heck even notes
scribbed on postit notes tacked to the wall than JavaDB.

I say this after countless hours spent taking the platform offline to rebuild
the database which grew uncontrollably despite careful use of transactions
within hibernate and daily cron jobs to run SYSCS_UTIL.SYSCS_COMPRESS_TABLE

~~~
twic
For the schema stuff, these days what i would do is write the objects, add the
minimal set of JPA annotations (which can be as little as @Entity at the top
and @Id on the ID column), then generate the DDL from that. You don't need any
XML for the mapping.

Sadly, you do still need a persistence.xml with the database connection
details, and for some providers a list of all your entity classes (WTF). I
have a build script which generates all that (amongst other things), though:

[https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...](https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097f86e29866b6ccd90e9663f2fd/build.gradle?at=default)

~~~
Nanzikambe
Interesting!

I did end up using annotations as you mention. However I chose to manage the
db structure myself because early on I encountered problems when I changed
data types and indexes, hibernate incombination with JavaDB dropped then
recreated the structure, which is fine, but then if you want to push your
changes to the live version, I had to write the SQL to port the live data into
the newly created table which was a PITA given javadb can't insert into
"GENERATED ALWAYS AS IDENTITY" columns, so that in turn meant more SQL to
preserve referential relationship between data. I was always left feeling I
did something totally wrong in that respect, so I blame myself.

A part of this also stems from the way I approach building an application,
I'll always spec & then create out the DB as a way of helping me visualise the
model before I start doing any "real" coding.

I still respect Java enormously, but I'm not at all sold on JEE application
servers for anything below enterprise scale applications. And for any case
where you need a quick prototype, Java definitely will not be my choice in the
future.

------
gjvc
see also Resin, which has a GPL version
[http://www.caucho.com/](http://www.caucho.com/)

