Hi people, Sriram, Remy, Costin,
Thanks Sriram for the +1 on this! As you guys have read, I think something is
up in the the area of Context information; specifiers, parsing, and storage of
current deployment state.
I've previously been talking about determinism as one of the problems, but I
don't find much indication that people get what I'm pointing out or are
thinking about this at the 'concept' level.
I'm going to some effort here to clarify this, and communicate these areas.
I would therefore expect competent people to discuss Issues, not "issues". And
please Costin, before you write too much about 'can't parse rant', perhaps try
finding the Enter key on your own keyboard. :-)
-----------
My understanding of the new Context/ Deployment design, is that deployed
Context Specifiers are located in /conf/[engine]/[host]. My further
understanding is, that either Tomcat or the User can create these; tomcat
from a variety of original sources.
Based on this I'd like to make a couple of predictions; re: erroneous
behaviours.
1) Tomcat will be unable to know reliably when a Source context-specifier has
been deleted, in order to delete the resultant Deployed context record.
2) Tomcat does not have enough information to know whether a given Deployed
context-specifier is owned by Tomcat or the User.
Apparently there may already be reports of #1.
Number #2 is likely to lead to to Tomcat auto-scrubbing deployed apps in the
/webapps folder when a context specifier is manually edited, whether these are
owned by tomcat or not.
----------
Now, for a recommended solution.
1) never mix Ownership of anything.
2) store the list of Deployed Context specifiers, away from the user /conf
directory;
- storage in /working would be suitable.
- keep ownership of this entirely to TC; then we will always know what
is going on.
3) sub-folder and named files structure for deployed Master Contexts is
unnecessary.
- it's complex & unnecessary, toss it entirely.
- store as XML file instead.
- all Context elements flat within the head; no need to structure/ nest
or context path.
4) bring back Context.ContextPath attribute, currently non-functional
- current implementation disregards in most cases (!)
- determine simple identification of Context Path from deployed/
context sources
- aka. use the Context Path if it's spec'd
- otherwise, use the default
5) fix recognition of Contexts by DocBase, currently broken
- this will fix Contexts explicitly specified in 'server.xml', from
also being deployed as
duplicates under default settings.
-------
Anyway, hopefully this a good explanation of the issues, and helpful to the
Tomcat developers and contributors in identifying what's wrong here.
I'm aware there are some Clustering issues, driving the current design, but
don't know exactly what these are. My proposed solution delivers Determinism,
and from a replication perspective, providing solid reliability for Context
info would certainly simplify clustering this information.
Obviously, I've already put 8 - 10 hours of thought into this. But, more
importantly, I've seen such 'unreliable' designs before, know what a reliable
one is, and can tell the symptoms & difference pretty much instantly.
As always, the proof is in the pudding; everything I'm raising & reporting is
there, the Context stuff can exhibit ranges of undesirable behaviour (due to
lack of determinism), the Context Path stuff is almost completely broken, etc.
If this *wasn't* the case I'd be full of shit, but it is, so let's look at
moving forward; will those Clustering requirements interact well with the
proposed solution, what other future goals are desirable, etc.
Let me know what you think,
Cheers,
Thomas
Connector Systems Ltd
thomasw 'at' connectorsystems 'dot' co 'dot' nz
