Q1) I think Tim just wanted an easier way to determine a server's version than tracking down the log file or using JConsole to check the TCServerInfoMBean.
Q2) The relatively new L1InfoMBean should probably have a version attribute. Q3) Nope. Q4) I agree with all of that. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Miller Sent: Wednesday, June 04, 2008 8:51 AM To: [email protected] Subject: [tc-dev] Some questions on version checking In looking at updated patch process stuff for the next release, I'm reviewing all the places we use version information (either to check compatibility or to report version info). Here's my list: Compatibility checking: 1) Client/server handshake - Version information comes from ProductInfo in DistributedObjectClient and DistributedObjectServer and is actually compared in ClientHandshakeManager.checkClientServerVersionMatch(). 2) Boot jar version check - Version info is written in the boot jar and then used to check compatibility. This check occurs in BootJarMetaData constructor. 3) Admin console version compatibility check - the check for whether an admin console is compatible with a server release happens in AdminClientPanel. 4) TIM version compatibility check - TIMs are marked with an expected TC version and this version is checked in KnopflerfishOSGi class. Version reporting: 5) Welcome app from kit - shows product version in com.tc.welcome.HyperlinkFrame.AboutAction. 6) Eclipse plugin - shows product version (in different forms) in org.terracotta.dso.actions.[AboutAction, HelpAction]. 7) Update checker in server - reports to update checker in UpdateCheckAction. 8) Server version servlet - reports server version in VersionServlet. 9) Server Mbean - reports server version in TCServerInfo. 10) Console logging - version is logged on startup in TCLogging. Some questions I had: Q1) What is the server version servlet for? Q2) Am I correct that there is no client MBean that reports version? (I've looked but didn't see any) Q3) Did I miss anything you expected to see here? Q4) In general, I think that all of the compatibility checks should ignore patch level when checking compatibility. My only question is whether updating patch level should force boot jar invalidation. Since this is probably infrequent and would be invasive at a customer environment in a patch situation, my current thinking is no. Depending on circumstances, the user might need to force this happen but we can direct them appropriately in that case. Q5) Something else I'm thinking about is what we should be reporting in 5-10 as we report at least 3 or 4 different forms of the version in those. _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
