Hi people,
As posted thru this series, Context Specifiers (which should be conceptually
trivial) seem to have become a problem area. To some extent Deployment also
seems to be touched by this.
I identify the problem as Design and lack of conceptual clarity, rather than
code.
We can see a lack of clarity of Ownership in two important areas of data,
introduced with 5.5 Neither the /conf/[engine]/[host] nor the /webapps
directory is clearly owned by either the (IT) User or Tomcat.
Consequently it is fundamentally unclear whether Configuration Changes should
require tomcat to apply secondary effects/ modify these data automatically, or
whether the IT User has already done so/ or does not require or intend any such
modification or changes to be made.
We're also seeing noted undesirable automatic effects such as Tomcat stupidly
scrubbing web.xml from a deployed webapp, breaking it completely, after minor
tidy-up edits on a user-created Context descriptor.
Having worked with data replication, persistence etc architectures for decade
plus I can say this is just not deterministic enough, and that I don't like
any lack of clarity over who owns data and which direction flow-on effects
apply.
I do not believe it is possible to implement a sound/ reliable system without a
greater degree of clarity in terms of Ownership, Responsibility and Effects.
Nor do I believe the lack of these has any benefits whatsoever.
I understand that some changes may be being driven to improve support for farm
deployment, or to fix broken behaviours from 5.0. But I do not believe this
design or these mixed-ownership concepts are fundamentally sound, or logically
can be.
I am also quite suprised how a trivial Context Specifier object, can now be
specified in 3 or 4 ways and places, yet is moderately non-functional in most
of these; with Context Path specification being almost completely broken.
At this point I will point out that I'm not the first person to run into most
of these context problems. In the majority they're pretty much all reported
bugs, which one person has blown off as:
- RESOLVED WON'TFIX
without them being resolved in the slightest.
Also we get comments such as:
> If you don't like it, you'll have to use a different container.
And regarding my desire to specify Context Paths -- hello, these are a basic
spec, not missile guidance technology.
> Ok, so you have specific needs. This is great, but at this point, there does
> not
> seem to be anyone willing to redo the deployer just so that we can support
> your
> use case.
My use case is being able to specify a Context Path, and having that work ?
Perhaps my bug report came across as a rant, because it had covered several
attempts all of which featured Contexts being non-functional or deployment
auto-deleting what it shouldn't have,
because I'd already read the docs, searched the web, read the NGs, read the bug
reports, and seen these issues already being raised, with users being waved
away/ blatantly disregarded...
-----------
I'd be interested to know what other Tomcat-Dev members think. Bear in mind
that I'm not a deep TC developer but have been building multi-task kernels/
fault-tolerant reliability/ database replication/ flow-on effect systems/
information robustness/ database technology/ business apps, for well over a
decade now.
Here's hoping we can bring a bit more light to this area.
You can also email me personally at:
thomasw 'at' connectorsystems 'dot' co 'dot' nz.
Cheers,
Thomas
