prediction; context problems

[Thomas Whitmore <th...@connectorsystems.co.nz>]

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