Difference between revisions of "Migration Guidelines from 0.4.4 to 0.5"
From GCube System
Lucio.lelii (Talk | contribs) (→Changes Related to Services) |
Lucio.lelii (Talk | contribs) (→Changes Related to Services) |
||
Line 52: | Line 52: | ||
:* '''the method <code>org.gcube.common.core.context.GCUBEServiceContext.getConfigFile()</code> is now <code>deprecated</code> and will be removed in the next minor/major release.''' | :* '''the method <code>org.gcube.common.core.context.GCUBEServiceContext.getConfigFile()</code> is now <code>deprecated</code> and will be removed in the next minor/major release.''' | ||
:: The method is replaced by <code>org.gcube.common.core.context.GCUBEServiceContext.getFile()</code>. See [[#filemanagement|below]] for furter information. | :: The method is replaced by <code>org.gcube.common.core.context.GCUBEServiceContext.getFile()</code>. See [[#filemanagement|below]] for furter information. | ||
− | :* the method <code>org.gcube.common.core.informationsystem.notifier.registerToISNotification</code> have new, non retro-compatible changes | + | :* '''the method <code>org.gcube.common.core.informationsystem.notifier.registerToISNotification</code> have new, non retro-compatible changes''' |
− | :* the method <code>org.gcube.common.core.informationsystem.notifier.unregisterFromISNotification</code> have new, non retro-compatible changes | + | :* '''the method <code>org.gcube.common.core.informationsystem.notifier.unregisterFromISNotification</code> have new, non retro-compatible changes''' |
− | :* the method <code>org.gcube.common.core.informationsystem.notifier.registerISNotification</code> have new, non retro-compatible changes | + | :* '''the method <code>org.gcube.common.core.informationsystem.notifier.registerISNotification</code> have new, non retro-compatible changes''' |
− | :* the method <code>org.gcube.common.core.informationsystem.notifier.unregisterISNotification</code> have new, non retro-compatible changes | + | :* '''the method <code>org.gcube.common.core.informationsystem.notifier.unregisterISNotification</code> have new, non retro-compatible changes''' |
:* '''<code>org.gcube.common.core.porttypes.GCUBEStartupPortType</code> is now <code>deprecated</code> and will be removed in the next minor/major release.''' | :* '''<code>org.gcube.common.core.porttypes.GCUBEStartupPortType</code> is now <code>deprecated</code> and will be removed in the next minor/major release.''' | ||
::Derive now ''all'' port-type implementations from <code>org.gcube.common.core.porttypes.GCUBEPortType</code>, regardless of the value set in their deployment descriptors for <code>loadOnStartup</code>. Do note that: | ::Derive now ''all'' port-type implementations from <code>org.gcube.common.core.porttypes.GCUBEPortType</code>, regardless of the value set in their deployment descriptors for <code>loadOnStartup</code>. Do note that: |
Revision as of 11:49, 5 May 2009
gCore 0.5.0RC
requires or supports the following changes to practices and implementations that are compliant with gCore 0.4.4:
Changes Related to the gHN
- package change in
ResultSet
components
- The inclusion of the
ResultSet
service and related components in gCore has coincided with a refactorisation of their package structure. In particular, fully qualified names that begun withorg.gcube.searchservice
begin now withorg.gcube.common.searchservice
.
- package change in
- new log files and log file location.
- All gCore logs are now located in
$GLOBUS_LOCATION/logs
, whilenohup.out
remains in$GLOBUS_LOCATION
(now regardless of where the$GLOBUS_LOCATION/bin/gcore-start-container
is run from). The gHN's logs remains the same (container.fulllog
,container.log
), but the local services have dedicated log files (ghnmanager.log
,deployer.log
,delegation.log
,rs.log
). Globus logs are now collected in a separate log fileglobus.log
and do not propagate to the contatainer's log files (default log level for globus isWARN
). Developers are recommended to configure service-specific logs during development. For this purpose, the configuration for local services in$GLOBUS_LOCATION/container-log4j.properties
can be used as templates.
- new lower bound on memory requirement for gHNs.
- The gHN now requires the allocation of 1GB of heap space to the JVM in which it runs. This is a production-level requirement and can be disabled or corrected during development by editing the script
$GLOBUS_LOCATION/bin/gcore-start-container
(START_OPTIONS
variable).
- new gHN configuration file for offline use.
- gCore ships with a clone of
$GLOBUS_LOCATION/config/GHNConfig.xml
called$GLOBUS_LOCATION/config/GHNConfig.client.xml
. The latter can diverge arbitrarily from the former so as to decouple offline and online use of the gHN.
- (optional) configuration of free port range for the gHN.
- Administrators and developers can now specify a
portRange
environment in$GLOBUS_LOCATION/configs/GHNConfig.xml
' (or$GLOBUS_LOCATION/configs/GHNConfig.client.xml
if useful). The value of the environment can be specified as in the following example:
<environment name="portRange" value="60000-61000" type="java.lang.String" />
- Do note the following:
- The configuration does not imply that the ports are actually 'open', only that they can be bound.
- The gHN management interface (see below) depends on the existence of this configuration.
- The first free port in this range can be obtained by invoking the method
getFreePort()
om theGHNContext
. See the Javadoc documentation for details of the signature.
- Do note the following:
- (optional) use of the JMX management interface.
- The gHN now binds a JMX managemenet interface to the port that it finds free in the configured range (see above). The bound port is shown in the gHN logs:
...GHNContext: INITIALISED MANAGEMENT INTERFACE AT service:jmx:rmi:///jndi/rmi://localhost:60000
- The interface can then be used with
jconsole
, a graphical JMX client that ships with the JDK:
- The interface can then be used with
jconsole localhost:60000
- gHN-specific and RI-specific information and operations can be found in the
MBeans
tabbed pane underorg.gcube
. In the same tabbed pane, logger and appender information and operations can be found underlog4j
.
- gHN-specific and RI-specific information and operations can be found in the
Changes Related to Services
-
org.gcube.common.core.resources.GCUBETransformationProgram
andorg.gcube.common.core.resources.GCUBEVRE
are no longer available.
- These types were not in use as the corresponding resources are modelled with
org.gcube.common.core.resources.GCUBEGenericResource
.
-
- the methods
org.gcube.common.core.state.GCUBEStatefulResource.isRemoved()
andorg.gcube.common.core.state.GCUBEStatefulResource.remove()
are no longer available.
isRemoved()
was intended primarily for internal usage and has been made redundant by the new locking mechanism, which should now be used by developers.remove()
was thread-unsafe as all removal operations should pass for the methodorg.gcube.common.core.state.GCUBEResourceHome.remove()
.
- the methods
- the method
org.gcube.common.core.state.GCUBEStatefulResource.getPersistenceDelegate()
is nowdeprecated
and will be removed in the next minor/major release.
- Exposing persistence delegates is no longer necessary and in fact dangerous. Resource load must be handled transparently by the home associated with the resource, and resource storage can be triggered by invoking directly the method
org.gcube.common.core.state.GCUBEStatefulResource.store()
.
- the method
- the method
org.gcube.common.core.utils.events.GCUBEProducer.registerTopics()
was alreadydeprecated
and is now no longer available.
- The registration of topics is now performed implicitly at the notification of the first event in a given topic.
- the method
- the method
org.gcube.common.core.context.GCUBEServiceContext.getConfigFile()
is nowdeprecated
and will be removed in the next minor/major release.
- The method is replaced by
org.gcube.common.core.context.GCUBEServiceContext.getFile()
. See below for furter information.
- the method
org.gcube.common.core.informationsystem.notifier.registerToISNotification
have new, non retro-compatible changes - the method
org.gcube.common.core.informationsystem.notifier.unregisterFromISNotification
have new, non retro-compatible changes - the method
org.gcube.common.core.informationsystem.notifier.registerISNotification
have new, non retro-compatible changes - the method
org.gcube.common.core.informationsystem.notifier.unregisterISNotification
have new, non retro-compatible changes -
org.gcube.common.core.porttypes.GCUBEStartupPortType
is nowdeprecated
and will be removed in the next minor/major release.
- Derive now all port-type implementations from
org.gcube.common.core.porttypes.GCUBEPortType
, regardless of the value set in their deployment descriptors forloadOnStartup
. Do note that:- The requirement that
loadOnStartup
be set totrue
for at least one port-type implementation does remain. - The requirements to derive
GCUBEPortType
are the same requirements to deriveGCUBEStartupPortType
(i.e. implement the methodgetServiceContext()
).
- The requirement that
- Note also that
GCUBEStartupPortType
is recast as a subclass ofGCUBEPortType
for this release only. - See also the Primer for more information on this requirement.
- the method
- New port-type and home callbacks on RI lifetime.
-
org.gcube.common.core.porttypes.GCUBEPortType
defines callbacks for all the states of RI lifetime:onInitialisation()
,onInitialisation()
onReady()</code,onFailure()
,onUpdate()
,onStateChange()
. The same callbacks are now also defined fororg.gcube.common.core.state.GCUBEResourceHome.remove()
. See the Developer's Guide for specific information on the lifetime of the RI.
- New file management methods on service contexts.
- Service contexts offer two methods to write and read files from the file system:
getFile()
andgetPersistentFile()
. The usage model and difference between the two methods are described in detail in the Developer's Guide, first here and then here . Do notice that, changes to persistent files must be explicitly notified to the persistence manager (see below), if one is configured for the service.
- (Optional) configuration of remote backup/recovery.
- Services that wish to take advantage of the new facility for remote backup and recovery can do so by adding the a
persistenceManagerProfile
resource to theirdeploy-jndi-xml
, as follows:
<resource name="persistenceManagerProfile" type="org.gcube.common.core.persistence.GCUBERIPersistenceManagerProfile"> <resourceParams> <parameter><name>factory</name><value>org.globus.wsrf.jndi.BeanFactory</value></parameter> <parameter><name>className</name><value>org.gcube.common.smspersistence.GCUBESMSPersistenceManager</value> </parameter><parameter><name>monitoringInterval</name><value>...value in seconds...</value></parameter> </resourceParams> </resource>
- Do note the following:
-
className
specifies the class of the only SMS-based persistence manager that ships with gCore -
monitoringInterval
measures in seconds how often the persistent manager will backup the RI state, if and only if this has changed since the last backup. - changes to persisted WS-Resources are automatically detected by the persistence manager. Changes to other files below the storage root of the service must be explicitly flagged by invoking the method
org.gcube.common.core.context.GCUBEServiceContext.notifyStateChange()
.
-
- See also the release notes for an overview of remote persistence.
- Do note the following:
- New
org.gcube.common.core.informationsystem.client.ISClient
interface.
- The
ISClient
interface now supports query by reference. See the Primer for examples on usage.
- New
- New
org.gcube.common.core.informationsystem.notifier.ISNotifier
interface.
- [Please summarise and point to primer section similarly to entry above].
- New
- New persistence modes for
org.gcube.common.core.state.GCUBEResourceHome
.
- Resource homes can now be configured to support additional modes of persistence. See the Primer for an explanation of the available modes and configuration details.
- New persistence modes for
- New locking mechanism for resources.
-
org.gcube.common.core.state.GCUBEStatefulResource
now defines a methodgetLock()
that returns a neworg.gcube.common.core.state.GCUBEReadWriteLock
that can be used by cooperating threads (including gCF's of course) to synchronise their access to the resource.GCUBEReadWriteLock
is an extension of Java'sReadWriteLock
which supports pre-emptive write locks (if one thread succeeds the others waiting for the lock are interrupted). This should be of limited interest to the vast majority of developers as the pre-emptive behaviour is used transparently by gCF on removal operations. Do useGCUBEReadWriteLock
as a standard read-write lock otherwise.
- New interface for sychronous consumers.
- The tagging interface
org.gcube.common.core.utils.events.GCUBESynchronousConsumer
is now available for consumers that wish producers to block in their delivery of events.