A common requirement for enterprise applications is to be able to deploy into read-only partitions. This is so that no user can change any aspect of the deployed application without following a strict change procedure.
However - glassfish requires so many directories to be read/write that it becomes extremely difficult to deploy in this manner.
What is needed is a clear separation of "fixed" directories - that will never change once an application has been deployed - and "working" directories that contain dynamic data (session information / unpacked ear files / whatever )
Currently glassfish has a complete mis mash.
hence its crap.
Subscribe to:
Post Comments (Atom)
2 comments:
Does any file based version of an application server work for you in this configuration? Glassfish is an open community project, you could always join and help change what you think is wrong. That is the great thing about open source.
Sun does offer a packaged based version in its SJSAS product offerings that is segmented into code and working directories. Maybe you should try that version. During development, most prefer all the code to be under one directory for ease of maintenance.
Many website requirements can be met by running their production servers in a hardened environment. A read-only file system is usually too restrictive in this web2.0 world and maintenance becomes cumbersome.
1) I would join in - but
a) as the build is dont with "maven" (long since consigned to the bin - even the inventors of jelly apologise for their cruel joke on the java community) i would rather gouge my eyes out.
b) the codebase looks like it was the intestinal result of a really strong curry and 10 pints of special brew.
b - more detail) - different versions of the same jars across the codebase; duplicate classes (with the same name and package) with different contents in different modules; no discernable configuration files checked in for a decent editor (that means Eclipse or Idea); terrible layout of modules; almost complete lack of tags demonstrating no understanding of release procedures.
2) During development I try to make sure that what I am testing bears some resemblance to the production deployment environment...
3) "A read-only filesystem [...] too restrictive" - please explain what you mean by this. What we are trying to do here is separate out dynamic stuff from deployed stuff. What world are you on?
Post a Comment