tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Whitmore" <thom...@connectorsystems.co.nz>
Subject context problems: not addressed; summary
Date Tue, 02 May 2006 04:47:15 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message