Přesto lze ještě trochu vylepšit jeho vzhled a fungování. Všechny informace jsem získal a vyzkoušel na mém Ubuntu 11.10 (Oneiric) 32bit.

Lepší vzhled

Největším šokem je vzhled. Upřímně dost odporný. Defaultně používá vzhled (Look & Feel – LAF) GTKLookAndFeel, tedy nativní vzhled v Gnome 2/3 a Xfce (sorry KDE). Hned jsem chtěl nastavit vzhled Nimbus bohužel se pak v tom případě text nevešli do vyhraženého místa na dialogu. To je jednoznačně chyba FlexiBee, nikoli Javy. Sami se zaměřujeme na Swing a NetBeans Platform (na Swingu postavený) a změna vzhledu neovlivní dialogy.

Všechno nastavení FlexiBee najdete ve spuštěcím skriptu /usr/bin/flexibee. Otevřeme tedy v editoru skript:

$ gksudo gedit /usr/bin/flexibee

Jediný použitelný LAF je Metal. Ten sice není příliš “sexy”, ale ještě to jde. Aniž bych moc pátral zkusil jsem jestli stačí nastavit standardní Swingovské systémové proměnné

• swing.defaultlaf = javax.swing.plaf.metal.MetalLookAndFeel — třída vzhledu
• swing.boldMetal = false — Metal netučné písmo. Tučné, které se opět nevejde do vymezeného místa.

do proměnné FLEXIBEE_JAVA_ARGS konfiguračního souboru. Ovšem aby námi nastavené LAF FlexiBee neignorovalo musíte ještě do FLEXIBEE_ARGS musíte doplnit --no-laf. Ve výsledku tedy: (zaskrolujte až úplně do prava)

FLEXIBEE_ARGS="--no-laf"
FLEXIBEE_JAVA_ARGS="-Xmx512m -client -XX:MaxPermSize=128m  -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:-OmitStackTraceInFastThrow -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel -Dswing.boldMetal=false"

Reinstalace

Když zapomenete heslo, ale nevadí vám přijít o data (máte totiž zálohu… )), pak v manálu píší, že musíte odinstalovat a nainstalovat znovu.

Jen toto mi nepomohlo. Musíte ještě vymazat skytou složku .winstrom ve svém domovském adresáři. Tepre poté se objeví průvodce prvního spuštění a umožní vytvořit novou databázi.

Nastavení vlastní JRE

Pokud máte na PC více Java Runtime a FlexiBee nenašlo tu správnou (jakou používá zjistíte v dialogu O aplikaci) není nic jednodušší, než ji nastavit ručně: (např. Oracle JDK 7)

FLEXIBEE_JAVA="/usr/lib/jvm/jdk1.7.0_01/jre/bin/java"

In past, only way how to an exception throw will not fail complete test was to label test method with @Test(expected=SomeExpectedException.class) annotation.

From JUnit 4.7 we have much richer tool to test if only certain method or methods call inside your test method throw an exception that we expect. This ability is called rules.

Pre JUnit 4.7 way:

@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
    ArrayList emptyList = new ArrayList();
    Object o = emptyList.get(0);
}

JUnit 4.7+ way:

public class BagRoundTest {
    @Rule
    public ExpectedException exception = ExpectedException.none();
 
    @Test
    public void bagRound() {
        something();
 
        // Add expected exception to expected exception list
        exception.expect(ValidactionException.class);
        methodThatIntentionallyThowsValidationException()
        // In the rest of test method no more ValidactionException.class is expected
        exception = ExpectedException.none();
 
        something();
    }
}

Other more advanced techniques are discussed here for example in this StackOverflow question.

Editor settings

• Indentation is usually 1 tab with 4 spaces width.
• Trailing whitespaces should be removed before commiting to SCM.

In NetBeans go to Tools / Options / Editor tab and set Remove Trailing Whitespace to Always.

GUI naming

• txtXXX – JText field
• btnXXX – JButton
• lblXXX – JLabel

Tasks in comments

We tried to standardize commonly used tasks hard-written in source code comments. Although every “larger then small” or important bug/feature should always also be filed in bugtracker.

• TODO – must be done
• BUG – needs to be fixed
• ENH – nice to have enhancement
• MAYBE – maybe/sometime or never
• ASK – question or point to analyse in detail

Field naming

JavaBeans standard:

• setField
• getField
• addListener
• removeListener

When you don’t want to unintentionally create JavaBean field by using set/get convention is necessity to use different prefixes:

• specField instead of setField
• giveField instead of getField

NetBeans IDE or NetBeans Platform app

1. In NetBeans IDE installation directory
   • under Ubuntu it’s /home/libor/dev/netbeans/
   • under Windows it’s C:\Program Files\NetBeans\

1. Find etc directory and netbeans.conf file

1. Add to the end of line beginning with netbeans_default_options parameter

--laf path.to.your.laf

e.g. --laf javax.swing.plaf.nimbus.NimbusLookAndFeel

On my Ubuntu 11.10 and Oracle JDK 7 I have available:

javax.swing.plaf.metal.MetalLookAndFeel
javax.swing.plaf.nimbus.NimbusLookAndFeel
com.sun.java.swing.plaf.motif.MotifLookAndFeel
com.sun.java.swing.plaf.gtk.GTKLookAndFeel

Please note that GTKLookAndFeel is not available in Windows.

• --laf Nimbus for Nimbus L&F
• --laf javax.swing.plaf.metal.MetalLookAndFeel for Metal L&F
• --laf Gtk for Metal L&F
• --laf path.to.your.laf for any other L&F

Notice that I am using fully qualified class with package name or just class. If class is available to NetBeans launcher script (JDK standard LAFs), you can abbreviate to class name.

So complete line can looks like this (text wrapped for better legibility):

netbeans_default_options="-J-client -J-Xss2m -J-Xms32m 
-J-XX:PermSize=32m -J-XX:MaxPermSize=384m 
-J-Dapple.laf.useScreenMenuBar=true 
-J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true 
-J-DuseSystemAAFontSettings=lcd -J-Dswing.aatext=true --laf Gtk"

NetBeans Platform apps

If you want the same for your NetBeans Platform application add to project (suite) project.properties file this line:

run.args.extra=--laf Nimbus

Reason #1: Price and legality

• Always and forever free
• Copy, distribute, share as you want

Reason #2: Perfection of basis

• Robustness, stability – features that made Linux famous
• Speed – 10 seconds to login screen, ready to work immediately after pressing “Sign in”, installation takes not more than 15 minutes
• Tab support of Nautilus (file and folder explorer)
• Seamless remote folder working
• True and complete uninstall – you system never get clutter
• Unified updating of installed application

Reason #3: Everything already included

Count yourself how much time you spend with installing what is in Ubuntu already included in 700 MB installation CD.

• Out-of-box printing to PDF
• PDF viewer
• LibreOffice office package (formerly OpenOffice)
• Zip/unzipper
• Bittorrent client
• screenshot taking

Reason #4: Everybody’s friend

• playing well with rest of world
• support plenty of hardware – typically sound, network, wifi, bluetooth works out of the box
• printing on Windows shared printer
• every existing filesystem support

Reason #5: Thinking of you

• Resume from last position during playback
• Always-on-top everywhere.
• Multiple screens
• Playing any format – “Whoops I don’t have this codec, should I download it?”
• Thumbnails of everything – images, movies, PDFs, text and HTML files
• Audio is played just with placing mouse over it.

Reason #6: Accessibility

• Super zooming with Super (aka Windows key) + mouse wheel.
• Chaning color of mouse cursor to white or black according to background to be still visible.
• Different sets of icons for visual impaired users

Select

Basic select:
select e from Holiday e

Select everything never than:
select e from Holiday e where e.date > {d '2020-05-15'}

Select everything between dates:
select e from Holiday e where e.date between {d '2020-05-15'} and {d '2020-05-18'}

Select exact date or time:
select e from Holiday e where e.date like {d '2011-01-01'}

Parametrized queries

Numbered paramaters:

EM.createQuery("select h from Holiday h where h.date = ?1", Holiday.class)
   .setParameter(1, new GregorianCalendar(2011, 0, 3).getTime())
   .getSingleResult();

Setting on JTable:

jtable.setColumnSelectionAllowed(false);
jtable.setRowSelectionAllowed(true);
jtable.setCellSelectionAllowed(true);

is not equivalent to disable any selection. My despair of lacking this quite imporant feature of JTable was ended by the idea of Brian Cole posted at one forum thread at CodeRanch.

class NullSelectionModel implements ListSelectionModel {
    @Override
    public boolean isSelectionEmpty() { return true; }
    @Override
    public boolean isSelectedIndex(int index) { return false; }
    @Override
    public int getMinSelectionIndex() { return -1; }
    @Override
    public int getMaxSelectionIndex() { return -1; }
    @Override
    public int getLeadSelectionIndex() { return -1; }
    @Override
    public int getAnchorSelectionIndex() { return -1; }
    @Override
    public void setSelectionInterval(int index0, int index1) { }
    @Override
    public void setLeadSelectionIndex(int index) { }
    @Override
    public void setAnchorSelectionIndex(int index) { }
    @Override
    public void addSelectionInterval(int index0, int index1) { }
    @Override
    public void insertIndexInterval(int index, int length, boolean before) { }
    @Override
    public void clearSelection() { }
    @Override
    public void removeSelectionInterval(int index0, int index1) { }
    @Override
    public void removeIndexInterval(int index0, int index1) { }
    @Override
    public void setSelectionMode(int selectionMode) { }
    @Override
    public int getSelectionMode() { return SINGLE_SELECTION; }
    @Override
    public void addListSelectionListener(ListSelectionListener lsl) { }
    @Override
    public void removeListSelectionListener(ListSelectionListener lsl) { }
    @Override
    public void setValueIsAdjusting(boolean valueIsAdjusting) { }
    @Override
    public boolean getValueIsAdjusting() { return false; }
}

Overview

This is not introduction for absolute beginners. Please refer to books or tutorials on this topic. Firstly, I would like to summary terms and relationships among them.

Persistence Unit

A persistence unit is a logical grouping that includes:

• Entity manager factory and its entity managers + their configuration information
• Set of entity classes
• Mapping metadata (annotations or XML file) that specifies mapping of the classes to the database.

PU is represented by persistence.xml file in META-INF folder of JAR file or application.

Example of persistence.xml

Here I present typical example of peristence.xml file using Eclipselink and MySQL as a backend datastore.

You can see name of persistence unit, type of transaction, list of entity classes, connection setting, and Eclipselink provider-specific properties.

 
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="com.virtage.plexflow" transaction-type="RESOURCE_LOCAL">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <class>com.virtage.plexflow.Document</class>
    <class>com.virtage.plexflow.WorkflowRule</class>
    <class>com.virtage.plexflow.DocumentProperties</class>
    <properties>
        <property name="eclipselink.logging.level" value="FINE"/>
        <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
        <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost/plexflow_trunk"/>
        <property name="javax.persistence.jdbc.user" value="plexflow_trunk"/>
        <property name="javax.persistence.jdbc.password" value="very_strong_password"/>
        <property name="eclipselink.logging.level" value="INFO"/>
    </properties>
  </persistence-unit>
</persistence>

Persistence Context

Definition found in JPA specification chapter 7.1:
A persistence context is a set of managed entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed by the entity manager.

In JEE environment we persistence context is always managed automatically and is propagated with JTA transaction.

• transaction scoped persistence context – lifetime of transaction is scoped to a single transaction. After transaction completes (TO CONFIRM no matter how whether with success or failure), persistence contexts die.
• extended persistence context – extended lifetime that can spans multiple transactions

In JSE environment exists only application-managed persistence contexts (because we have only application-managed entity managers) we always create a new isolated extended persistence context. Lifecycle is managed by EntityManager.close() method that closes entity manager to release its persistence context and other resources.

Type of persistence context is depending on the PersistenceContextType specified when its entity manager is created.

Persistence contexts are always associated with an entity manager factory. Entity manager instances obtained from different entity manager factories never share the same persistence context.

TO ASK V JSE je jen transaction-scoped PC? Je to tak? Jelikož v JPA spec (7.6.2 a 7.6.3) je jen container-managed transaction-scoped a extended PC.

In JSE we recognize these PCs: (JPA 7.7)

(JPA spec 7.6:)

• Container-managed persistence contexts (JPA 7.6) – When a container-managed entity manager is used, the lifecycle of the persistence context is always managed automatically, transparently to the application, and the persistence context is propagated with the JTA transaction.

A container-managed persistence context may be defined to have either a lifetime that is scoped to a single transaction or an extended lifetime that spans multiple transactions, depending on the PersistenceContextType that is specified when its entity manager is created. This specification refers to such persistence contexts as transaction-scoped persistence contexts and extended persistence contexts respectively.

Entity Manager

There are, generally speaking, two main kinds of entity managers:

• container-managed: Entity Manager may only be obtained from JEE container (application container or server that supports JPA SPI)
  • transaction-scoped container-managed
  • extended container-managed
• application-managed (or also non-managed): Second option for JEE, only option for JSE environment. Application must manually manage EntityManager instance lifecycle with close() method.

EntityManager interface defines methods to interact with associated persistence context – to create and remove entitites, to find entitites, and to query over entitities.

Obtaining an EntityManager

Entity manager for a persistence context is always obtained from an entity manager factory. Altough in JSE environment, application has to obtain it directly from from EntityManagerFactory class (which is in turn obtained from Persitence root class).

import javax.persistence.*;
...
EntityManagerFactory emf = Persistence
	 .createEntityManagerFactory("PetShop");
EntityManager em = emf.createEntityManager();
...
em.close();

If you don’t need EM anymore, it’s advisable to close() it. Closing should be performed before closing parent EMF.

em.close();
emf.close();

Thread safety

Entity manager is not thread-safe and must be accessed in single-thread manner. [Z toho vyplývá] also persistence contexts are not required to be thread-safe.

Unlike entity manager, entity manager factory is thread-safe.

Common entity manager methods

The persist, merge, remove, and refresh methods must be invoked within a transaction. If there is no transaction context, the javax.persistence.TransactionRequiredException is thrown.

persist()

Requirements:

• Must be called in transaction, otherwise ??? is thrown.

merge()

Requirements:

• Must be called in transaction, otherwise ??? is thrown.

remove()

Requirements:

• Must be called in transaction, otherwise ??? is thrown.

lock()

Requirements:

• Entity must be managed otherwise IllegalArgumentException is thrown.

find()

contains()

Locking

Locking is essential feature to avoid collisions resulting from simultaneous updates to the same data by concurrent users. JPA support two types of locking:

• optimistic locking – The most common type of locking. Lock on object is placed on transaction commit. Every object that has to be updated or deleted is checked and exception is thrown when JPA detects that there is newer version of this object.
• pesimistic locking – When need to know whether collision can occur earlier then on commit, use persimistic locking. This kind of locking locks object immediately when they are used in transaction.

Optimitic locking should be prefered as it is easier to use and more efficient. The transaction will fail with OptimisticLockException on commit (or flush) operation if JPA detects that version field of being updated object is different from version is datastore (i.e. object has been already chaged by another user).

In most JPA providers you will need to add field annotated with @Version to entity class. Although your JPA provider don’t force you to do this, it still make sence to expose version because your application can for example write version value to log on failure.

@Entity
public class MyEntity {
   ..
   @Version long version;
   ...
}

Also, if you do this, you should never allow modification of this field (never provide setter method).

Specifing locking mode

Enum javax.persistence.LockModeType is used to specify locking mode in methods that takes locks (lock, find, or refresh) or to the Query.setLockMode() or TypedQuery.setLockMode() methods.

Optimistic locking:

• OPTIMISTIC (formerly READ in JPA 1.0) – perform a version check on locked Entity before commit, throw an OptimisticLockException if Entity version mismatch.
• OPTIMISTIC_FORCE_INCREMENT (formerly WRITE in JPA 1.0) – same but force an increment to the version at the end of the transaction, even if the entity is not modified.

Pesimistic locking:

• LockModeType.PESIMISTIC – lock the database row when reading
• LockModeType.PESIMISTIC_FOR_INCREMENT – same but force an increment to the version at the end of the transaction, even if the entity is not modified.
• LockModeType.PESIMISTIC_READ
• LockModeType.PESIMISTIC_WRITE

Entity Manager Factory

Persistence unit have just one entity manager factory. Instance of EntityManagerFactory interface is used to create application-managed entity managers. Each EMF provides identically configured EM instances (connecting to the same database, same user and password etc.).

Obtaining an Entity Manager Factory

javax.persistence.Persistence class is the bootstrap class that provides access to an entity manager factory.

EntityManagerFactory emf =
javax.persistence.Persistence.createEntityManagerFactory("Order");
EntityManager em = emf.createEntityManager();

At the end of lifetime of aplication, obtainted EMF should be closed with close() method. Closing EMF causes all its EM to move into the closed state also. This is not same as closing EM! There is still requirement to EM.close() before closing EMF.

em.close();
emf.close();

Transactions

JPA supports two different kinds of transactions.

• JTA transactions – typically used when runnin in JEE container. They are started and commited using usual container techniques (UserTransaction API, or transaction demarcation in EJB or Spring).
• resource local transaction – in JSE or non-managed mode in JEE. You, as developer, must manage transaction manually by calling EntityTransaction instance methods begin(), commit() and rollback().

Transaction and Entity Manager

You can’t choose transaction type. EntityTransaction instance obtainted from EntityManager getTransaction() method has type defined according to underlying entity manager factory (i.e. specified in persistence.xml). See sections 8.2.1.2 and 9.1 in JPA specification.

EntityTransaction methods

begin()

Start a resource transaction.

Throws IllegalStateException if isActive() is true (i.e. there is already active transaction).

commit()

Commit the current resource transaction, writing any unflushed changes to the database.

Throws ‘IllegalStateException’ if isActive() is false.
Throws ‘RollbackException’ if the commit fails.

If the EntityTransaction.commit operation fails, the persistence provider must roll back the transaction.

Managed entities of transaction-scoped PC become detached when the trasaction commits; the managed entities of an extended PC remain managed.

If the commit fails, then the managed objects are considered detached, and the EntityManager is cleared. This means that commit failures cannot be caught and retried, if a failure occurs, the entire transaction must be performed again.

rollback()

Roll back the current active resource transaction.

Throws ‘IllegalStateException’ if isActive() is false.
Throws ‘PersistenceException’ if an unexpected error condition is encountered.

When a resource-local entity manager is used, and the persistence provider runtime throws an exception defined to cause transaction rollback, the persistence provider must mark the transaction for rollback.
setRollbackOnly() and getRollbackOnly()

Mark the current resource transaction so that the only possible outcome of the transaction is for the transaction to be rolled back.

Throws IllegalStateException if isActive() is false

Important note: Transactions in JPA are always at the object level, this means that all changes made to all persistent objects in the persistence context are part of the transaction.

There is 1:1 relationship between EntityManager and transaction so is common to see this code pattern

em.getTransaction().begin()
// something
em.getTransaction().commit()

instead of

EntityTransaction tx = em.getTransaction();
tx.begin();
// something
tx.commit()

because will always get same EntityTransaction instance. Also if you need more transactions, you have to get more entity managers.
Declaring in persistence.xml

transaction-type attribute has value RESOURCE_LOCAL.

Resources

• JPA 2.0 specification aka JSR-317
• Java Persistence wikibook
• JPA 2.0 Concurrency and locking

Because an example is better then thousands of words:

java -jar %HOMEDIR%\CleanForum.jar 1> CleanForum.log 2>&1
   or
someapp 1> CleanForum.log 2>&1

Here I am redirecting stdout 1> to file CleanForum.log. Then stderr stream 2> is asked to output back to the first redirection using ampersand notation.

That is it. If it is a little bit complicated, releax and just use it.

Steps overview

1. Install Derby (= just unpack .tar.gz) somewhere, e.g. /opt/derby.
   Create directory where files conprising database will reside, e.g. /var/derby-dbs.
2. Create derby.properties configuration file here.
3. Derby will create here also log file derby.log
4. Start Derby Network Server with

$ sudo java -Dderby.system.home=/var/derby-dbs -jar $DERBY_HOME/lib/derbyrun.jar server start

Please notice derby.system.home property cannot be placed in derby.properties file. It has to be known to Derby in start time, not later.

Example derby.properties file

If you are in hurry, here is example derby.properties file. For more details are tips continue bellow please.

# Accept connections outside of localhost
derby.drda.host=10.0.0.40
# Change default port 1527
#derby.drda.portNumber=1527
# Log connections
derby.drda.logConnections=true
 
# Authentication and users
derby.database.defaultConnectionMode=noAccess
derby.connection.requireAuthentication=true
derby.authentication.provider=BUILTIN
derby.user.sa=veryStrongPassword
derby.user.readonly=readonly
derby.database.fullAccessUsers=sa
derby.database.readOnlyAccessUsers=readonly

Enable network connections from remote hosts

Default configuration disallow us to connect to Derby server outside of localhost. You have to specify network adapter on which Derby should listen using property derby.drda.host.

# Specify your server IP address
derby.drda.host=192.168.10.95
# Or use special value 0.0.0.0 to listen on every NICs
derby.drda.host=0.0.0.0

Shutting down database or server

Because of nature of Derby shutting down is little complicated. You have a many ways to the the same thing – correctly shutdown database or server.

Using JDBC connection string

Shut down entire system:
jdbc:derby:;shutdown=true

Shut down salesDB (authentication not enabled):
jdbc:derby:salesDB;shutdown=true

Shut down using Network Server:
jdbc:derby://localhost:1527/mydb;shutdown=true

Using shell script

stopNetworkServer [-h hostname] [-p port] [-user user] [-password pwd]

Using derbyrun.jar

java -jar derbyrun.jar server shutdown [-h hostname] [-p port] [-user user] [-password pwd]

Using Java class

java org.apache.derby.drda.NetworkServerControl shutdown [-h hostname] [-p port] [-user user] [-password pwd]

Start, shutdown and restart helper scripts

You can save a lot of typing if you create three helper scripts to start, shutdown and to restart Derby server. I named it myCommand.sh.

myStartServer.sh:

#!/bin/bash
 
java -Dderby.system.home=/var/derby-dbs -jar \
    /opt/derby/lib/derbyrun.jar server start

myStopServer.sh:

#!/bin/bash
 
java -jar /opt/derby/lib/derbyrun.jar server \
   shutdown -h 10.120.34.25 -p 1527 -user sa -password 12356

myRestartServer.sh:

#!/bin/bash
 
./myStopServer.sh
./myStartServer.sh

And don’t forget make scripts executable:

$ chmod +x my*.sh

How to shutdown broken zoombie Derby

Sometimes Derby cannot be stopped gracefully with shutdown method. In such case you have to kill it manually. I should be always used with care because you can lose data cached in memory or database can become unconsistent.

Find process id (PID) of Derby

$ ps aux | grep java

You you get output similar to this:

root     27304  4.6  2.6 411172 27504 pts/0    Sl   09:21   0:01 java -Dderby.system.home=/var/derby-dbs -jar /opt/derby/lib/derbyrun.jar server start
1000     27450  0.0  0.0   3324   804 pts/0    S+   09:21   0:00 grep --color=auto java

First line is your zoombie Derby. We can see that Derby has PID 27304. Second line is command used to identify PID itself. Kill PID 27304 with:

$ sudo kill -kill 27304

Clients cannot connect with “Connection refused” error

For example if you try to shutdown Derby server with

$ ./stopNetworkServer -user sa -password 12356

or with

./stopNetworkServer -h localhost -p 1527 -user sa -password 12356

Or you will try to connect using ij tool or any JDBC client you can encounter error
Fri May 06 10:02:19 CEST 2011 : Could not connect to Derby Network Server on host localhost, port 1527: Connection refused

Suprisied by is connection refused? If you omit -h option, Derby will suppose that you mean localhost. But we previously instruct Derby to listen on NIC with some IP address, not on looback (i.e. localhost).

Auto start with computer

In Ubuntu and Debian place myStartServer.sh to /etc/rc.local file so it will looke like:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
 
# Start Derby Network Server
/opt/derby/bin/myStartServer.sh
 
exit 0