Date: 31 July 2008
Archive: version 0.1
Initial release (beta). Targets SAMP WD v1.0 (25 June 2008).
Date: 19 September 2008
Archive: version 0.2
xmlrpcpackage itself defines a pluggable interface for providing XML-RPC client and server functionality; two implementations are also provided, in the packages xmlrpc.apache and xmlrpc.internal. The Apache one is basically what was there in previous versions; the internal one is completely freestanding, and if this is used the Apache XML-RPC library is not required for operation.
ConnectorGuiprovides Actions suitable for insertion in a general SAMP control menu, and SendActionManager provides menus and Actions for sending particular messages.
HubClientprivateKey member is now an Object not a String, for greater generality.
HubRunnerclass moved from package
Date: 25 September 2008
Archive: Version 0.2-1
jsamp.xmlrpc.implproperty now correctly propagated to JVM running external hub.
hubmonitorwhich meant that sometimes window did not appear.
Date: 9 December 2008
Archive: Version 0.3
msg-guimode and then run
HubTester. Or just use the hub with your own SAMP clients. Note that this functionality incurs some overhead - if not used no such overhead is incurred.
-xmlrpcflags of command-line tools, and classes
DefaultSendActionManagerwith other, more capable,
SendActionManagersubclasses. This makes it easy to handle the results from messages which have been sent, for instance by passing the information to the user graphically or in other ways.
gui.GuiHubConnectornow contains the Swing-related functionality which was previously in (its superclass)
client.HubConnector, and also all the functionality from the now removed class
ConnectorGuiAPIs modified to permit use of various different hub implementations (with different graphical characteristics - see
notifyAllhub methods as per agreed modifications to the standard at version 1.1. Affects hub and client API, implementation and test suite.
Date: 27 March 2009
Archive: Version 0.3-1
GuiHubConnector.createRegisterOrHubActionmethod, which registers if it can, else offers the user to start a hub. This may be the only button you need.
HubConnector- these allow you to make asynchronous calls so that the results are delivered as callbacks to supplied objects without having to worry about registering handlers and matching tags.
SendActionManagerclass. These give another way (button plus combo box) go allow users to trigger a send.
.samplockfile noting that contact XML-RPC URL hostname is configurable.
samp.httpd. Also added some utility classes in that package to facilitate serving dynamic resources and resources from the classpath. This is because having a simple self-contained HTTP server may be useful for client implementations doing SAMP-like things other than strictly communicating with the hub.
LogResultHandlerclasses moved from package
Date: 5 August 2009
Archive: Version 1.0
Though this version is numbered 1.0, it's not a giant leap ahead of the previous one (0.3-1). However, this is the first release since SAMP became an IVOA Recommendation, and this toolkit is believed to be fully compliant with that standard. The intention is that backwardly incompatible changes will be kept to a minimum following this release.
jsamp.server.portprovided to allow selection of the default server port.
jsamp.lockfileprovided to support non-standard lockfile location.
samp.secretstring for HubRunner if you don't want it chosen randomly.
Changes to behaviour (note some of these may have backward compatibility issues):
SampUtils.getLocalHost()) is now "127.0.0.1", not the DNS name; in certain network environments this works better than the alternatives, though it's less good for inter-machine communications. This default can be altered by setting the
samp.hostnamesystem property; it has two new special values "[hostname]" and "[hostnumber]".
jsamp.localhost(the old name is still recognised for backward compatibility).
-xmlrpcflag from command-line tools; the
jsamp.xmlrpc.implsystem property should be used instead.
API Changes (note some of these may have backward compatibility issues):
DefaultClientProfileclass; this is now the recommended way of getting a general purpose ClientProfile object (rather than using
StandardClientProfile.getInstance(). Using this will aid pluggability (ability to use with non-standard profiles in the future).
UtilServerclass; this can help to reduce the number of HTTP servers run by a JSAMP application, and provides convenience methods for exporting local (e.g. file: or classpath) URLs.
parseValueutility method to
org.astrogrid.samp.xmlrpc, which is where it should have been.
jsamp.versionfile now included in source zip archive.
Date: 21 July 2010
Archive: Version 1.1
jsamp.profilesystem properties which did the same job in a non-standard way have been withdrawn. This has some backwardly incompatible consequences:
jsamp.profilesystem properties withdrawn; use
SAMP_HUBenvironment variable instead.
SampUtils.LOCKFILE_NAMEconstant withdrawn; use
SampUtils.getLockFile()method withdrawn; use
StandardClientProfile.getLockUrl()instead. If you want to find out if a hub is running, instead of
LockInfo.readLockFile(File)method withdrawn; use
LockInfo.readLockFile()method withdrawn; use
LockWriterno-arg constructor withdrawn.
-httplockflag to hubrunner, which allows publication of lockfile by HTTP for use by non-localhost clients.
java -jar jsamp.jar") with no arguments now starts the hub rather than just printing a usage message.
isHubRunning. This is more general (and easier to use) than testing something like
HubRunnner.runHubmethod now returns the running HubRunner instance.
faultCodewas string instead of int).
addShutdownHookin XmlRpcHubConnection. It seems that signed applets may not have the appropiate permissions.
StandardClientProfile.getInstance()as they should (hence will be correctly influenced by
getClientMapis called before
HubConnector, since without declaring subscriptions the client map won't work.
Date: 15 Feb 2011
Archive: Version 1.2
The two main changes at this release are generalisation of the hub running framework to allow multiple profiles to run interfacing to the same hub simultaneously, and implementation of the experimental Web Profile. The former was motivated by the latter (though should really have been present from the start). This work was suggested by Jonathan Fay and financially supported by Microsoft Research, whose support is gratefully acknowledged. There are also a number of bug fixes and minor enhancements.
org.astrogrid.samp.hub.HubRunnerclass has been deprecated in favour of the new class org.astrogrid.samp.hub.Hub. This can be used from the command line or programmatically to start a hub, and it can run zero or more profiles, defined by the new HubProfile interface, simultaneously. HubProfile implementations are provided for the Standard Profile and the Web Profile, and you can plug in your own at runtime. This class is now the Main-Class defined in the jar file's Manifest, so invoking (e.g. clicking or java -jar) the jsamp-*.jar file will now invoke this class. Documentation of the command-line usage is on the Command-line Tools page. By default only the Standard Profile is run, so simply invoking the jar file will have much the same behaviour as it did in previous versions, that is starting a Standard Profile-only hub. Which profiles are run can be influenced in various ways, including by defining the
A new "facade" mode of hub operation has been introduced, which allows tunnelling from one hub profile to another (mostly of interest to hub profile implementors).
There have been a number of other backwardly incompatible changes to the hub implementation classes: Most of the
HubServiceinterface has been replaced using
Receiverhas been replaced with
CallableClient, reducing amount and duplication of code, and some assumptions specific to the Standard Profile have been removed from the interfaces of hub classes which are properly profile-independent. These changes are not believed likely to affect anybody who is not writing hub implementation code.
This release also includes client and hub implementations of the experimental Web Profile. Implementation is in the new package org.astrogrid.samp.web. Note that this profile is still under discussion and details of the definition may change in the future.
ApacheServer(thanks to Laurent Bourgès).
Minor changes and enhancements:
SampXmlRpcHandlerinterface gets an additional argument.
java.awt.Window.locationByPlatformsystem property is set, if it does not already have an explicit value, in the JSamp class.
createResponsewhich may be overridden for more flexibility.
Date: 2 Aug 2011
Archive: Version 1.3
Various changes relating to configurable use of profiles and the Web Profile in particular, to match the SAMP 1.3 WD, and to enable experimentation with multi-profile configurations while we gain experience with security options. There is more discussion in the new Profiles page, but the main changes are:
-web:extraprofilesand system property
mapargument and not a
register(), as per the change to the Web Profile specification.
Hub.runHub(), still works though.
The Hub GUI window now has menus:
JSON is now used as the standard serialization/deserialization format for SAMP objects in a few places:
fromJsonin SampUtils class.
snoopertools on the command line using JSON syntax.
ClientProfile.isHubRunningmethod now probes more agressively for a hub (for instance in the Standard Profile it pings rather than just looking for the .samp file). This is a change to both the API and the implementations.
org.astrogrid.samp.web.AuthResourceBundle_xx.propertiesresource; run AuthResourceBundle.main() for example output.
HubMonitornow correctly uses