About
Spring Batch Lightmin is a client/server batch and scheduling platform for the Spring Boot stack. The batch stack based on Spring Batch.
Architecture
Documentation
Samples
All samples for Spring Batch Lightmin can be found at Sample Applications
Getting Started
|
Important
|
Spring 5.1.x set the the property spring.main.allow-bean-definition-overriding to false as a default. In order to use the current version of Spring Batch Lightmin, this property has to be set to true. This issue can hopefully be solved in the upcoming releases. |
The following section describes a quick start guide to setup the client server architecture. If your want to get an overview of the configuration options, please read the documentation. The getting started guide for the Embedded Mode can be found in the section Embedded Lightmin.
Spring Batch Lightmin BOM
Add the Spring Batch Lightmin BOM to the dependency management section of your project.
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-bom</artifactId>
<version>${spring-batch-lightmin.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Setting up the Server
The server is the component which is used to configure clients and schedule jobs.
|
Important
|
The server can be operated in standalone and cluster mode. The standalone mode does not support any synchronisation between multiple cluster instances. Also the server cluster scheduler are working totally independent from each other in standalone mode. |
The server itself is also a Spring Boot application.
Maven Dependencies
Standalone
The following dependency has to added to your project.
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-server-standalone</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
Cluster
The project currently provides one cluster implementation based on Infinispan.
Infinispan
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-server-cluster-infinispan</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
Enable the Server
In order to enable the server, the annotation @EnableLightminServer has to added to one of the @Configuration classes.
@EnableLightminServer
@SpringBootApplication
public class LightminServer {
}
Enable the Cluster
If you added the cluster dependencies the following actions have to be done:
Infinispan
In order to enable the server, the annotation @EnableLightminServer has to added to one of the @Configuration classes.
@EnableLightminServer
@EnableServerClusterInfinispan
@SpringBootApplication
public class LightminServer {
}
The Infinispan cluster configuration will provide the following clustered features:
-
Synchronized poller for server scheduler and clean up jobs
-
LightminServerLockManager implenentation for Infinispan
-
Distributed Repositories for
-
JobExecutionEventRepository
-
JournalRepository
-
LightminApplicationRepository
-
If the following properties are set to true, additional distributed repositories will be provided:
spring:
batch:
lightmin:
server:
cluster:
infinispan:
repository:
init-scheduler-configuration-repository: true # default false (1)
init-scheduler-execution-repository: true # default false (2)
-
if true, a distributed SchedulerConfigurationRepository will be provided
-
if true, a distributed SchedulerExecutionRepository will be provided
|
Important
|
It is highly recommended to use persistent repositories for SchedulerConfigurationRepository and SchedulerExecutionRepository like the JDBC repositories. The distributed repositories will contain the stored values as long as one cluster member is up and running. |
Infinispan Global Configuration
In order to use the infinispan cluster, a GlobalConfiguration has to be provided. The documentation of Infinispan and jGroups will give you insides how to configure it for your need.
@Configuration
public class MyConfiguration {
@Bean
public GlobalConfiguration globalConfiguration() {
return new GlobalConfigurationBuilder()
// Configure the global configuration
.build();
}
}
Server Scheduler
Since lightmin version 2.1.1 the server provides a scheduler to trigger jobs at the clients. In order to provide this feature, the scheduler configurations and executions have to be stored.
The SchedulerConfigurationRepository and SchedulerExecutionRepository are responsible for the doing the job. Per dafault, the standalone server will configure inmemory repositories, which are cleared after each restart.
Configuration Properties
The behavior of the Server Scheduler can be changed via application properties.
spring:
batch:
lightmin:
server:
scheduler:
enabled: true # default true (1)
create-new-executions-on-failure: false # default false (2)
create-new-executions-on-lost: false # default false (3)
fail-on-instance-execution-count: true # default true (4)
poller-period: 1000 # default 1000 (5)
poller-period-retry: 1000 # default 1000 (6)
repository:
delete-poller-period: PT10m # default 10 minutes (7)
delete-failed: true # default true (8)
delete-finished: true # default true (9)
delete-lost: true # default true (10)
keep-failed: PT24h # default 24 hours (11)
keep-finished: PT24h # default 24 hours (12)
keep-lost: PT24h # default 24 hours (13)
-
If set to false, no schedulers will be executed
-
If set to true, a new executions based on the configuration will be created on failure.
-
If set to true, a new executions based on the configuration will be created on lost after configured retries failed.
-
If true, the execution will fail if not enough instances are available.
-
Time in millis to fetch new executions to be executed by the scheduler
-
Time in millis to fetch executions to be retried by the scheduler
-
Duration of the clean up poller for the repositories
-
If set to true, the failed executions will be deleted automatically.
-
If set to true, the finished executions will be deleted automatically.
-
If set to true, the lost executions will be deleted automatically.
-
Duration how long failed executions should be kept before getting deleted automatically.
-
Duration how long finished executions should be kept before getting deleted automatically.
-
Duration how long lost executions should be kept before getting deleted automatically.
|
Important
|
The properties create-new-executions-on-failure: false create-new-executions-on-lost: false fail-on-instance-execution-count: true are global properties. There is the possibility that future releases will support this configuration option per execution. |
Server Scheduler Jdbc Repositories
The database schema for the repositories are available in the dependency at org.tuxdevelop.spring.batch.lightmin.server.scheduler.repository
Maven Dependency
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-server-scheduler-repository-jdbc</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
Enable the JDBC Repository
@EnableLightminServer
@EnableServerSchedulerJdbcRepository
@SpringBootApplication
public class MyApplication {
...
}
Service Discovery
Depending on the clients, the server is also able to find the clients via service discovery.
To enable the feature, a DiscoveryClient implementation has to added and configured(e.g. Consul, Eureka, etc…) and the following property has to set to true
spring::
batch:
lightmin:
server:
discovery-enabled: true
Server behind a Proxy
The server frontend uses redirects and the HOST header is taken to create the redirect urls. This is the default behaviour of Spring MVC. If the server frontend is running behind a proxy, the implementation of the server takes care, that the X-FORWARD-PREFIX header is used as well.
If the proxy cannot pass the HOST header or you do not want to change the defaults, e.g. Zuul, the following property can force the server to use the X-FORWARDED-HOST header to build the redirect urls.
spring:
batch:
lightmin:
server:
use-x-forwarded-headers: true
Setting up a Client
The client applications are responsible to provide Spring Batch Job definitions. The Spring Batch Lightmin client framework provides all the configurations to set up Spring Batch and the communication with the server.
Step one - Client type
The type of the client decides how the registration to the server should be done. Currently to types are supported, classic and via service discovery.
Classic
The classic client has to know where the servers are located and will send a registration request after the start up.
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-client-classic</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The dependency above will provide everything which is required for the classic client. The annotation @EnableLightminClientClassic has to added to one of the configuration classes.
@SpringBootApplication
@EnableLightminClientClassic
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
The following configuration properties have to be present
spring:
application:
name: my-client-application (1)
batch:
lightmin:
client:
classic:
server:
url: http://myserver1.domain:8180, http://myserver2.domain:8180 (2)
-
The spring.application.name is used to identify a client and handle a cluster of the instances.
-
The url property is a list of server to which the registration request should be send.
Service Discovery
Spring Batch Lightmin provides two implementations for the discovery client type. Both implementations add a tags to the underlying service discovery technology, so the server could identify lightmin clients.
Consul Client
The following dependency has to added for the consul client
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-client-discovery-consul</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The annotation @EnableLightminClientConsul enables the fully integration with Consul.
@SpringBootApplication
@EnableLightminClientConsul
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
The configuration options for Consul can be found in the Spring Cloud Consul documentation.
The client is sending per default events to the server, in order to find the server via service discovery, the following property has to be set.
spring:
batch:
lightmin:
client:
discovery:
server-discovery-name: lightmin-server (1)
-
The service discovery name of the server.
Eureka Client
The following dependency has to added for the eureka client
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-client-discovery-eureka</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The annotation @EnableLightminClientEureka enables the fully integration with Eureka.
@SpringBootApplication
@EnableLightminClientEureka
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
The configuration options for Eureka can be found in the Spring Cloud Netflix documentation.
The client is sending per default events to the server, in order to find the server via service discovery, the following property has to be set.
spring:
batch:
lightmin:
client:
discovery:
server-discovery-name: lightmin-server (1)
-
The service discovery name of the server.
Step two - The Configuration Repository
The Configuration Repository is the component which stores the scheduler and listener configurations of the lightmin clients. This configurations are loaded at start time and can be managed with the server frontend or API calls.
Spring Batch Lightmin provides three implementation of the repository
-
map - In memory repository, all changes will be gone after a restart.
-
jdbc - The client fetches and stores the configurations in a database.
-
remote - The client fetches and stores the configurations via API calls to a repository server.
Map Repository
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-repository-map</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The annotation @EnableLightminMapConfigurationRepository enables the in memory repository.
@SpringBootApplication
@EnableLightminClientConsul
@EnableLightminMapConfigurationRepository
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
Jdbc Repository
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-repository-jdbc</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The annotation @EnableLightminJdbcConfigurationRepository enables the jdbc repository.
@SpringBootApplication
@EnableLightminClientConsul
@EnableLightminJdbcConfigurationRepository
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
The jdbc repository requires a configured datasource bean with the name dataSource.
If the project configuration requires a specific datasource for the lightmin repository, the bean name can set via configuration property. More configuration options can be found in the documentation.
spring:
batch:
lightmin:
repository:
jdbc:
data-source-name: myDataSource (1)
-
Overriding the default datasource name.
The database schema ddl and drop scripts for various databases are located in the dependency above under the path:
org/tuxdevelop/spring/batch/lightmin/repository
Remote Repository
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-repository-remote</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
The annotation @EnableLightminRemoteConfigurationRepository enables the remote repository.
@SpringBootApplication
@EnableLightminClientConsul
@EnableLightminRemoteConfigurationRepository
public class ClientApplication {
public static void main(final String[] args) {
SpringApplication.run(ClientApplication.class, args);
}
}
The remote repository can be located via url and service discovery.
For the url way, the following properties has to be set:
spring:
batch:
lightmin:
repository:
remote:
server-url: http://my-server.domain:8280 (1)
-
The url to the remote repository server
For the service discovery approach, the following properties has to set and a DiscoveryClient bean has to be present.
spring:
batch:
lightmin:
repository:
remote:
discover-remote-repository: true (1)
server-discovery-name: remoteRepositorySever (2)
-
Enables the discovery feature
-
The discovery name of the remote repository server
Further configuration options can be found in the documentation.
Step three - Configure Spring Batch
The client configurations are enabling the Spring Batch stack as well. Spring Batch itself has to have a configured JobRepository. This JobRepository can be in memory via map or jdbc.
The configuration of the JobRepository can be done via properties, so Spring Batch Lightmin knows what to configure.
Map JobRepository
For the map repository, the following configuration is enough:
spring:
batch:
lightmin:
batch:
repository-type: map
Jdbc Repository
For the jdbc repository, the following configuration is enough:
spring:
batch:
lightmin:
batch:
repository-type: jdbc
Properties like dataSource name, table prefix etc. can be overridden as well. Please check the documentation for more details.
Clients in Containers
If a client runs inside a container like Docker, the dns name of the host systems has to be transferred to server on registration time. For this use case, a property is available.
spring:
batch:
lightmin:
client:
hostname: FQDN of the host
Lightmin Client and JPA
If your clients uses JPA, the following annotation is required to initialize the JPA specific Lightmin BatchConfigurer.
@Configuration
@EnableLightminBatchJpa (1)
public class MyConfiguration {
}
-
@EnableLightminBatchJpa configures the JPA specific BatchConfigurer
Remote Repository Server
The Remote Repository Server is a Spring Boot application which provides a REST API for clients.
The server itself needs a job configuration repository itself. The server supports map and jdbc.
Maven
For the Jdbc repository, the following dependencies have to be added.
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-repository-server</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-repository-jdbc</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
Configuration
The configuration of the used repository can be found in the client section.
The annotation @EnableLightminRepositoryServer enables the server and the corresponding annotation the job configuration repository.
@SpringBootApplication
@EnableLightminRepositoryServer
@EnableLightminJdbcConfigurationRepository
public class RepositoryServerApplication {
public static void main(final String[] args) {
SpringApplication.run(RepositoryServerApplication.class, args);
}
}
Embedded Lightmin
If the client server architecture does not fit the requirements, Spring Batch Lightmin also provides am embedded mode, which ships the client and server in one package.
Maven
<dependency>
<groupId>org.tuxdevelop</groupId>
<artifactId>spring-batch-lightmin-embedded</artifactId>
<version>${spring-batch-lightmin.version}</version>
</dependency>
Configuration
In this case, a specific client does not have to be configured. The Job Configuration Repository and Spring Batch have to be configured like for a regular client.
@SpringBootApplication
@EnableLightminEmbedded
@EnableLightminMapConfigurationRepository
public class EmbeddedLightminApplication {
public static void main(final String[] args) {
SpringApplication.run(EmbeddedLightminApplication.class, args);
}
}
spring:
batch:
lightmin:
batch:
repository-type: map
Spring Batch Lightmin Metrics
Lightmin Metrics introduces some custom metrics for the Lightmin-Platform. It uses Micrometer to collect metrics. The metrics are available for client and server applications.
Enabling Client Metrics
In order to collect metrics of a Lightmin client application, the following property has to be to true.
spring:
batch:
lightmin:
client:
metrics-enabled: true # default true
|
Important
|
If you want to use runtime information of a client on a server, the following property has to be set to true. The information send will be transformed to metrics on the server, if the sever metrics feature is enabled. |
spring:
batch:
lightmin:
client:
publish-job-events: true # default true
Enabling Server Metrics
In order to collect metrics of a Lightmin server , the following property has to be set to true.
spring:
batch:
lightmin:
server:
metrics-enabled: true # default true
Exposing Metrics via actuator
In order to expose the collected metrics, a Micrometer registry dependencies has to be added to the client and the server.
For prometheus, the following dependencies has to be added
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>${micrometer.version}</version>
</dependency>
|
Important
|
The lightmin dependencies do not provide any registries out of the box |
Modifying Lighmin Metrics
Metrics will be published over prometheus actuator and can be modified by adding MeterFilter into the metrics configuration. Refer to Micrometer Documentation for more information.
@Configuration
public class Config{
final static String name = "EXAMPLE";
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return registry -> {
if (name != null) {
registry.config().meterFilter(
new MeterFilter() {
@Override
public DistributionStatisticConfig configure(Meter.Id id, DistributionStatisticConfig config) {
if (id.getName().startsWith("lightmin")) {
// Example Filter - Activating histogram on all lightmin metrics
return DistributionStatisticConfig.builder().percentilesHistogram(true)
.percentiles(0.95)
.build()
.merge(config);
}
return config;
}
})
.commonTags("example_tag", name);
}
};
}
}
Grafana Dashboards
Lightmin Metrics introduces prebuild Grafana Dashboards for server and client. The json files are available in the resources folder of the lightmin-metrics project. In order to use the plugin, please install the following Plugins:
-
Statusmap by Flant JSC
Lightmin Dashboard
The Spring Batch Lightmin Dashboard provides information about all Lightmin clients which are configured as target in Prometheus. The following variables are available:
-
Service - taken from the tag APPLICATION_NAME (Lightmin Clients should be listed here)
-
Job Name - Name of all jobs, or all jobs of the selected Services
-
Job Count Interval - Time period for the overall SUCCESSFUL and FAILED overview
If a specific Job Name is selected, the details about the job and step execution will be displayed.
Lightmin Server Dashboard
The Server Dashboard provides an overview of all Job Executions, which are send from the clients to the server. The Lightmin server(s) should be configured as target in Prometheus.
|
Important
|
The boards require a Prometheus datasource. |
Server User Interface
Applications
The start page of the SpringBatchLightmin shows all register applications. The status icon shows the current health status of the application.
Application Instance Dashboard
The application dashboard is the entry point to the monitoring and administration of a client application instance. The overview shows the important endpoints, all known Spring Batch Jobs and configured external links of the client application.
Batch Jobs
The batch jobs overview shows all registered batch jobs of the application instance and the execution count of them.
Batch Job Executions
The view shows an overview of all executions for the selected job. To get details of the job execution, click on the desired id.
Job Execution
The job execution view shows you a detailed overview about the job and step executions of the selected job execution.
Job Scheduler
Job Scheduler Configurations are cron or time based scheduler.
Add Job Scheduler Configuration
Period Scheduler
Cron Scheduler
Job Listener
Add Job Listener configuration
Job Launcher
Job Execution Events
Journal
Server Scheduler
Server Scheduler Executions
Server Scheduler Configurations
Add Server Scheduler Configuration
Server Configuration
The SpringBatchLightmin-Server provides defaults configurations. These configurations can be overridden via properties.
Context Path
If the server has a concrete context path, which is different from the servlet path, the default value can be overridden by the following property.
spring:
batch:
lightmin:
server:
#default ""
context-path: /my-path
Heartbeat period
The Heartbeat period is the time in mills to check the health status of the clients.
spring:
batch:
lightmin:
server:
#default 100000
heartbeat-period: 1000
Credentials
If the server has to pass username and password to the clients, the values can be configured via properties.
spring:
batch:
lightmin:
server:
client-user-name: username
client-password: password
Server Side auto discovery
In order to detected lightmin client via service discovery, the following property has to be set to true
spring:
batch:
lightmin:
server:
discovery-enabled: true
Server behind a Proxy
The server ui uses redirects and the HOST header is taken to create the redirect urls. This is the default behavior of Spring MVC. If the server ui is running behind a proxy, the implementation of the server takes care, that the X-FORWARD-PREFIX header is used as well.
If the proxy cannot pass the HOST header or you do not want to change the default, e.g. Zuul, the following property can force the server to use the X-FORWARDED-HOST header to build the redirect urls.
spring:
batch:
lightmin:
server:
use-x-forwarded-headers: true
Custom UI Logo and Text
If you want to place a custom logo or text next to the Spring Boot and Spring Batch logo, the following properties can be used. If the logo property is set, the text will be displayed
spring:
batch:
lightmin:
server:
fe:
#Displays the give label value
label: DEV
#Displays the image of the given url (local and remote)
img-path: img/logo.png
Server Metrics
In order to collect metrics of a Lightmin server , the following property has to be to true.
spring:
batch:
lightmin:
server:
metrics-enabled: true # default true
Server Scheduler
The behavior of the Server Scheduler can be changed via application properties.
spring:
batch:
lightmin:
server:
scheduler:
enabled: true # default true (1)
create-new-executions-on-failure: false # default false (2)
create-new-executions-on-lost: false # default false (3)
fail-on-instance-execution-count: true # default true (4)
poller-period: 1000 # default 1000 (5)
poller-period-retry: 1000 # default 1000 (6)
repository:
delete-poller-period: PT10m # default 10 minutes (7)
delete-failed: true # default true (8)
delete-finished: true # default true (9)
delete-lost: true # default true (10)
keep-failed: PT24h # default 24 hours (11)
keep-finished: PT24h # default 24 hours (12)
keep-lost: PT24h # default 24 hours (13)
Client Configuration
The SpringBatchLightmin-Client tries to configure all client side properties by using the Spring Boot auto configured Server-, ManagementServer- and Actuator-Properties, excepted the url of the SpringBatchLightmin-Server. All these properties can be overridden.
Core
The core properties can be changed for all clients.
Service Url
The service-url is the url of client.
spring:
batch:
lightmin:
client:
service-url: http://localhost:8080/my-app
Management Url
The management-url is the management url of the client.
spring:
batch:
lightmin:
client:
management-url: http://localhost:8080/management
Health Url
The management-url is the health url of the client, it is used by the server to check the status.
spring:
batch:
lightmin:
client:
health-url: http://localhost:8080/management/health
Server Port
The server-port is the application port or the external port, if the application is running inside a container e.g. docker.
spring:
batch:
lightmin:
client:
server-port: 8080
Management Port
The server-port is the application management port or the external port, if the application is running inside a container e.g. docker. If the property is not set, the server-port will be taken.
spring:
batch:
lightmin:
client:
management-port: 8081
Hostname
The hostname property can be used to set the name which should be used for registration at the server. This can be helpful when running inside a container, e.g. docker.
spring:
batch:
lightmin:
client:
hostname: my.fqdn
Publish Job Events
The publish-job-events property can used to deactivate the pushes from the client to the server when a JobExecution is finished.
spring:
batch:
lightmin:
client:
#default: true
publish-job-events: false
Credentials to access Server
If the server is secured with a username and password, the following to properties can be set on the client side.
spring:
batch:
lightmin:
client:
server:
username: myuser
password: mypassword
Classic Client
The following properties can be changed for the classic client
Auto Registration
If auto-registration is set to true, the client tries to register itself automatically.
spring:
batch:
lightmin:
client:
classic:
#default true
auto-registration: true
Auto De-Registration
If auto-deregistration is set to true, the client calls the server for de-registration before the shutdown.
spring:
batch:
lightmin:
client:
classic:
#default true
auto-deregistration: false
Register Once
If register-once is set to true, the client will register itself only at one server.
spring:
batch:
lightmin:
client:
classic:
#default false
auto-register-once: true
Registration Period
The period is the time in millis, the client tries to register at the servers.
spring:
batch:
lightmin:
client:
classic:
#default 10000
period: 100
Lightmin Server
The url is a mandatory property. The value is a comma separated list of server urls.
spring:
batch:
lightmin:
client:
classic:
server:
url: http://localhost:8090, http://localhost:9000
API
The api property gives the relative path to the server side api. If the value is my/api and the url value is http://server:8080, the client tries to register at http://server:8080/my/api
spring:
batch:
lightmin:
client:
classic:
server:
#default api/applications
api: api/application
Discovery Client
The following properties can be changed for the discovery client
Server Discovery Name
The name discovery name of the server which should be used by the DiscoveryClient.
spring:
batch:
lightmin:
client:
discovery:
#default: lightmin-server
server-discovery-name: my-server
Server Context Path
If the server has a context path, this property will be used to enhance the discovery address by the DiscoveryClient.
spring:
batch:
lightmin:
client:
discovery:
server-context-path: /server
Job Configuration Repository Configuration
Jdbc Configuration Repository
The following configuration properties can be used for the jdbc configuration repository
Table Names
If the table name of the provided ddl schemas does not match your requirements, you can rename them and configure the custom names via property.
spring:
batch:
lightmin:
repository:
jdbc:
#default: BATCH_JOB_CONFIGURATION
job-configuration-table-name: my-jc-table-name
#default: BATCH_JOB_CONFIGURATION_VALUE
job-configuration-value-table-name: my-jcv-table-name
#default: BATCH_JOB_CONFIGURATION_PARAMETERS
job-configuration-parameter-table-name: mv-jcp-table-name
Database Schema name
If you have to define a custom schema for your database, the following property can be used.
spring:
batch:
lightmin:
repository:
jdbc:
configuration-database-schema: my-schema
Datasource Name
Per default, the repository tries to get a DataSource bean with the name dataSource. If the DataSource has a different name in your configuration, the following property can be used.
spring:
batch:
lightmin:
repository:
jdbc:
data-source-name: myDataSourceName
Remote Configuration Repository
The following configuration properties can be used for the remote configuration repository
Common
The following properties can be used with and without service discovery
Credentials
If the Remote Repository Server is secured, the following properties can be used to set a username and a password.
spring:
batch:
lightmin:
repository:
remote:
username: username
password: password
No Service Discovery
Server Url
The property points directly to the url of remote repository server.
spring:
batch:
lightmin:
repository:
remote:
server-url: http://my-server.domain:8180
Discovery
Enable Discovery
This property has to be set to true to enable the discovery.
spring:
batch:
lightmin:
repository:
remote:
#default: false
discover-remote-repository: true
Remote Repository Discovery Name
Set or change the discovery name of the Remote Repository Server.
spring:
batch:
lightmin:
repository:
remote:
#default: spring-batch-lightmin-repository-server
server-discovery-name: my-remote-repo
Remote Repository Context Path
If the Remote Repository uses a context path, this property will be added to the discovered url by the DiscoveryClient.
spring:
batch:
lightmin:
repository:
remote:
context-path: /remote-repo-server
Startup Discovery Retry
The retry count to find the repository server.
spring:
batch:
lightmin:
repository:
remote:
#default: 30
server-startup-discovery-retry: 10
Startup Discovery Wait Time
The time period between the retries.
spring:
batch:
lightmin:
repository:
remote:
#default: 500 in millis
server-startup-discovery-retry-wait-time: 200
Batch Configuration
The following properties can be used to configure Spring Batch in lightmin clients.
Repository Type
The type of the JobRepository.
spring:
batch:
lightmin:
batch:
#default: jdbc
repository-type: map
Jdbc JobRepository Configuration
For the jdbc JobRepository, the following properties can be used.
Table Prefix
Prefix for all Spring Batch tables.
spring:
batch:
lightmin:
batch:
#default: BATCH_
table-prefix: MY_PREFIX_
Datasource Name
The name of the DataSource which should be used for Spring Batch.
spring:
batch:
lightmin:
batch:
#default: dataSource
data-source-name: myDataSourceName
Database Schema
The database schema name.
spring:
batch:
lightmin:
batch:
database-schema: myDatabaseSchema
Job Configurations
A job Configuration contains properties, which describes how a job should be launched by Spring Batch Lightmin.
Anatomy of a Job Configuration
public class JobConfiguration extends AbstractConfiguration {
private Long jobConfigurationId;
private String jobName;
private JobSchedulerConfiguration jobSchedulerConfiguration;
private JobListenerConfiguration jobListenerConfiguration;
private Map<String, Object> jobParameters;
private JobIncrementer jobIncrementer;
}
Properties
Job Configuration Id
The jobConfigurationId is a technical id to make the configuration unique.
Job Name
The jobName is the name of Spring Batch Job where the configuration belongs to.
Job Parameters
The jobParameters are keys and values, which will passed to the JobLauncher, when a instance of a Spring Batch Job will be triggered by a JobConfiguration. The key describes the type of the parameter. Following types are currently supported
-
String
-
Long
-
Double
-
Date
Job Incrementer
The jobIncrementer is a job parameter which will be added to existing job parameters. This incrementer can be used to trigger a new JobInstance of a Job.
public enum JobIncrementer {
DATE("DATE_INCREMENTER"),
NONE("NONE");
}
Job Scheduler Configuration
The JobSchedulerConfiguration determines, in which way a Job should be launched.
public class JobSchedulerConfiguration extends AbstractConfiguration {
private JobSchedulerType jobSchedulerType;
private String cronExpression;
private Long initialDelay;
private Long fixedDelay;
private TaskExecutorType taskExecutorType;
private String beanName;
private SchedulerStatus schedulerStatus;
}
JobSchedulerType
The JobSchedulerType determines, if the trigger is a CRON expression or by periods.
public enum JobSchedulerType {
CRON(1L),
PERIOD(2L);
}
cronExpression
It has to be not null and a regular CRON expression, if the JobSchedulerType is set to CRON. It has to be null, if the JobSchedulerType is equal to PERIOD.
initial- & fixedDelay
Both properties must not be null or negative, if the JobSchedulerType is set to PERIOD. The initialDelay configures the delay of the first launched after initialization and the fixedDelay the the period of a relaunch. Both values have to be null, if the JobSchedulerType is equal to CRON.
TaskExecutorType
The TaskExecutorType determines, if the launch of a Job should be synchronously or asynchronously. If the value is set to SYNCHRONOUS, the task executor will wait, until the previous run is finished. On ASYNCHRONOUS mode, the job will be launched, if the CRON or PERIOD trigger fires.
public enum TaskExecutorType {
SYNCHRONOUS("SYNCHRONOUS", 1L),
ASYNCHRONOUS("ASYNCHRONOUS", 2L);
}
beanName
The name of spring bean.
SchedulerStatus
The SchedulerStatus represents the current status of scheduler of the JobConfiguration.
public enum SchedulerStatus {
INITIALIZED("INITIALIZED"),
RUNNING("RUNNING"),
STOPPED("STOPPED"),
IN_TERMINATION("IN TERMINATION");
Job Listener Configuration
The Job Listner Configurations can be registered, to listen for events and triggers a job.
public class JobListenerConfiguration extends AbstractConfiguration {
private JobListenerType jobListenerType;
private String sourceFolder;
private String filePattern;
private Long pollerPeriod;
private String beanName;
private ListenerStatus listenerStatus;
private TaskExecutorType taskExecutorType;
Job Listener Type
public enum JobListenerType {
LOCAL_FOLDER_LISTENER(1L);
}
-
LOCAL FOLDER LISTENER
If the LOCAL FOLDER LISTENER event is fired, the absolut path to the file will be passed as Job Parameter with the name fileSource to the Job Launcher.
Source Folder
The file system folder, the listener should be registered for
File Pattern
Ant based pattern, to filter files, which should be used for the event.
Poller Period
Bean Name
The name of spring bean.
Listener Status
The Listener Status indicates the current status of the Listener Configuration
public enum ListenerStatus {
ACTIVE("ACTIVE"),
STOPPED("STOPPED");
}
Task Executor
The TaskExecutorType determines, if the launch of a Job should be synchronously or asynchronously. If the value is set to SYNCHRONOUS, the task executor will wait, until the previous run is finished. On ASYNCHRONOUS mode, the job will be launched, if a new event occurs.
public enum TaskExecutorType {
SYNCHRONOUS("SYNCHRONOUS", 1L),
ASYNCHRONOUS("ASYNCHRONOUS", 2L);
}
JobConfiguration Repository
The JobConfigurationRepository describes an interface, to manage JobConfigurations. The current version provides three implementations, the JdbcJobConfigurationRepository, RemoteJobConfigurationRepository and the MapJobConfigurationRepository.
public interface JobConfigurationRepository {
JobConfiguration getJobConfiguration(Long jobConfigurationId, String applicationName) throws NoSuchJobConfigurationException;
Collection<JobConfiguration> getJobConfigurations(String jobName, String applicationName) throws NoSuchJobException, NoSuchJobConfigurationException;
JobConfiguration add(JobConfiguration jobConfiguration, String applicationName);
JobConfiguration update(JobConfiguration jobConfiguration, String applicationName) throws NoSuchJobConfigurationException;
void delete(JobConfiguration jobConfiguration, String applicationName) throws NoSuchJobConfigurationException;
Collection<JobConfiguration> getAllJobConfigurations(String applicationName);
Collection<JobConfiguration> getAllJobConfigurationsByJobNames(Collection<String> jobNames, String applicationName);
JdbcJobConfigurationRepository
The JdbcJobConfigurationRepository stores the JobConfiguration within a relational database. In order to use the jdbc version, a ddl schema has to be installed. Schemas for various providers are locate within the core jar.
H2 Schema example
CREATE TABLE BATCH_JOB_CONFIGURATION (
job_configuration_id NUMERIC IDENTITY PRIMARY KEY NOT NULL,
application_name VARCHAR(255) NOT NULL,
job_name VARCHAR(255) NOT NULL,
job_incrementer VARCHAR(255),
job_configuration_type INT NOT NULL
);
CREATE TABLE BATCH_JOB_CONFIGURATION_VALUE (
id NUMERIC IDENTITY PRIMARY KEY NOT NULL,
job_configuration_id NUMERIC NOT NULL,
value_key VARCHAR(255) NOT NULL,
configuration_value VARCHAR(255),
FOREIGN KEY (job_configuration_id) REFERENCES BATCH_JOB_CONFIGURATION (job_configuration_id)
);
CREATE TABLE BATCH_JOB_CONFIGURATION_PARAMETERS (
id NUMERIC IDENTITY PRIMARY KEY NOT NULL,
job_configuration_id NUMERIC NOT NULL,
parameter_name VARCHAR(255) NOT NULL,
parameter_value VARCHAR(255) NOT NULL,
parameter_type INT NOT NULL,
FOREIGN KEY (job_configuration_id) REFERENCES BATCH_JOB_CONFIGURATION (job_configuration_id)
);
RemoteJobConfigurationRepository
The RemoteJobConfigurationRepository communicates with an external repository server via REST API.
MapJobConfigurationRepository
The MapJobConfigurationRepository stores the JobConfigurations within a map. If the application will be restarted, all stored JobConfigurations will be lost.
Spring Batch Lightmin Metrics
Lightmin Metrics introduces some custom metrics for the Lightmin-Platform. It uses Micrometer to collect metrics. The metrics are available for client and server applications.
Enabling Client Metrics
In order to collect metrics of a Lightmin client application, the following property has to be to true.
spring:
batch:
lightmin:
client:
metrics-enabled: true #default true
|
Important
|
If you want to use runtime information of a client on a server, the following property has to be set to true. The send information will be transformed to metrics on the server, if the sever metrics feature is enabled. |
spring:
batch:
lightmin:
client:
publish-job-events: true #default true
Enabling Server Metrics
In order to collect metrics of a Lightmin server , the following property has to be to true.
spring:
batch:
lightmin:
server:
metrics-enabled: true #default true
Exposing Metrics via actuator
In order to expose the collected metrics, a Micrometer registry dependencies has to be added to the client and the server.
For prometheus, the following dependencies has to be added
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>${micrometer.version}</version>
</dependency>
|
Important
|
The lightmin dependencies do not provide any registries out of the box |
Modifying Lighmin Metrics
Metrics will be published over prometheus actuator and can be modified by adding MeterFilter into the metrics configuration. Refer to Micrometer Documentation for more information.
@Configuration
public class Config{
final static String name = "EXAMPLE";
@Bean
public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return registry -> {
if (name != null) {
registry.config().meterFilter(
new MeterFilter() {
@Override
public DistributionStatisticConfig configure(Meter.Id id, DistributionStatisticConfig config) {
if (id.getName().startsWith("lightmin")) {
// Example Filter - Activating histogram on all lightmin metrics
return DistributionStatisticConfig.builder().percentilesHistogram(true)
.percentiles(0.95)
.build()
.merge(config);
}
return config;
}
})
.commonTags("example_tag", name);
}
};
}
}
Grafana Dashboards
Lightmin Metrics introduces prebuild Grafana Dashboards for server and client. The json files are available in the resources folder of the lightmin-metrics project. In order to use the plugin, please install the following Plugins:
-
Statusmap by Flant JSC
Lightmin Dashboard
The Spring Batch Lightmin Dashboard provides information about all Lightmin clients which are configured as target in Prometheus. The following variables are available:
-
Service - taken from the tag APPLICATION_NAME (Lightmin Clients should be listed here)
-
Job Name - Name of all jobs, or all jobs of the selected Services
-
Job Count Interval - Time period for the overall SUCCESSFUL and FAILED overview
If a specific Job Name is selected, the details about the job and step execution will be displayed.
Lightmin Server Dashboard
The Server Dashboard provides an overview of all Job Executions, which are send from the clients to the server.


Star NFL WR Mocks ESPN Announcer Booger McFarland
by Andrew HolleranESPN’s Monday Night Football broadcasting team has received its fair share of criticism this season. Joe Tessitore and Booger McFarland are both good at what they do, but the pairing just doesn’t seem to click for big-time NFL games.
Monday night, a couple of star NFL wide receivers appeared mock McFarland for what he said during the Chiefs-Chargers game.
“Games in this league are lost more than they’re won,” McFarland said on Monday night.
Packers wide receiver Davante Adams didn’t appear to respect that comment. It does have a Trent Dilfer “you can’t lose games and still win” vibe.
Minnesota Vikings wideout Stefon Diggs didn’t seem to like it, either.
The Chiefs ended up winning Monday night’s game, 24-17.


Computech-Electronics/ NEWS / LATEST NEWS / HUAWEI P30 PRO REVIEW: SMARTPHONE PHOTOGRAPHY,REDEFINED
ARTICLE | BY RAY DAVIS | APRIL 6, 2019 6:54 AM PDT
Smartphone cameras have become great in the last decade, but there are still some things they can't do. In fact, I bet these shortcomings have unconsciously trained many of us to avoid taking photos in certain situations: dimly lit restaurants, starry skies, a squirrel sitting in a tree — why bother taking a photo if you know the shot is going to look like crap?
The Huawei P30 Pro is here to change this notion.
It can zoom in like a DSLR, and it can quickly snap low-light photos that would normally require a tripod and a lot of patience. It has every feature you can imagine, and then some. In short: The phone can take photos that other smartphones can only dream of.
The Huawei P30 is not, strictly speaking, Huawei's flagship smartphone. Those honors belong to the Mate series, with new models likely coming in October. But the P30 Pro is a better phone than last year's Mate 20 Pro — and the vast majority of today's phones — in almost every regard.
It has the same Huawei Kirin 980 chip, it comes with 6 or 8GB of RAM and 128, 256, or 512GB of storage, and has a massive 4,200 mAh battery with super fast charging and wireless charging, as well as reverse wireless charging.
The P30 Pro also has a huge, 6.47-inch OLED screen that's curved on the sides, a tiny water drop-shaped notch on top (the phone's screen doubles as a close-proximity speaker, removing the need for a top speaker), an in-display fingerprint scanner, a face recognition system, and IP68 water/dust resistance. It runs Android 9 Pie and Huawei's latest EMUI 9.1 software.
Tiny concessions
With the amount of features smartphones come with these days, the details matter — and there are a few things that the P30 Pro lacks. First, its screen resolution is 2,340 x 1,080, giving it a pixel density of 398 ppi, which is alright, but not on par with the best smartphones. In practice, this means the screen, while still plenty sharp, isn't as amazingly sharp as the screens of the Mate 20 Pro, the iPhone XS Max or the Samsung Galaxy S10+.
That's it — the above are all the significant features I could think of that the P30 Pro doesn't have. To me, none of these are crucial, but they're noteworthy, as some competitors in a similar price range do have them.
The P30 Pro also doesn't have a stereo speaker (because the top speaker has been replaced by the display itself). It doesn't have a front-facing 3D depth sensor. It also doesn't have a headphone jack, and it does not come with a USB-C to 3.5mm connector dongle.
Like most Huawei phones, the P30 Pro feels rock solid and the curved edges are beautiful, but they make the phone very easy to drop.
On the back, there's a choice of shiny gradients and a few solid colors. My review unit had the "Breathing Crystal" color, which is a purple-to-blue-to-white gradient that looks quite beautiful but loses its luster once you put the phone into the (included), see-through case. The vertically positioned cameras make the P30 Pro look like an iPhone from the future, but again, the look's not very original.
A revolutionary camera
Something that none of the competitors have is P30 Pro's wonderful quad-camera array on the back, coupled with a 32-megapixel (f/2.0 aperture) selfie camera on the front.
The rear cameras are, in order:
40-megapixel wide angle camera with f/1.6 aperture and optical image stabilization
20-megapixel ultra-wide angle camera with f/2.2 aperture (no OIS)
8-megapixel telephoto camera with 5x optical zoom, f/3.4 aperture and optical image stabilization
a "time of flight" depth sensor
All of that may seem randomly thrown in just to show off, but it's not. The camera system on the P30 Pro has been carefully designed to produce great photos in situations in which smartphones are typically terrible.
By that, I don't mean sunny, outdoor photos. In those conditions, you'll get good photos from nearly any phone, and P30 Pro is just as good as the best of them. By default, it takes AI-enhanced 10-megapixel photos, meaning that it chooses the best settings depending on what you're shooting (in the example below, the "beach" setting was automatically chosen).
I wasn't a fan of Huawei's AI when it was first introduced, but it appears to be getting better. I was consistently getting great photos on default settings, and switching to 40-megapixel mode was mostly unnecessary.


vector( n ) — vector of length n initialized to zero
vector( n, value ) — vector of length n initialized to a real value
vector( n, [value1,value2] ) — vector of length n initialized to random real values
matrix( n ) — n × n matrix initialized to zero
matrix( n, m ) — n × m matrix initialized to zero
matrix( n, m, value ) — n × m matrix initialized to a real value
matrix( n, m, [value1,value2] ) — n × m matrix initialized to random real values
identity( n ) — n × n real identity matrix
identity( n, value ) — n × n real identity matrix multiplied by a real value
matrixAdd( A, B ) — add two real matrices
matrixSub( A, B ) — subtract two real matrices
matrixMul( A, B ) — multiply two real matrices
transpose( A ) — transpose of a real matrix
inverse( A ) — inverse of a real matrix
determinant( A ) — determinant of a real matrix
luDecomposition( A ) — LU decomposition of a real matrix returned with permutation matrix and total pivots in { L: L, U: U, P: P, pivots: pivots }
luSolve( A, b ) — solution of the real system Ax = b returned as an array
eigensystem( A ) — eigenvalues and column eigenvectors of a real symmetric matrix returned as arrays in { eigenvalues: eigenvalues, eigenvectors: eigenvectors }


|
|||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use Entry | |
| com.sun.jini.lookup.entry | Helper utility classes for managing entries used as lookup service attributes. |
| com.sun.jini.outrigger | This is an implementation of a JavaSpaces(TM) technology-enabled service. |
| net.jini.admin | These interfaces provide common ways to export particular administrative functionality. |
| net.jini.core.entry | The Entry interface and its associated
UnusableEntryException are used by the lookup service
to represent service-specific attributes and by the JavaSpace
interface to mark entries. |
| net.jini.core.lookup | These are the lookup service interfaces and classes. |
| net.jini.entry | Provides classes that are useful when handling or implementing entries. |
| net.jini.lookup | Standard utility classes for managing the join state of a service and the service discovery duties of a client or service. |
| net.jini.lookup.entry | These are common entry classes for use as attributes in lookup services and their associated JavaBeans(TM) component wrapping classes. |
| net.jini.space | JavaSpaces(TM) servers provide a place on the network, a space, for clients to store and exchange objects. |
| Uses of Entry in com.sun.jini.lookup.entry |
| Classes in com.sun.jini.lookup.entry that implement Entry | |
class |
BasicServiceType
An implementation of ServiceType that uses ResourceBundles. |
| Methods in com.sun.jini.lookup.entry that return Entry | |
static Entry[] |
LookupAttributes.add(Entry[] attrSets,
Entry[] addAttrSets)
Returns a new array containing the elements of the addAttrSets parameter (that are not duplicates of
any of the elements already in the attrSets parameter)
added to the elements of attrSets . |
static Entry[] |
LookupAttributes.add(Entry[] attrSets,
Entry[] addAttrSets,
boolean checkSC)
Returns a new array containing the elements of the addAttrSets parameter (that are not duplicates of
any of the elements already in the attrSets parameter)
added to the elements of attrSets . |
static Entry[] |
LookupAttributes.modify(Entry[] attrSets,
Entry[] attrSetTmpls,
Entry[] modAttrSets)
Returns a new array that contains copies of the attributes in the attrSets parameter, modified according to the contents
of both the attrSetTmpls parameter and the
modAttrSets parameter. |
static Entry[] |
LookupAttributes.modify(Entry[] attrSets,
Entry[] attrSetTmpls,
Entry[] modAttrSets,
boolean checkSC)
Returns a new array that contains copies of the attributes in the attrSets parameter, modified according to the contents
of both the attrSetTmpls parameter and the
modAttrSets parameter. |
| Methods in com.sun.jini.lookup.entry with parameters of type Entry | |
static Entry[] |
LookupAttributes.add(Entry[] attrSets,
Entry[] addAttrSets)
Returns a new array containing the elements of the addAttrSets parameter (that are not duplicates of
any of the elements already in the attrSets parameter)
added to the elements of attrSets . |
static Entry[] |
LookupAttributes.add(Entry[] attrSets,
Entry[] addAttrSets,
boolean checkSC)
Returns a new array containing the elements of the addAttrSets parameter (that are not duplicates of
any of the elements already in the attrSets parameter)
added to the elements of attrSets . |
static Entry[] |
LookupAttributes.modify(Entry[] attrSets,
Entry[] attrSetTmpls,
Entry[] modAttrSets)
Returns a new array that contains copies of the attributes in the attrSets parameter, modified according to the contents
of both the attrSetTmpls parameter and the
modAttrSets parameter. |
static Entry[] |
LookupAttributes.modify(Entry[] attrSets,
Entry[] attrSetTmpls,
Entry[] modAttrSets,
boolean checkSC)
Returns a new array that contains copies of the attributes in the attrSets parameter, modified according to the contents
of both the attrSetTmpls parameter and the
modAttrSets parameter. |
static boolean |
LookupAttributes.equal(Entry e1,
Entry e2)
Test that two entries are the same type, with the same public fields. |
static boolean |
LookupAttributes.equal(Entry[] attrSet1,
Entry[] attrSet2)
Tests that two Entry[] arrays are the same. |
static boolean |
LookupAttributes.matches(Entry tmpl,
Entry e)
Test if the parameter tmpl is the same class as, or a
superclass of, the parameter e , and that every
non-null public field of tmpl is the
same as the corresponding field of e . |
static void |
LookupAttributes.check(Entry[] attrs,
boolean nullOK)
Throws an IllegalArgumentException if any element of
the array is not an instance of a valid Entry class
(the class is not public, or does not have a no-arg constructor, or
has primitive public non-static non-final fields). |
| Uses of Entry in com.sun.jini.outrigger |
| Methods in com.sun.jini.outrigger that return Entry | |
Entry[] |
OutriggerServerImpl.getLookupAttributes()
|
Entry |
AdminIterator.next()
Deprecated. Return the next entry in the sequence. |
| Methods in com.sun.jini.outrigger with parameters of type Entry | |
AdminIterator |
ConstrainableJavaSpaceAdmin.contents(Entry tmpl,
Transaction txn)
Deprecated. Return an AdminIterator that will iterate over all
the entries in the space that match the given template and are
visible under the given transaction.
|
AdminIterator |
ConstrainableJavaSpaceAdmin.contents(Entry tmpl,
Transaction txn,
int fetchSize)
Deprecated. Return an AdminIterator that will iterate over all
the entries in the space that match the given template and are
visible under the given transaction.
|
AdminIterator |
ConstrainableJavaSpaceAdmin.contents(Entry tmpl,
Transaction txn,
int fetchSize,
MethodConstraints constrains)
Deprecated. Return an AdminIterator that will iterate over all
the entries in the space that match the given template and are
visible under the given transaction. |
void |
OutriggerServerImpl.addLookupAttributes(Entry[] attrSets)
|
void |
OutriggerServerImpl.modifyLookupAttributes(Entry[] attrSetTemplates,
Entry[] attrSets)
|
AdminIterator |
JavaSpaceAdmin.contents(Entry tmpl,
Transaction txn)
Deprecated. Return an AdminIterator that will iterate over all
the entries in the space that match the given template and are
visible under the given transaction.
|
AdminIterator |
JavaSpaceAdmin.contents(Entry tmpl,
Transaction txn,
int fetchSize)
Deprecated. Return an AdminIterator that will iterate over all
the entries in the space that match the given template and are
visible under the given transaction.
|
| Uses of Entry in net.jini.admin |
| Methods in net.jini.admin that return Entry | |
Entry[] |
JoinAdmin.getLookupAttributes()
Get the current attribute sets for the service. |
| Methods in net.jini.admin with parameters of type Entry | |
void |
JoinAdmin.addLookupAttributes(Entry[] attrSets)
Add attribute sets for the service. |
void |
JoinAdmin.modifyLookupAttributes(Entry[] attrSetTemplates,
Entry[] attrSets)
Modify the current attribute sets, using the same semantics as ServiceRegistration.modifyAttributes. |
| Uses of Entry in net.jini.core.entry |
| Fields in net.jini.core.entry declared as Entry | |
Entry |
UnusableEntryException.partialEntry
The partial entry. |
| Constructors in net.jini.core.entry with parameters of type Entry | |
UnusableEntryException(Entry partial,
String[] badFields,
Throwable[] exceptions)
Create an exception for the given partial entry and vectors of bad field names/nested exception pairs. |
| Uses of Entry in net.jini.core.lookup |
| Fields in net.jini.core.lookup declared as Entry | |
Entry[] |
ServiceItem.attributeSets
Attribute sets. |
Entry[] |
ServiceTemplate.attributeSetTemplates
Attribute set templates to match, or null. |
| Methods in net.jini.core.lookup with parameters of type Entry | |
void |
ServiceRegistration.addAttributes(Entry[] attrSets)
Adds the specified attribute sets (those that aren't duplicates of existing attribute sets) to the registered service item. |
void |
ServiceRegistration.modifyAttributes(Entry[] attrSetTemplates,
Entry[] attrSets)
Modifies existing attribute sets. |
void |
ServiceRegistration.setAttributes(Entry[] attrSets)
Deletes all of the service item's existing attributes, and replaces them with the specified attribute sets. |
| Constructors in net.jini.core.lookup with parameters of type Entry | |
ServiceItem(ServiceID serviceID,
Object service,
Entry[] attrSets)
Simple constructor. |
|
ServiceTemplate(ServiceID serviceID,
Class[] serviceTypes,
Entry[] attrSetTemplates)
Simple constructor. |
| Uses of Entry in net.jini.entry |
| Classes in net.jini.entry that implement Entry | |
class |
AbstractEntry
An abstract implementation of Entry that provides useful
implementations of equals , hashCode , and
toString . |
| Methods in net.jini.entry with parameters of type Entry | |
static boolean |
AbstractEntry.equals(Entry e1,
Entry e2)
Returns true if the two arguments are of the same
class and for each entry field F, the arguments'
values for F are either both null or the
invocation of equals on one argument's value for
F with the other argument's value for F as
its parameter returns true . |
static int |
AbstractEntry.hashCode(Entry entry)
Returns zero XORed with the result of invoking hashCode on each of the argument's
non-null entry fields. |
static String |
AbstractEntry.toString(Entry entry)
Returns a String representation of its argument
that will contain the name of the argument's class and a
representation of each of the argument's entry fields. |
| Uses of Entry in net.jini.lookup |
| Methods in net.jini.lookup that return Entry | |
Entry[] |
JoinManager.getAttributes()
Returns an array containing the set of attributes currently associated with the service. |
| Methods in net.jini.lookup with parameters of type Entry | |
void |
JoinManager.addAttributes(Entry[] attrSets)
Associates a new set of attributes with the service, in addition to the service's current set of attributes. |
void |
JoinManager.addAttributes(Entry[] attrSets,
boolean checkSC)
Associates a new set of attributes with the service, in addition to the service's current set of attributes. |
void |
JoinManager.setAttributes(Entry[] attrSets)
Replaces the service's current set of attributes with a new set of attributes. |
void |
JoinManager.modifyAttributes(Entry[] attrSetTemplates,
Entry[] attrSets)
Changes the service's current set of attributes using the same semantics as the modifyAttributes method of the
ServiceRegistration class.
|
void |
JoinManager.modifyAttributes(Entry[] attrSetTemplates,
Entry[] attrSets,
boolean checkSC)
Changes the service's current set of attributes using the same semantics as the modifyAttributes method of the
ServiceRegistration class.
|
void |
JoinManager.replaceRegistration(Object serviceProxy,
Entry[] attrSets)
Registers a new reference to the service with all current and future discovered lookup services, applying semantics identical to the one-argument form of this method, except with respect to the registration of the given attribute sets. |
| Constructors in net.jini.lookup with parameters of type Entry | |
JoinManager(Object serviceProxy,
Entry[] attrSets,
ServiceIDListener callback,
DiscoveryManagement discoveryMgr,
LeaseRenewalManager leaseMgr)
Constructs an instance of this class that will register the given service reference with all discovered lookup services and, through an event sent to the given ServiceIDListener object,
communicate the service ID assigned by the first lookup service
with which the service is registered. |
|
JoinManager(Object serviceProxy,
Entry[] attrSets,
ServiceIDListener callback,
DiscoveryManagement discoveryMgr,
LeaseRenewalManager leaseMgr,
Configuration config)
Constructs an instance of this class, configured using the items retrieved through the given Configuration object,
that will register the given service reference with all discovered
lookup services and, through an event sent to the given
ServiceIDListener object, communicate the service ID
assigned by the first lookup service with which the service is
registered. |
|
JoinManager(Object serviceProxy,
Entry[] attrSets,
ServiceID serviceID,
DiscoveryManagement discoveryMgr,
LeaseRenewalManager leaseMgr)
Constructs an instance of this class that will register the service with all discovered lookup services, using the supplied ServiceID . |
|
JoinManager(Object serviceProxy,
Entry[] attrSets,
ServiceID serviceID,
DiscoveryManagement discoveryMgr,
LeaseRenewalManager leaseMgr,
Configuration config)
Constructs an instance of this class, configured using the items retrieved through the given Configuration , that will
register the service with all discovered lookup services, using the
supplied ServiceID . |
| Uses of Entry in net.jini.lookup.entry |
| Classes in net.jini.lookup.entry that implement Entry | |
class |
Address
The address of the physical component of a service. |
class |
Comment
A free-form comment about a service. |
class |
Location
The location of the physical component of a service. |
class |
Name
The name of a service as used by users. |
class |
ServiceInfo
Generic information about a service. |
class |
ServiceType
Human-oriented information about the "type" of a service. |
class |
Status
The base class from which other status-related entry classes may be derived. |
| Methods in net.jini.lookup.entry that return Entry | |
Entry |
StatusBean.followLink()
Return the Entry linked to by this JavaBeans component. |
Entry |
ServiceInfoBean.followLink()
Return the Entry linked to by this JavaBeans component. |
Entry |
NameBean.followLink()
Return the Name linked to by this JavaBeans component. |
Entry |
LocationBean.followLink()
Return the Entry linked to by this JavaBeans component. |
Entry |
CommentBean.followLink()
Return the Entry linked to by this JavaBeans component. |
Entry |
EntryBean.followLink()
Return the Entry linked to by this JavaBeans component. |
Entry |
AddressBean.followLink()
Return the Entry linked to by this JavaBeans component. |
| Methods in net.jini.lookup.entry with parameters of type Entry | |
void |
StatusBean.makeLink(Entry e)
Make a link to an Entry object. |
void |
ServiceInfoBean.makeLink(Entry e)
Make a link to an Entry object. |
void |
NameBean.makeLink(Entry e)
Make a link to an Entry object. |
void |
LocationBean.makeLink(Entry e)
Make a link to an Entry object. |
static EntryBean |
EntryBeans.createBean(Entry ent)
Create a bean of the appropriate type for the given Entry object, and link it to the object for immediate manipulation. |
void |
CommentBean.makeLink(Entry e)
Make a link to an Entry object. |
void |
EntryBean.makeLink(Entry e)
Make a link to an Entry object. |
void |
AddressBean.makeLink(Entry e)
Make a link to an Entry object. |
| Uses of Entry in net.jini.space |
| Methods in net.jini.space that return Entry | |
abstract Entry |
AvailabilityEvent.getEntry()
Returns a copy of the Entry whose transition
triggered this event. |
abstract Entry |
AvailabilityEvent.getSnapshot()
Returns a snapshot of the Entry whose
transition triggered this event. |
Entry |
MatchSet.next()
Removes one Entry from the match set and
returns a copy to the caller. |
Entry |
MatchSet.getSnapshot()
Returns a snapshot of the Entry removed by
the last call to next . |
Entry |
JavaSpace.read(Entry tmpl,
Transaction txn,
long timeout)
Read any matching entry from the space, blocking until one exists. |
Entry |
JavaSpace.readIfExists(Entry tmpl,
Transaction txn,
long timeout)
Read any matching entry from the space, returning null if there is currently is none. |
Entry |
JavaSpace.take(Entry tmpl,
Transaction txn,
long timeout)
Take a matching entry from the space, waiting until one exists. |
Entry |
JavaSpace.takeIfExists(Entry tmpl,
Transaction txn,
long timeout)
Take a matching entry from the space, returning null if there is currently is none. |
Entry |
JavaSpace.snapshot(Entry e)
The process of serializing an entry for transmission to a JavaSpaces service will be identical if the same entry is used twice. |
| Methods in net.jini.space with parameters of type Entry | |
Lease |
JavaSpace.write(Entry entry,
Transaction txn,
long lease)
Write a new entry into the space. |
Entry |
JavaSpace.read(Entry tmpl,
Transaction txn,
long timeout)
Read any matching entry from the space, blocking until one exists. |
Entry |
JavaSpace.readIfExists(Entry tmpl,
Transaction txn,
long timeout)
Read any matching entry from the space, returning null if there is currently is none. |
Entry |
JavaSpace.take(Entry tmpl,
Transaction txn,
long timeout)
Take a matching entry from the space, waiting until one exists. |
Entry |
JavaSpace.takeIfExists(Entry tmpl,
Transaction txn,
long timeout)
Take a matching entry from the space, returning null if there is currently is none. |
EventRegistration |
JavaSpace.notify(Entry tmpl,
Transaction txn,
RemoteEventListener listener,
long lease,
MarshalledObject handback)
When entries are written that match this template notify the given listener with a RemoteEvent that
includes the handback object. |
Entry |
JavaSpace.snapshot(Entry e)
The process of serializing an entry for transmission to a JavaSpaces service will be identical if the same entry is used twice. |
|
|||||||||||
| PREV NEXT | FRAMES NO FRAMES |


An explanation of how the hashlife algorithm reduces processing time and effort for cellular automata evaluation.
For my Master's dissertation I did some research using Gosper's Algorithm (also known as hashlife), which is an algorithm for hashing 2-dimensional cellular automata so that running the cellular automata is less memory and processor intensive. Anyway, I am told that the explaination I wrote in my disseration was reasonably comprehensive so I've decided to put that section of my dissertation online. Hopefully it is of use to any unfortunate students who need to try and understand how Hashlife works and don't want to spend the best part of a week stumbling through the originial paper; you can stumble through this as well.
If you need it, here are the references to Gosper's original paper and for my dissertation.
For this project we will be using Gosper's algorithm (Gosper, 1984) to simulate the game of life. It is highly efficient when compared to other simulators because it uses hashing and a mechanism Gosper named "macrocells".
Hashing is a means of storing data structures in a table, called a hashtable, so that they are easily accessed later. The data structure is reduced to a number somehow and this number is used to reference where that data structure is stored in the hashtable. Different data may reduce to the same number, so the hashtable must create a linked list at that location to store all the different entries. Upon retrieval, hashing can significantly reduce the amount of time spent searching for a data structure.
Ordinarily to retrieve data the entire table must be searched each time, but using hashing only the data which reduces to the same number (known as a hash value) needs to be searched. With large quantities of data, such as could be created by a Game of Life simulator, this gives a significant reduction in search time.
A macrocell is a square of cellular automata 2n by 2n in size. Each macrocell stores pointers to 5 smaller 2n-1 by 2n-1 cells. Four of these cells are the four quarters of the larger macrocell, as shown in Figure 1, the other cell is what Gosper referred to as the "RESULT" of the larger macrocell. The RESULT square is concentric to the larger macrocell as shown in Figure 2. It contains the state of the macrocell after 2n-2 time steps, and it is entirely determined by the state of the macrocell. The reason that the RESULT macrocell is 2n-1 in size is that it will take 2n-2 time steps for information outside the macrocell to penetrate the RESULT cell's border. Hence, the RESULT square is the only information that can be accurately predicted from the initial macrocell after 2n-2 steps.
Figure 1: The macrocell is divided into 4 equal parts, each part is an individual but smaller macrocell.
Figure 2: Macrocell showing the dimensions of itself and the RESULT square.
The most important thing to note about macrocells is that they are recursive. Each macrocell contains 5 smaller macrocells, these macrocells also contain 5 macrocells, and so on down to a single cell size 20 x 20; of which, for the Game of Life, there are only 2 (live and dead).
Each macrocell can also be reused. If a macrocell is a repeat of a previously discovered one then it will behave in exactly the same way, so it becomes a pointer to the previously discovered cell in storage. There is no need to store another copy of it in memory. Only if a new macrocell is found do we calculate its RESULT and save the macrocell into memory.
When a macrocell is 4 by 4 in size it is easy to calculate the RESULT using brute force, the cell only needs to advance one time step. However problems arise when n>2. If we take a macrocell and its 4 quadrants we can see that the RESULTs from the quadrants do not fill the area required to calculate the larger RESULT (Figure 3). Furthermore these RESULTs are from 2n-3 time steps into the future not 2n-2, because the existing RESULTs are from the quadrant cells of size 2n-1, and so their RESULT is at time 2(n-2)-1, or 2n-3.
Figure 3: The RESULTs from the quadrants are not sufficient to calculate the RESULT for the whole cell (shown in blue).
The solution Gosper proposed is scalable for all values of n, we will explain it here using an example where n=3.
The first step is to find the state of the macrocell after 2n-3 time steps, which in this example is a 6 x 6 square after 1 time step, the corners of which are already given by the RESULTs of the quadrants. The remaining area, indicated in Figure 4, is calculated by making five temporary 4 x 4 macrocells overlapping the original four, so that their RESULT regions end up occupying the blue area in Figure 4. This gives a 6x6 RESULT square which shows the state of the macrocell after 1 (2n-3) time step.
The next step is much like the first. We need to reduce the 6 x 6 macrocell into a 4 x 4 macrocell that represents the 6x6 macrocell after another 2n-3 time steps (because 2n-3 + 2n-3 = 2n-2, which is the time in the future that we're interested in). The 6 x 6 square is converted to four overlapping 4 x 4 macrocells as illustrated by Figure 5.
The four 4 x 4 macrocells are used to evaluate their 2 x 2 RESULT, and the four 2 x 2 RESULTs are combined to make a 4 x 4 square. As the 6 x 6 RESULT is now being evaluated, the 4 x 4 macrocells are predicting another step into the future to give the RESULT after 2 time steps or 2n-2.
For any value of n there are only two required stages for calculating the result: finding the RESULT after 2n-3 steps, and then using that to find the RESULT at 2n-2 steps. With larger values of n it is more likely we will encounter macrocells that do not have a RESULT; in which case these must be evaluated separately, starting at the smallest values of n and working upwards.
Figure 4: The area of the 6x6 square still left to find. The grey parts are known but the blue areas still need to be found.
Figure 5: Reducing the 6 x 6 square to a 4 x 4 square. The blue area at the top left shows how a 4 x 4 macrocell is found in order to be reduced to a 2 x 2 RESULT. This is repeated to find the other three 2 x 2 squares.
The overall result of the algorithm is to consume much less memory than a naive alternative through the recycling of macrocells and the recursive nature of the algorithm. The macrocells are also able to predict their state 2n-2 steps into the future, and if n is large this also results in a significant loss of overhead.
Hashlife performs best for repetitive or periodic patterns as only a few macrocells are ever needed and they are reused often. For more chaotic patterns the algorithm is less efficient as macrocells are less likely to be repeated and so more are stored and the calculation of RESULTs uses more overhead.


Sign out
|
Users
|
Journal
Completed iteration
See all
available
,
upcoming
,
in progress
, or
rejected
iterations.
Edit your post/comment on Iterations within 15 minutes
5 comments
Add the "todo" designation to BC's printable time report
4 comments
Force SSL Everywhere
8 comments
Edit your post/comment on Iterations within 15 minutes
5 comments
Add the "todo" designation to BC's printable time report
4 comments
Force SSL Everywhere
8 comments


STAGE 1
Initial investors
Prime Movers
1 FYE / ETH
ETH Cap
1000 ETH
STAGE 2
Early adopters
First users of FYE token
Varied
FYE Cap
187,741 FYE
STAGE 3
Upcoming IEO
Public adoption
TBA
No Cap
20,811,259 FYE
Token Address
0xde9F3378969b482B2223B7ba9c6f9b5186f3124A


OBJCOPY
Section: GNU Development Tools (1)Updated: 2012-06-22
Index Return to Main Contents
NAME
objcopy - copy and translate object filesSYNOPSIS
objcopy [-F bfdname|--target=bfdname][-I bfdname|--input-target=bfdname]
[-O bfdname|--output-target=bfdname]
[-B bfdarch|--binary-architecture=bfdarch]
[-S|--strip-all]
[-g|--strip-debug]
[-K symbolname|--keep-symbol=symbolname]
[-N symbolname|--strip-symbol=symbolname]
[--strip-unneeded-symbol=symbolname]
[-G symbolname|--keep-global-symbol=symbolname]
[--localize-hidden]
[-L symbolname|--localize-symbol=symbolname]
[--globalize-symbol=symbolname]
[-W symbolname|--weaken-symbol=symbolname]
[-w|--wildcard]
[-x|--discard-all]
[-X|--discard-locals]
[-b byte|--byte=byte]
[-i interleave|--interleave=interleave]
[-j sectionname|--only-section=sectionname]
[-R sectionname|--remove-section=sectionname]
[-p|--preserve-dates]
[--debugging]
[--gap-fill=val]
[--pad-to=address]
[--set-start=val]
[--adjust-start=incr]
[--change-addresses=incr]
[--change-section-address section{=,+,-}val]
[--change-section-lma section{=,+,-}val]
[--change-section-vma section{=,+,-}val]
[--change-warnings] [--no-change-warnings]
[--set-section-flags section=flags]
[--add-section sectionname=filename]
[--rename-section oldname=newname[,flags]]
[--long-section-names {enable,disable,keep}]
[--change-leading-char] [--remove-leading-char]
[--reverse-bytes=num]
[--srec-len=ival] [--srec-forceS3]
[--redefine-sym old=new]
[--redefine-syms=filename]
[--weaken]
[--keep-symbols=filename]
[--strip-symbols=filename]
[--strip-unneeded-symbols=filename]
[--keep-global-symbols=filename]
[--localize-symbols=filename]
[--globalize-symbols=filename]
[--weaken-symbols=filename]
[--alt-machine-code=index]
[--prefix-symbols=string]
[--prefix-sections=string]
[--prefix-alloc-sections=string]
[--add-gnu-debuglink=path-to-file]
[--keep-file-symbols]
[--only-keep-debug]
[--extract-symbol]
[--writable-text]
[--readonly-text]
[--pure]
[--impure]
[--file-alignment=num]
[--heap=size]
[--image-base=address]
[--section-alignment=num]
[--stack=size]
[--subsystem=which:major.minor]
[-v|--verbose]
[-V|--version]
[--help] [--info]
infile [outfile]
DESCRIPTION
The GNU objcopy utility copies the contents of an object file to another. objcopy uses the GNU BFD Library to read and write the object files. It can write the destination object file in a format different from that of the source object file. The exact behavior of objcopy is controlled by command-line options. Note that objcopy should be able to copy a fully linked file between any two formats. However, copying a relocatable object file between any two formats may not work as expected.objcopy creates temporary files to do its translations and deletes them afterward. objcopy uses BFD to do all its translation work; it has access to all the formats described in BFD and thus is able to recognize most formats without being told explicitly.
objcopy can be used to generate S-records by using an output target of srec (e.g., use -O srec).
objcopy can be used to generate a raw binary file by using an output target of binary (e.g., use -O binary). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file.
When generating an S-record or a raw binary file, it may be helpful to use -S to remove sections containing debugging information. In some cases -R will be useful to remove sections which contain information that is not needed by the binary file.
Note---objcopy is not able to change the endianness of its input files. If the input format has an endianness (some formats do not), objcopy can only copy the inputs into file formats that have the same endianness or which have no endianness (e.g., srec). (However, see the --reverse-bytes option.)
OPTIONS
- infile
- outfile
- The input and output files, respectively. If you do not specify outfile, objcopy creates a temporary file and destructively renames the result with the name of infile.
- -I bfdname
- --input-target=bfdname
- Consider the source file's object format to be bfdname, rather than attempting to deduce it.
- -O bfdname
- --output-target=bfdname
- Write the output file using the object format bfdname.
- -F bfdname
- --target=bfdname
- Use bfdname as the object format for both the input and the output file; i.e., simply transfer data from source to destination with no translation.
- -B bfdarch
- --binary-architecture=bfdarch
- Useful when transforming a architecture-less input file into an object file. In this case the output architecture can be set to bfdarch. This option will be ignored if the input file has a known bfdarch. You can access this binary data inside a program by referencing the special symbols that are created by the conversion process. These symbols are called _binary_objfile_start, _binary_objfile_end and _binary_objfile_size. e.g. you can transform a picture file into an object file and then access it in your code using these symbols.
- -j sectionname
- --only-section=sectionname
- Copy only the named section from the input file to the output file. This option may be given more than once. Note that using this option inappropriately may make the output file unusable.
- -R sectionname
- --remove-section=sectionname
- Remove any section named sectionname from the output file. This option may be given more than once. Note that using this option inappropriately may make the output file unusable.
- -S
- --strip-all
- Do not copy relocation and symbol information from the source file.
- -g
- --strip-debug
- Do not copy debugging symbols or sections from the source file.
- --strip-unneeded
- Strip all symbols that are not needed for relocation processing.
- -K symbolname
- --keep-symbol=symbolname
- When stripping symbols, keep symbol symbolname even if it would normally be stripped. This option may be given more than once.
- -N symbolname
- --strip-symbol=symbolname
- Do not copy symbol symbolname from the source file. This option may be given more than once.
- --strip-unneeded-symbol=symbolname
- Do not copy symbol symbolname from the source file unless it is needed by a relocation. This option may be given more than once.
- -G symbolname
- --keep-global-symbol=symbolname
- Keep only symbol symbolname global. Make all other symbols local to the file, so that they are not visible externally. This option may be given more than once.
- --localize-hidden
- In an ELF object, mark all symbols that have hidden or internal visibility as local. This option applies on top of symbol-specific localization options such as -L.
- -L symbolname
- --localize-symbol=symbolname
- Make symbol symbolname local to the file, so that it is not visible externally. This option may be given more than once.
- -W symbolname
- --weaken-symbol=symbolname
- Make symbol symbolname weak. This option may be given more than once.
- --globalize-symbol=symbolname
- Give symbol symbolname global scoping so that it is visible outside of the file in which it is defined. This option may be given more than once.
- -w
- --wildcard
-
Permit regular expressions in symbolnames used in other command
line options. The question mark (?), asterisk (*), backslash (\) and
square brackets ([]) operators can be used anywhere in the symbol
name. If the first character of the symbol name is the exclamation
point (!) then the sense of the switch is reversed for that symbol.
For example:
-w -W !foo -W fo*
would cause objcopy to weaken all symbols that start with ``fo'' except for the symbol ``foo''.
- -x
- --discard-all
- Do not copy non-global symbols from the source file.
- -X
- --discard-locals
- Do not copy compiler-generated local symbols. (These usually start with L or ..)
- -b byte
- --byte=byte
- Keep only every byteth byte of the input file (header data is not affected). byte can be in the range from 0 to interleave-1, where interleave is given by the -i or --interleave option, or the default of 4. This option is useful for creating files to program ROM. It is typically used with an "srec" output target.
- -i interleave
- --interleave=interleave
- Only copy one out of every interleave bytes. Select which byte to copy with the -b or --byte option. The default is 4. objcopy ignores this option if you do not specify either -b or --byte.
- -p
- --preserve-dates
- Set the access and modification dates of the output file to be the same as those of the input file.
- --debugging
- Convert debugging information, if possible. This is not the default because only certain debugging formats are supported, and the conversion process can be time consuming.
- --gap-fill val
- Fill gaps between sections with val. This operation applies to the load address (LMA) of the sections. It is done by increasing the size of the section with the lower address, and filling in the extra space created with val.
- --pad-to address
- Pad the output file up to the load address address. This is done by increasing the size of the last section. The extra space is filled in with the value specified by --gap-fill (default zero).
- --set-start val
- Set the start address of the new file to val. Not all object file formats support setting the start address.
- --change-start incr
- --adjust-start incr
- Change the start address by adding incr. Not all object file formats support setting the start address.
- --change-addresses incr
- --adjust-vma incr
- Change the VMA and LMA addresses of all sections, as well as the start address, by adding incr. Some object file formats do not permit section addresses to be changed arbitrarily. Note that this does not relocate the sections; if the program expects sections to be loaded at a certain address, and this option is used to change the sections such that they are loaded at a different address, the program may fail.
- --change-section-address section{=,+,-}val
- --adjust-section-vma section{=,+,-}val
- Set or change both the VMA address and the LMA address of the named section. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under --change-addresses, above. If section does not exist in the input file, a warning will be issued, unless --no-change-warnings is used.
- --change-section-lma section{=,+,-}val
- Set or change the LMA address of the named section. The LMA address is the address where the section will be loaded into memory at program load time. Normally this is the same as the VMA address, which is the address of the section at program run time, but on some systems, especially those where a program is held in ROM, the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under --change-addresses, above. If section does not exist in the input file, a warning will be issued, unless --no-change-warnings is used.
- --change-section-vma section{=,+,-}val
- Set or change the VMA address of the named section. The VMA address is the address where the section will be located once the program has started executing. Normally this is the same as the LMA address, which is the address where the section will be loaded into memory, but on some systems, especially those where a program is held in ROM, the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under --change-addresses, above. If section does not exist in the input file, a warning will be issued, unless --no-change-warnings is used.
- --change-warnings
- --adjust-warnings
- If --change-section-address or --change-section-lma or --change-section-vma is used, and the named section does not exist, issue a warning. This is the default.
- --no-change-warnings
- --no-adjust-warnings
- Do not issue a warning if --change-section-address or --adjust-section-lma or --adjust-section-vma is used, even if the named section does not exist.
- --set-section-flags section=flags
- Set the flags for the named section. The flags argument is a comma separated string of flag names. The recognized names are alloc, contents, load, noload, readonly, code, data, rom, share, and debug. You can set the contents flag for a section which does not have contents, but it is not meaningful to clear the contents flag of a section which does have contents---just remove the section instead. Not all flags are meaningful for all object file formats.
- --add-section sectionname=filename
- Add a new section named sectionname while copying the file. The contents of the new section are taken from the file filename. The size of the section will be the size of the file. This option only works on file formats which can support sections with arbitrary names.
- --rename-section oldname=newname[,flags]
-
Rename a section from oldname to newname, optionally
changing the section's flags to flags in the process. This has
the advantage over usng a linker script to perform the rename in that
the output stays as an object file and does not become a linked
executable.
This option is particularly helpful when the input format is binary, since this will always create a section called .data. If for example, you wanted instead to create a section called .rodata containing binary data you could use the following command line to achieve it:
objcopy -I binary -O <output_format> -B <architecture> \ --rename-section .data=.rodata,alloc,load,readonly,data,contents \ <input_binary_file> <output_object_file>
- --long-section-names {enable,disable,keep}
- Controls the handling of long section names when processing "COFF" and "PE-COFF" object formats. The default behaviour, keep, is to preserve long section names if any are present in the input file. The enable and disable options forcibly enable or disable the use of long section names in the output object; when disable is in effect, any long section names in the input object will be truncated. The enable option will only emit long section names if any are present in the inputs; this is mostly the same as keep, but it is left undefined whether the enable option might force the creation of an empty string table in the output file.
- --change-leading-char
- Some object file formats use special characters at the start of symbols. The most common such character is underscore, which compilers often add before every symbol. This option tells objcopy to change the leading character of every symbol when it converts between object file formats. If the object file formats use the same leading character, this option has no effect. Otherwise, it will add a character, or remove a character, or change a character, as appropriate.
- --remove-leading-char
- If the first character of a global symbol is a special symbol leading character used by the object file format, remove the character. The most common symbol leading character is underscore. This option will remove a leading underscore from all global symbols. This can be useful if you want to link together objects of different file formats with different conventions for symbol names. This is different from --change-leading-char because it always changes the symbol name when appropriate, regardless of the object file format of the output file.
- --reverse-bytes=num
-
Reverse the bytes in a section with output contents. A section length must
be evenly divisible by the value given in order for the swap to be able to
take place. Reversing takes place before the interleaving is performed.
This option is used typically in generating ROM images for problematic target systems. For example, on some target boards, the 32-bit words fetched from 8-bit ROMs are re-assembled in little-endian byte order regardless of the CPU byte order. Depending on the programming model, the endianness of the ROM may need to be modified.
Consider a simple file with a section containing the following eight bytes: 12345678.
Using --reverse-bytes=2 for the above example, the bytes in the output file would be ordered 21436587.
Using --reverse-bytes=4 for the above example, the bytes in the output file would be ordered 43218765.
By using --reverse-bytes=2 for the above example, followed by --reverse-bytes=4 on the output file, the bytes in the second output file would be ordered 34127856.
- --srec-len=ival
- Meaningful only for srec output. Set the maximum length of the Srecords being produced to ival. This length covers both address, data and crc fields.
- --srec-forceS3
- Meaningful only for srec output. Avoid generation of S1/S2 records, creating S3-only record format.
- --redefine-sym old=new
- Change the name of a symbol old, to new. This can be useful when one is trying link two things together for which you have no source, and there are name collisions.
- --redefine-syms=filename
- Apply --redefine-sym to each symbol pair "old new" listed in the file filename. filename is simply a flat file, with one symbol pair per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --weaken
- Change all global symbols in the file to be weak. This can be useful when building an object which will be linked against other objects using the -R option to the linker. This option is only effective when using an object file format which supports weak symbols.
- --keep-symbols=filename
- Apply --keep-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --strip-symbols=filename
- Apply --strip-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --strip-unneeded-symbols=filename
- Apply --strip-unneeded-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --keep-global-symbols=filename
- Apply --keep-global-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --localize-symbols=filename
- Apply --localize-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --globalize-symbols=filename
- Apply --globalize-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --weaken-symbols=filename
- Apply --weaken-symbol option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
- --alt-machine-code=index
- If the output architecture has alternate machine codes, use the indexth code instead of the default one. This is useful in case a machine is assigned an official code and the tool-chain adopts the new code, but other applications still depend on the original code being used. For ELF based architectures if the index alternative does not exist then the value is treated as an absolute number to be stored in the e_machine field of the ELF header.
- --writable-text
- Mark the output text as writable. This option isn't meaningful for all object file formats.
- --readonly-text
- Make the output text write protected. This option isn't meaningful for all object file formats.
- --pure
- Mark the output file as demand paged. This option isn't meaningful for all object file formats.
- --impure
- Mark the output file as impure. This option isn't meaningful for all object file formats.
- --prefix-symbols=string
- Prefix all symbols in the output file with string.
- --prefix-sections=string
- Prefix all section names in the output file with string.
- --prefix-alloc-sections=string
- Prefix all the names of all allocated sections in the output file with string.
- --add-gnu-debuglink=path-to-file
- Creates a .gnu_debuglink section which contains a reference to path-to-file and adds it to the output file.
- --keep-file-symbols
- When stripping a file, perhaps with --strip-debug or --strip-unneeded, retain any symbols specifying source file names, which would otherwise get stripped.
- --only-keep-debug
-
Strip a file, removing contents of any sections that would not be
stripped by --strip-debug and leaving the debugging sections
intact. In ELF files, this preserves all note sections in the output.
The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part executable. One a stripped binary which will occupy less space in RAM and in a distribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested procedure to create these files is as follows:
-
- 1.<Link the executable as normal. Assuming that is is called>
- "foo" then...
- 1.<Run objcopy --only-keep-debug foo foo.dbg to>
- create a file containing the debugging info.
- 1.<Run objcopy --strip-debug foo to create a>
- stripped executable.
- 1.<Run objcopy --add-gnu-debuglink=foo.dbg foo>
- to add a link to the debugging info into the stripped executable.
-
Note---the choice of ".dbg" as an extension for the debug info file is arbitrary. Also the "--only-keep-debug" step is optional. You could instead do this:
-
i.e., the file pointed to by the --add-gnu-debuglink can be the full executable. It does not have to be a file created by the --only-keep-debug switch.
Note---this switch is only intended for use on fully linked files. It does not make sense to use it on object files where the debugging information may be incomplete. Besides the gnu_debuglink feature currently only supports the presence of one filename containing debugging information, not multiple filenames on a one-per-object-file basis.
-
- --file-alignment num
- Specify the file alignment. Sections in the file will always begin at file offsets which are multiples of this number. This defaults to 512. [This option is specific to PE targets.]
- --heap reserve
- --heap reserve,commit
- Specify the number of bytes of memory to reserve (and optionally commit) to be used as heap for this program. [This option is specific to PE targets.]
- --image-base value
- Use value as the base address of your program or dll. This is the lowest memory location that will be used when your program or dll is loaded. To reduce the need to relocate and improve performance of your dlls, each should have a unique base address and not overlap any other dlls. The default is 0x400000 for executables, and 0x10000000 for dlls. [This option is specific to PE targets.]
- --section-alignment num
- Sets the section alignment. Sections in memory will always begin at addresses which are a multiple of this number. Defaults to 0x1000. [This option is specific to PE targets.]
- --stack reserve
- --stack reserve,commit
- Specify the number of bytes of memory to reserve (and optionally commit) to be used as stack for this program. [This option is specific to PE targets.]
- --subsystem which
- --subsystem which:major
- --subsystem which:major.minor
- Specifies the subsystem under which your program will execute. The legal values for which are "native", "windows", "console", "posix", "efi-app", "efi-bsd", "efi-rtd", "sal-rtd", and "xbox". You may optionally set the subsystem version also. Numeric values are also accepted for which. [This option is specific to PE targets.]
- --extract-symbol
-
Keep the file's section flags and symbols but remove all section data.
Specifically, the option:
-
This option is used to build a .sym file for a VxWorks kernel. It can also be a useful way of reducing the size of a --just-symbols linker input file.
- -V
- --version
- Show the version number of objcopy.
- -v
- --verbose
- Verbose output: list all object files modified. In the case of archives, objcopy -V lists all members of the archive.
- --help
- Show a summary of the options to objcopy.
- --info
- Display a list showing all architectures and object formats available.
- @file
-
Read command-line options from file. The options read are
inserted in place of the original @file option. If file
does not exist, or cannot be read, then the option will be treated
literally, and not removed.
Options in file are separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The file may itself contain additional @file options; any such options will be processed recursively.
SEE ALSO
ld(1), objdump(1), and the Info entries for binutils.COPYRIGHT
Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
Index
This document was created by man2html, using the manual pages.
Time: 05:29:06 GMT, December 24, 2015