thanks for reading! I'll note Q2 in the doc to be added. On Jun 4, 2008, at 3:35 PM, Gary Keim wrote:
> 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
