big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
package net.i2p;
|
|
|
|
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
import java.io.File;
|
2011-06-14 19:27:46 +00:00
|
|
|
import java.util.Collections;
|
2004-05-17 03:38:53 +00:00
|
|
|
import java.util.HashSet;
|
|
|
|
import java.util.Properties;
|
2010-12-12 22:09:04 +00:00
|
|
|
import java.util.Random;
|
2004-05-17 03:38:53 +00:00
|
|
|
import java.util.Set;
|
|
|
|
|
|
|
|
import net.i2p.client.naming.NamingService;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
import net.i2p.crypto.AESEngine;
|
|
|
|
import net.i2p.crypto.CryptixAESEngine;
|
|
|
|
import net.i2p.crypto.DSAEngine;
|
2004-06-22 04:23:19 +00:00
|
|
|
import net.i2p.crypto.DummyDSAEngine;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.crypto.DummyElGamalEngine;
|
2010-03-08 00:48:56 +00:00
|
|
|
//import net.i2p.crypto.DummyPooledRandomSource;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.crypto.ElGamalAESEngine;
|
|
|
|
import net.i2p.crypto.ElGamalEngine;
|
2006-09-27 06:00:33 +00:00
|
|
|
import net.i2p.crypto.HMAC256Generator;
|
2006-02-26 21:30:56 +00:00
|
|
|
import net.i2p.crypto.HMACGenerator;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.crypto.KeyGenerator;
|
|
|
|
import net.i2p.crypto.SHA256Generator;
|
|
|
|
import net.i2p.crypto.SessionKeyManager;
|
2009-05-29 10:00:06 +00:00
|
|
|
import net.i2p.crypto.TransientSessionKeyManager;
|
2010-12-12 22:09:04 +00:00
|
|
|
import net.i2p.data.Base64;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.data.RoutingKeyGenerator;
|
2010-12-01 18:57:05 +00:00
|
|
|
import net.i2p.internal.InternalClientManager;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.stat.StatManager;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
import net.i2p.util.Clock;
|
2009-02-25 00:05:30 +00:00
|
|
|
import net.i2p.util.ConcurrentHashSet;
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
import net.i2p.util.FileUtil;
|
2008-07-16 13:42:54 +00:00
|
|
|
import net.i2p.util.FortunaRandomSource;
|
2011-01-03 18:37:29 +00:00
|
|
|
import net.i2p.util.I2PProperties;
|
2009-01-20 17:12:24 +00:00
|
|
|
import net.i2p.util.KeyRing;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.util.LogManager;
|
2010-03-08 00:48:56 +00:00
|
|
|
//import net.i2p.util.PooledRandomSource;
|
2008-07-16 13:42:54 +00:00
|
|
|
import net.i2p.util.RandomSource;
|
2010-07-06 15:22:48 +00:00
|
|
|
import net.i2p.util.SecureDirectory;
|
2011-01-03 18:37:29 +00:00
|
|
|
import net.i2p.util.I2PProperties.I2PPropertyCallback;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* <p>Provide a base scope for accessing singletons that I2P exposes. Rather than
|
|
|
|
* using the traditional singleton, where any component can access the component
|
|
|
|
* in question directly, all of those I2P related singletons are exposed through
|
|
|
|
* a particular I2PAppContext. This helps not only with understanding their use
|
|
|
|
* and the components I2P exposes, but it also allows multiple isolated
|
|
|
|
* environments to operate concurrently within the same JVM - particularly useful
|
|
|
|
* for stubbing out implementations of the rooted components and simulating the
|
|
|
|
* software's interaction between multiple instances.</p>
|
|
|
|
*
|
|
|
|
* As a simplification, there is also a global context - if some component needs
|
|
|
|
* access to one of the singletons but doesn't have its own context from which
|
|
|
|
* to root itself, it binds to the I2PAppContext's globalAppContext(), which is
|
|
|
|
* the first context that was created within the JVM, or a new one if no context
|
|
|
|
* existed already. This functionality is often used within the I2P core for
|
|
|
|
* logging - e.g. <pre>
|
|
|
|
* private static final Log _log = new Log(someClass.class);
|
|
|
|
* </pre>
|
|
|
|
* It is for this reason that applications that care about working with multiple
|
|
|
|
* contexts should build their own context as soon as possible (within the main(..))
|
|
|
|
* so that any referenced components will latch on to that context instead of
|
|
|
|
* instantiating a new one. However, there are situations in which both can be
|
|
|
|
* relevent.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public class I2PAppContext {
|
|
|
|
/** the context that components without explicit root are bound */
|
2011-01-07 00:15:35 +00:00
|
|
|
protected static volatile I2PAppContext _globalAppContext;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
|
2011-01-07 17:09:27 +00:00
|
|
|
protected I2PProperties _overrideProps;
|
2004-04-24 22:29:01 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private StatManager _statManager;
|
|
|
|
private SessionKeyManager _sessionKeyManager;
|
|
|
|
private NamingService _namingService;
|
|
|
|
private ElGamalEngine _elGamalEngine;
|
|
|
|
private ElGamalAESEngine _elGamalAESEngine;
|
|
|
|
private AESEngine _AESEngine;
|
|
|
|
private LogManager _logManager;
|
2006-02-26 21:30:56 +00:00
|
|
|
private HMACGenerator _hmac;
|
2006-09-27 06:00:33 +00:00
|
|
|
private HMAC256Generator _hmac256;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private SHA256Generator _sha;
|
2006-09-27 04:02:13 +00:00
|
|
|
protected Clock _clock; // overridden in RouterContext
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private DSAEngine _dsa;
|
|
|
|
private RoutingKeyGenerator _routingKeyGenerator;
|
|
|
|
private RandomSource _random;
|
|
|
|
private KeyGenerator _keyGenerator;
|
2009-01-20 17:12:24 +00:00
|
|
|
protected KeyRing _keyRing; // overridden in RouterContext
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private volatile boolean _statManagerInitialized;
|
|
|
|
private volatile boolean _sessionKeyManagerInitialized;
|
|
|
|
private volatile boolean _namingServiceInitialized;
|
|
|
|
private volatile boolean _elGamalEngineInitialized;
|
|
|
|
private volatile boolean _elGamalAESEngineInitialized;
|
|
|
|
private volatile boolean _AESEngineInitialized;
|
|
|
|
private volatile boolean _logManagerInitialized;
|
|
|
|
private volatile boolean _hmacInitialized;
|
2006-09-27 06:00:33 +00:00
|
|
|
private volatile boolean _hmac256Initialized;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private volatile boolean _shaInitialized;
|
2006-09-27 04:02:13 +00:00
|
|
|
protected volatile boolean _clockInitialized; // used in RouterContext
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private volatile boolean _dsaInitialized;
|
|
|
|
private volatile boolean _routingKeyGeneratorInitialized;
|
|
|
|
private volatile boolean _randomInitialized;
|
|
|
|
private volatile boolean _keyGeneratorInitialized;
|
2009-01-20 17:12:24 +00:00
|
|
|
protected volatile boolean _keyRingInitialized; // used in RouterContext
|
2011-06-14 19:27:46 +00:00
|
|
|
protected final Set<Runnable> _shutdownTasks;
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
private File _baseDir;
|
|
|
|
private File _configDir;
|
|
|
|
private File _routerDir;
|
|
|
|
private File _pidDir;
|
|
|
|
private File _logDir;
|
|
|
|
private File _appDir;
|
|
|
|
private File _tmpDir;
|
2011-07-28 18:22:31 +00:00
|
|
|
// split up big lock on this to avoid deadlocks
|
|
|
|
private final Object _lock1 = new Object(), _lock2 = new Object(), _lock3 = new Object(), _lock4 = new Object(),
|
|
|
|
_lock5 = new Object(), _lock6 = new Object(), _lock7 = new Object(), _lock8 = new Object(),
|
|
|
|
_lock9 = new Object(), _lock10 = new Object(), _lock11 = new Object(), _lock12 = new Object(),
|
|
|
|
_lock13 = new Object(), _lock14 = new Object(), _lock15 = new Object(), _lock16 = new Object(),
|
|
|
|
_lock17 = new Object();
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
|
|
|
* Pull the default context, creating a new one if necessary, else using
|
|
|
|
* the first one created.
|
|
|
|
*
|
2011-06-17 18:37:02 +00:00
|
|
|
* Warning - do not save the returned value, or the value of any methods below,
|
|
|
|
* in a static field, or you will get the old context if a new router is
|
|
|
|
* started in the same JVM after the first is shut down,
|
|
|
|
* e.g. on Android.
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*/
|
|
|
|
public static I2PAppContext getGlobalContext() {
|
2011-01-07 00:15:35 +00:00
|
|
|
// skip the global lock - _gAC must be volatile
|
|
|
|
// http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
|
2010-11-19 00:40:33 +00:00
|
|
|
I2PAppContext rv = _globalAppContext;
|
|
|
|
if (rv != null)
|
|
|
|
return rv;
|
|
|
|
|
2004-08-01 23:24:47 +00:00
|
|
|
synchronized (I2PAppContext.class) {
|
|
|
|
if (_globalAppContext == null) {
|
|
|
|
_globalAppContext = new I2PAppContext(false, null);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return _globalAppContext;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2010-11-19 00:40:33 +00:00
|
|
|
/**
|
|
|
|
* Pull the default context, WITHOUT creating a new one.
|
|
|
|
* Use this in static methods used early in router initialization,
|
|
|
|
* where creating a context messes things up.
|
|
|
|
*
|
|
|
|
* @return context or null
|
|
|
|
* @since 0.8.2
|
|
|
|
*/
|
|
|
|
public static I2PAppContext getCurrentContext() {
|
|
|
|
return _globalAppContext;
|
|
|
|
}
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
2011-07-08 13:47:49 +00:00
|
|
|
* Create a brand new context.
|
|
|
|
* WARNING: In almost all cases, you should use getGlobalContext() instead,
|
|
|
|
* to avoid creating additional contexts, which may spawn numerous
|
|
|
|
* additional resources and threads, and may be the cause of logging
|
|
|
|
* problems or hard-to-isolate bugs.
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*/
|
|
|
|
public I2PAppContext() {
|
2004-04-24 22:29:01 +00:00
|
|
|
this(true, null);
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2004-04-24 22:29:01 +00:00
|
|
|
/**
|
2011-07-08 13:47:49 +00:00
|
|
|
* Create a brand new context.
|
|
|
|
* WARNING: In almost all cases, you should use getGlobalContext() instead,
|
|
|
|
* to avoid creating additional contexts, which may spawn numerous
|
|
|
|
* additional resources and threads, and may be the cause of logging
|
|
|
|
* problems or hard-to-isolate bugs.
|
2004-04-24 22:29:01 +00:00
|
|
|
*/
|
|
|
|
public I2PAppContext(Properties envProps) {
|
|
|
|
this(true, envProps);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
2011-07-08 13:47:49 +00:00
|
|
|
* Create a brand new context.
|
|
|
|
* WARNING: In almost all cases, you should use getGlobalContext() instead,
|
|
|
|
* to avoid creating additional contexts, which may spawn numerous
|
|
|
|
* additional resources and threads, and may be the cause of logging
|
|
|
|
* problems or hard-to-isolate bugs.
|
|
|
|
*
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
* @param doInit should this context be used as the global one (if necessary)?
|
2011-07-08 13:47:49 +00:00
|
|
|
* Will only apply if there is no global context now.
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*/
|
2004-04-24 22:29:01 +00:00
|
|
|
private I2PAppContext(boolean doInit, Properties envProps) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (doInit) {
|
2004-08-01 23:24:47 +00:00
|
|
|
synchronized (I2PAppContext.class) {
|
2011-06-17 18:37:02 +00:00
|
|
|
if (_globalAppContext == null) {
|
2004-08-01 23:24:47 +00:00
|
|
|
_globalAppContext = this;
|
2011-06-17 18:37:02 +00:00
|
|
|
} else {
|
|
|
|
System.out.println("Warning - New context not replacing old one, you now have a second one");
|
|
|
|
(new Exception("I did it")).printStackTrace();
|
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
}
|
|
|
|
}
|
2011-01-31 15:44:00 +00:00
|
|
|
_overrideProps = new I2PProperties();
|
|
|
|
if (envProps != null)
|
|
|
|
_overrideProps.putAll(envProps);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_statManager = null;
|
|
|
|
_sessionKeyManager = null;
|
|
|
|
_namingService = null;
|
|
|
|
_elGamalEngine = null;
|
|
|
|
_elGamalAESEngine = null;
|
|
|
|
_logManager = null;
|
2009-01-20 17:12:24 +00:00
|
|
|
_keyRing = null;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_statManagerInitialized = false;
|
|
|
|
_sessionKeyManagerInitialized = false;
|
|
|
|
_namingServiceInitialized = false;
|
|
|
|
_elGamalEngineInitialized = false;
|
|
|
|
_elGamalAESEngineInitialized = false;
|
|
|
|
_logManagerInitialized = false;
|
2009-01-20 17:12:24 +00:00
|
|
|
_keyRingInitialized = false;
|
2011-06-17 18:37:02 +00:00
|
|
|
_shutdownTasks = new ConcurrentHashSet(32);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
initializeDirs();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
}
|
|
|
|
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
/**
|
|
|
|
* Directories. These are all set at instantiation and will not be changed by
|
|
|
|
* subsequent property changes.
|
|
|
|
* All properties, if set, should be absolute paths.
|
|
|
|
*
|
|
|
|
* Name Property Method Files
|
|
|
|
* ----- -------- ----- -----
|
|
|
|
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
|
|
|
|
* Temp i2p.dir.temp getTempDir() Temporary files
|
|
|
|
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
|
2009-06-15 15:35:25 +00:00
|
|
|
* PID i2p.dir.pid getPIDDir() router.ping
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
*
|
|
|
|
* (the following all default to the same as Config)
|
|
|
|
*
|
|
|
|
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
|
2009-06-15 15:35:25 +00:00
|
|
|
* Log i2p.dir.log getLogDir() logs/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
* App i2p.dir.app getAppDir() eepsite/, ...
|
|
|
|
*
|
|
|
|
* Note that we can't control where the wrapper puts its files.
|
|
|
|
*
|
|
|
|
* The app dir is where all data files should be. Apps should always read and write files here,
|
|
|
|
* using a constructor such as:
|
|
|
|
*
|
|
|
|
* String path = mypath;
|
|
|
|
* File f = new File(path);
|
|
|
|
* if (!f.isAbsolute())
|
|
|
|
* f = new File(_context.geAppDir(), path);
|
|
|
|
*
|
|
|
|
* and never attempt to access files in the CWD using
|
|
|
|
*
|
|
|
|
* File f = new File("foo");
|
|
|
|
*
|
|
|
|
* An app should assume the CWD is not writable.
|
|
|
|
*
|
|
|
|
* Here in I2PAppContext, all the dirs default to CWD.
|
|
|
|
* However these will be different in RouterContext, as Router.java will set
|
|
|
|
* the properties in the RouterContext constructor.
|
|
|
|
*
|
|
|
|
* Apps should never need to access the base dir, which is the location of the base I2P install.
|
|
|
|
* However this is provided for the router's use, and for backward compatibility should an app
|
|
|
|
* need to look there as well.
|
|
|
|
*
|
|
|
|
* All dirs except the base are created if they don't exist, but the creation will fail silently.
|
2010-08-14 18:22:46 +00:00
|
|
|
* @since 0.7.6
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
*/
|
|
|
|
private void initializeDirs() {
|
|
|
|
String s = getProperty("i2p.dir.base", System.getProperty("user.dir"));
|
|
|
|
_baseDir = new File(s);
|
|
|
|
// config defaults to base
|
|
|
|
s = getProperty("i2p.dir.config");
|
|
|
|
if (s != null) {
|
2010-07-06 15:22:48 +00:00
|
|
|
_configDir = new SecureDirectory(s);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (!_configDir.exists())
|
|
|
|
_configDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_configDir = _baseDir;
|
|
|
|
}
|
|
|
|
// router defaults to config
|
|
|
|
s = getProperty("i2p.dir.router");
|
|
|
|
if (s != null) {
|
2010-07-06 15:22:48 +00:00
|
|
|
_routerDir = new SecureDirectory(s);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (!_routerDir.exists())
|
|
|
|
_routerDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_routerDir = _configDir;
|
|
|
|
}
|
2009-06-13 14:16:12 +00:00
|
|
|
// pid defaults to system temp directory
|
|
|
|
s = getProperty("i2p.dir.pid", System.getProperty("java.io.tmpdir"));
|
|
|
|
_pidDir = new File(s);
|
|
|
|
if (!_pidDir.exists())
|
|
|
|
_pidDir.mkdir();
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
// these all default to router
|
|
|
|
s = getProperty("i2p.dir.log");
|
|
|
|
if (s != null) {
|
2010-07-06 15:22:48 +00:00
|
|
|
_logDir = new SecureDirectory(s);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (!_logDir.exists())
|
|
|
|
_logDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_logDir = _routerDir;
|
|
|
|
}
|
|
|
|
s = getProperty("i2p.dir.app");
|
|
|
|
if (s != null) {
|
2010-07-06 15:22:48 +00:00
|
|
|
_appDir = new SecureDirectory(s);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (!_appDir.exists())
|
|
|
|
_appDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_appDir = _routerDir;
|
|
|
|
}
|
2009-06-15 15:35:25 +00:00
|
|
|
/******
|
2010-11-19 00:40:33 +00:00
|
|
|
(new Exception("Initialized by")).printStackTrace();
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
System.err.println("Base directory: " + _baseDir.getAbsolutePath());
|
|
|
|
System.err.println("Config directory: " + _configDir.getAbsolutePath());
|
|
|
|
System.err.println("Router directory: " + _routerDir.getAbsolutePath());
|
|
|
|
System.err.println("App directory: " + _appDir.getAbsolutePath());
|
|
|
|
System.err.println("Log directory: " + _logDir.getAbsolutePath());
|
|
|
|
System.err.println("PID directory: " + _pidDir.getAbsolutePath());
|
|
|
|
System.err.println("Temp directory: " + getTempDir().getAbsolutePath());
|
2009-06-15 15:35:25 +00:00
|
|
|
******/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
}
|
|
|
|
|
2010-08-14 18:22:46 +00:00
|
|
|
/**
|
|
|
|
* This is the installation dir, often referred to as $I2P.
|
|
|
|
* Applilcations should consider this directory read-only and never
|
|
|
|
* attempt to write to it.
|
|
|
|
* It may actually be read-only on a multi-user installation.
|
|
|
|
* The config files in this directory are templates for user
|
|
|
|
* installations and should not be accessed by applications.
|
|
|
|
* The only thing that may be useful in here is the lib/ dir
|
|
|
|
* containing the .jars.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getBaseDir() { return _baseDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* The base dir for config files.
|
|
|
|
* Applications may use this to access router configuration files if necessary.
|
|
|
|
* Usually ~/.i2p on Linux and %APPDIR%\I2P on Windows.
|
|
|
|
* In installations originally installed with 0.7.5 or earlier, and in
|
|
|
|
* "portable" installations, this will be the same as the base dir.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getConfigDir() { return _configDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Where the router keeps its files.
|
|
|
|
* Applications should not use this.
|
|
|
|
* The same as the config dir for now.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getRouterDir() { return _routerDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Where router.ping goes.
|
|
|
|
* Applications should not use this.
|
|
|
|
* The same as the system temp dir for now.
|
|
|
|
* Which is a problem for multi-user installations.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getPIDDir() { return _pidDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Where the router keeps its log directory.
|
|
|
|
* Applications should not use this.
|
|
|
|
* The same as the config dir for now.
|
|
|
|
* (i.e. ~/.i2p, NOT ~/.i2p/logs)
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getLogDir() { return _logDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Where applications may store data.
|
|
|
|
* The same as the config dir for now, but may change in the future.
|
|
|
|
* Apps should be careful not to overwrite router files.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getAppDir() { return _appDir; }
|
2010-08-14 18:22:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Where anybody may store temporary data.
|
|
|
|
* This is a directory created in the system temp dir on the
|
|
|
|
* first call in this context, and is deleted on JVM exit.
|
|
|
|
* Applications should create their own directory inside this directory
|
|
|
|
* to avoid collisions with other apps.
|
|
|
|
* @since 0.7.6
|
|
|
|
* @return dir constant for the life of the context
|
|
|
|
*/
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
public File getTempDir() {
|
|
|
|
// fixme don't synchronize every time
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock1) {
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (_tmpDir == null) {
|
|
|
|
String d = getProperty("i2p.dir.temp", System.getProperty("java.io.tmpdir"));
|
|
|
|
// our random() probably isn't warmed up yet
|
2010-12-12 22:09:04 +00:00
|
|
|
byte[] rand = new byte[6];
|
|
|
|
(new Random()).nextBytes(rand);
|
|
|
|
String f = "i2p-" + Base64.encode(rand) + ".tmp";
|
2010-07-06 15:22:48 +00:00
|
|
|
_tmpDir = new SecureDirectory(d, f);
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (_tmpDir.exists()) {
|
2010-12-12 22:09:04 +00:00
|
|
|
// good or bad ? loop and try again?
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
} else if (_tmpDir.mkdir()) {
|
|
|
|
_tmpDir.deleteOnExit();
|
|
|
|
} else {
|
|
|
|
System.err.println("Could not create temp dir " + _tmpDir.getAbsolutePath());
|
2010-07-06 15:22:48 +00:00
|
|
|
_tmpDir = new SecureDirectory(_routerDir, "tmp");
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
_tmpDir.mkdir();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return _tmpDir;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** don't rely on deleteOnExit() */
|
|
|
|
public void deleteTempDir() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock1) {
|
Big directory rework.
Eliminate all uses of the current working directory, and
set up multiple directories specified by absolute paths for various uses.
Add a WorkingDir class to create a user config directory and
migrate files to it for new installs.
The directory will be $HOME/.i2p on linux and %APPDIR%\I2P on Windows,
or as specified in the system property -Di2p.dir.config=/path/to/i2pdir
All files except for the base install and temp files will be
in the config directory by default.
Temp files will be in a i2p-xxxxx subdirectory of the system temp directory
specified by the system property java.io.tmpdir.
Convert all file opens in the code to be relative to a specific directory,
as specified in the context. Code and applications should never open
files relative to the current working directory (e.g. new File("foo")).
All files should be accessed in the appropriate context directory,
e.g. new File(_context.getAppDir(), "foo").
The router.config file location may be specified as a system property on the
java command line with -Drouter.configLocation=/path/to/router.config
All directories may be specified as properties in the router.config file.
The migration will copy all files from an existing installation,
except i2psnark/, with the system property -Di2p.dir.migrate=true.
Otherwise it will just set up a new directory with a minimal configuration.
The migration will also create a modified wrapper.config and (on linux only)
a modified i2prouter script, and place them in the config directory.
There are no changes to the installer or the default i2prouter, i2prouter.bat,
i2prouter, wrapper.config, runplain.sh, windows service installer/uninstaller,
etc. in this checkin.
* Directories. These are all set at instantiation and will not be changed by
* subsequent property changes.
* All properties, if set, should be absolute paths.
*
* Name Property Method Files
* ----- -------- ----- -----
* Base i2p.dir.base getBaseDir() lib/, webapps/, docs/, geoip/, licenses/, ...
* Temp i2p.dir.temp getTempDir() Temporary files
* Config i2p.dir.config getConfigDir() *.config, hosts.txt, addressbook/, ...
*
* (the following all default to the same as Config)
*
* Router i2p.dir.router getRouterDir() netDb/, peerProfiles/, router.*, keyBackup/, ...
* Log i2p.dir.log getLogDir() wrapper.log*, logs/
* PID i2p.dir.pid getPIDDir() wrapper *.pid files, router.ping
* App i2p.dir.app getAppDir() eepsite/, ...
*
* Note that we can't control where the wrapper actually puts its files.
All these will be set appropriately in a Router Context.
In an I2P App Context, all except Temp will be the current working directory.
Lightly tested so far, needs much more testing.
2009-06-04 19:14:40 +00:00
|
|
|
if (_tmpDir != null) {
|
|
|
|
FileUtil.rmdir(_tmpDir, false);
|
|
|
|
_tmpDir = null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
2004-04-24 22:29:01 +00:00
|
|
|
* Access the configuration attributes of this context, using properties
|
|
|
|
* provided during the context construction, or falling back on
|
|
|
|
* System.getProperty if no properties were provided during construction
|
|
|
|
* (or the specified prop wasn't included).
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
public String getProperty(String propName) {
|
2004-04-24 22:29:01 +00:00
|
|
|
if (_overrideProps != null) {
|
|
|
|
if (_overrideProps.containsKey(propName))
|
|
|
|
return _overrideProps.getProperty(propName);
|
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return System.getProperty(propName);
|
|
|
|
}
|
2004-04-24 22:29:01 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
2004-04-24 22:29:01 +00:00
|
|
|
* Access the configuration attributes of this context, using properties
|
|
|
|
* provided during the context construction, or falling back on
|
|
|
|
* System.getProperty if no properties were provided during construction
|
|
|
|
* (or the specified prop wasn't included).
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
public String getProperty(String propName, String defaultValue) {
|
2004-04-24 22:29:01 +00:00
|
|
|
if (_overrideProps != null) {
|
|
|
|
if (_overrideProps.containsKey(propName))
|
|
|
|
return _overrideProps.getProperty(propName, defaultValue);
|
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return System.getProperty(propName, defaultValue);
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2008-12-10 16:32:26 +00:00
|
|
|
/**
|
|
|
|
* Return an int with an int default
|
|
|
|
*/
|
|
|
|
public int getProperty(String propName, int defaultVal) {
|
|
|
|
String val = null;
|
|
|
|
if (_overrideProps != null) {
|
|
|
|
val = _overrideProps.getProperty(propName);
|
|
|
|
if (val == null)
|
|
|
|
val = System.getProperty(propName);
|
|
|
|
}
|
|
|
|
int ival = defaultVal;
|
|
|
|
if (val != null) {
|
|
|
|
try {
|
|
|
|
ival = Integer.parseInt(val);
|
|
|
|
} catch (NumberFormatException nfe) {}
|
|
|
|
}
|
|
|
|
return ival;
|
|
|
|
}
|
|
|
|
|
2010-03-02 22:52:26 +00:00
|
|
|
/**
|
|
|
|
* Return a boolean with a boolean default
|
|
|
|
* @since 0.7.12
|
|
|
|
*/
|
|
|
|
public boolean getProperty(String propName, boolean defaultVal) {
|
|
|
|
String val = getProperty(propName);
|
|
|
|
if (val == null)
|
|
|
|
return defaultVal;
|
|
|
|
return Boolean.valueOf(val).booleanValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Default false
|
|
|
|
* @since 0.7.12
|
|
|
|
*/
|
|
|
|
public boolean getBooleanProperty(String propName) {
|
|
|
|
return Boolean.valueOf(getProperty(propName)).booleanValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @since 0.7.12
|
|
|
|
*/
|
|
|
|
public boolean getBooleanPropertyDefaultTrue(String propName) {
|
|
|
|
return getProperty(propName, true);
|
|
|
|
}
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
2004-04-24 22:29:01 +00:00
|
|
|
* Access the configuration attributes of this context, listing the properties
|
|
|
|
* provided during the context construction, as well as the ones included in
|
|
|
|
* System.getProperties.
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*
|
2011-01-07 00:15:35 +00:00
|
|
|
* WARNING - not overridden in RouterContext, doesn't contain router config settings,
|
|
|
|
* use getProperties() instead.
|
|
|
|
*
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
* @return set of Strings containing the names of defined system properties
|
|
|
|
*/
|
|
|
|
public Set getPropertyNames() {
|
2004-04-24 22:29:01 +00:00
|
|
|
Set names = new HashSet(System.getProperties().keySet());
|
|
|
|
if (_overrideProps != null)
|
|
|
|
names.addAll(_overrideProps.keySet());
|
|
|
|
return names;
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
}
|
|
|
|
|
2011-01-03 14:26:22 +00:00
|
|
|
/**
|
|
|
|
* Access the configuration attributes of this context, listing the properties
|
|
|
|
* provided during the context construction, as well as the ones included in
|
|
|
|
* System.getProperties.
|
|
|
|
*
|
|
|
|
* @return new Properties with system and context properties
|
|
|
|
* @since 0.8.4
|
|
|
|
*/
|
|
|
|
public Properties getProperties() {
|
|
|
|
Properties rv = new Properties();
|
|
|
|
rv.putAll(System.getProperties());
|
|
|
|
rv.putAll(_overrideProps);
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
2011-01-03 18:37:29 +00:00
|
|
|
/**
|
|
|
|
* Add a callback, which will fire upon changes in the property
|
|
|
|
* given in the specific callback.
|
2011-01-07 17:09:27 +00:00
|
|
|
* Unimplemented in I2PAppContext: this only makes sense in a router context.
|
2011-01-03 18:37:29 +00:00
|
|
|
* @param callback The implementation of the callback.
|
|
|
|
*/
|
2011-01-07 17:09:27 +00:00
|
|
|
public void addPropertyCallback(I2PPropertyCallback callback) {}
|
2011-01-03 18:37:29 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
|
|
|
* The statistics component with which we can track various events
|
|
|
|
* over time.
|
|
|
|
*/
|
|
|
|
public StatManager statManager() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_statManagerInitialized)
|
|
|
|
initializeStatManager();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _statManager;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeStatManager() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock2) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_statManager == null)
|
|
|
|
_statManager = new StatManager(this);
|
|
|
|
_statManagerInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The session key manager which coordinates the sessionKey / sessionTag
|
|
|
|
* data. This component allows transparent operation of the
|
|
|
|
* ElGamal/AES+SessionTag algorithm, and contains all of the session tags
|
2009-08-30 16:04:28 +00:00
|
|
|
* for one particular application.
|
|
|
|
*
|
|
|
|
* This is deprecated for client use, it should be used only by the router
|
|
|
|
* as its own key manager. Not that clients are doing end-to-end crypto anyway.
|
|
|
|
*
|
|
|
|
* For client crypto within the router,
|
|
|
|
* use RouterContext.clientManager.getClientSessionKeyManager(dest)
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
public SessionKeyManager sessionKeyManager() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_sessionKeyManagerInitialized)
|
|
|
|
initializeSessionKeyManager();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _sessionKeyManager;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeSessionKeyManager() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock3) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_sessionKeyManager == null)
|
2009-05-29 10:00:06 +00:00
|
|
|
//_sessionKeyManager = new PersistentSessionKeyManager(this);
|
|
|
|
_sessionKeyManager = new TransientSessionKeyManager(this);
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_sessionKeyManagerInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Pull up the naming service used in this context. The naming service itself
|
|
|
|
* works by querying the context's properties, so those props should be
|
|
|
|
* specified to customize the naming service exposed.
|
|
|
|
*/
|
|
|
|
public NamingService namingService() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_namingServiceInitialized)
|
|
|
|
initializeNamingService();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _namingService;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeNamingService() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock4) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_namingService == null) {
|
|
|
|
_namingService = NamingService.createInstance(this);
|
|
|
|
}
|
|
|
|
_namingServiceInitialized = true;
|
|
|
|
}
|
2005-09-18 22:36:10 +00:00
|
|
|
}
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
|
|
|
* This is the ElGamal engine used within this context. While it doesn't
|
|
|
|
* really have anything substantial that is context specific (the algorithm
|
|
|
|
* just does the algorithm), it does transparently use the context for logging
|
|
|
|
* its performance and activity. In addition, the engine can be swapped with
|
|
|
|
* the context's properties (though only someone really crazy should mess with
|
|
|
|
* it ;)
|
|
|
|
*/
|
|
|
|
public ElGamalEngine elGamalEngine() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_elGamalEngineInitialized)
|
|
|
|
initializeElGamalEngine();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _elGamalEngine;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeElGamalEngine() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock5) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_elGamalEngine == null) {
|
|
|
|
if ("off".equals(getProperty("i2p.encryption", "on")))
|
|
|
|
_elGamalEngine = new DummyElGamalEngine(this);
|
|
|
|
else
|
|
|
|
_elGamalEngine = new ElGamalEngine(this);
|
|
|
|
}
|
|
|
|
_elGamalEngineInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Access the ElGamal/AES+SessionTag engine for this context. The algorithm
|
|
|
|
* makes use of the context's sessionKeyManager to coordinate transparent
|
|
|
|
* access to the sessionKeys and sessionTags, as well as the context's elGamal
|
|
|
|
* engine (which in turn keeps stats, etc).
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public ElGamalAESEngine elGamalAESEngine() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_elGamalAESEngineInitialized)
|
|
|
|
initializeElGamalAESEngine();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _elGamalAESEngine;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeElGamalAESEngine() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock6) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_elGamalAESEngine == null)
|
|
|
|
_elGamalAESEngine = new ElGamalAESEngine(this);
|
|
|
|
_elGamalAESEngineInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Ok, I'll admit it. there is no good reason for having a context specific
|
|
|
|
* AES engine. We dont really keep stats on it, since its just too fast to
|
|
|
|
* matter. Though for the crazy people out there, we do expose a way to
|
|
|
|
* disable it.
|
|
|
|
*/
|
2004-09-28 20:33:23 +00:00
|
|
|
public AESEngine aes() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_AESEngineInitialized)
|
|
|
|
initializeAESEngine();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _AESEngine;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeAESEngine() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock7) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_AESEngine == null) {
|
|
|
|
if ("off".equals(getProperty("i2p.encryption", "on")))
|
|
|
|
_AESEngine = new AESEngine(this);
|
|
|
|
else
|
|
|
|
_AESEngine = new CryptixAESEngine(this);
|
|
|
|
}
|
|
|
|
_AESEngineInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Query the log manager for this context, which may in turn have its own
|
|
|
|
* set of configuration settings (loaded from the context's properties).
|
|
|
|
* Each context's logManager keeps its own isolated set of Log instances with
|
|
|
|
* their own log levels, output locations, and rotation configuration.
|
|
|
|
*/
|
|
|
|
public LogManager logManager() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_logManagerInitialized)
|
|
|
|
initializeLogManager();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _logManager;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeLogManager() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock8) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_logManager == null)
|
|
|
|
_logManager = new LogManager(this);
|
|
|
|
_logManagerInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
|
|
|
* There is absolutely no good reason to make this context specific,
|
|
|
|
* other than for consistency, and perhaps later we'll want to
|
|
|
|
* include some stats.
|
|
|
|
*/
|
2006-02-26 21:30:56 +00:00
|
|
|
public HMACGenerator hmac() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_hmacInitialized)
|
|
|
|
initializeHMAC();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _hmac;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeHMAC() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock9) {
|
2005-07-04 20:44:17 +00:00
|
|
|
if (_hmac == null) {
|
2006-02-26 21:30:56 +00:00
|
|
|
_hmac= new HMACGenerator(this);
|
2005-07-04 20:44:17 +00:00
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_hmacInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
2006-09-27 06:00:33 +00:00
|
|
|
|
2011-06-02 13:30:33 +00:00
|
|
|
/** @deprecated used only by syndie */
|
2006-09-27 06:00:33 +00:00
|
|
|
public HMAC256Generator hmac256() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_hmac256Initialized)
|
|
|
|
initializeHMAC256();
|
2006-09-27 06:00:33 +00:00
|
|
|
return _hmac256;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2011-06-02 13:30:33 +00:00
|
|
|
/** @deprecated used only by syndie */
|
2006-09-27 06:00:33 +00:00
|
|
|
private void initializeHMAC256() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock10) {
|
2006-09-27 06:00:33 +00:00
|
|
|
if (_hmac256 == null) {
|
|
|
|
_hmac256 = new HMAC256Generator(this);
|
|
|
|
}
|
|
|
|
_hmac256Initialized = true;
|
|
|
|
}
|
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Our SHA256 instance (see the hmac discussion for why its context specific)
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public SHA256Generator sha() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_shaInitialized)
|
|
|
|
initializeSHA();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _sha;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeSHA() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock11) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_sha == null)
|
|
|
|
_sha= new SHA256Generator(this);
|
|
|
|
_shaInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Our DSA engine (see HMAC and SHA above)
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public DSAEngine dsa() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_dsaInitialized)
|
|
|
|
initializeDSA();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _dsa;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeDSA() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock12) {
|
2004-06-22 04:23:19 +00:00
|
|
|
if (_dsa == null) {
|
|
|
|
if ("off".equals(getProperty("i2p.encryption", "on")))
|
|
|
|
_dsa = new DummyDSAEngine(this);
|
|
|
|
else
|
|
|
|
_dsa = new DSAEngine(this);
|
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_dsaInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Component to generate ElGamal, DSA, and Session keys. For why it is in
|
|
|
|
* the appContext, see the DSA, HMAC, and SHA comments above.
|
|
|
|
*/
|
|
|
|
public KeyGenerator keyGenerator() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_keyGeneratorInitialized)
|
|
|
|
initializeKeyGenerator();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _keyGenerator;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeKeyGenerator() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock13) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_keyGenerator == null)
|
|
|
|
_keyGenerator = new KeyGenerator(this);
|
|
|
|
_keyGeneratorInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The context's synchronized clock, which is kept context specific only to
|
|
|
|
* enable simulators to play with clock skew among different instances.
|
|
|
|
*
|
|
|
|
*/
|
2011-01-19 16:40:48 +00:00
|
|
|
public Clock clock() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_clockInitialized)
|
|
|
|
initializeClock();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _clock;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2006-09-27 04:02:13 +00:00
|
|
|
protected void initializeClock() { // overridden in RouterContext
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock14) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_clock == null)
|
|
|
|
_clock = new Clock(this);
|
|
|
|
_clockInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Determine how much do we want to mess with the keys to turn them
|
|
|
|
* into something we can route. This is context specific because we
|
|
|
|
* may want to test out how things react when peers don't agree on
|
|
|
|
* how to skew.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public RoutingKeyGenerator routingKeyGenerator() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_routingKeyGeneratorInitialized)
|
|
|
|
initializeRoutingKeyGenerator();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _routingKeyGenerator;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeRoutingKeyGenerator() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock15) {
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
if (_routingKeyGenerator == null)
|
|
|
|
_routingKeyGenerator = new RoutingKeyGenerator(this);
|
|
|
|
_routingKeyGeneratorInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-20 17:12:24 +00:00
|
|
|
/**
|
|
|
|
* Basic hash map
|
|
|
|
*/
|
|
|
|
public KeyRing keyRing() {
|
|
|
|
if (!_keyRingInitialized)
|
|
|
|
initializeKeyRing();
|
|
|
|
return _keyRing;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected void initializeKeyRing() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock16) {
|
2009-01-20 17:12:24 +00:00
|
|
|
if (_keyRing == null)
|
|
|
|
_keyRing = new KeyRing();
|
|
|
|
_keyRingInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
/**
|
|
|
|
* [insert snarky comment here]
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public RandomSource random() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_randomInitialized)
|
|
|
|
initializeRandom();
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
return _random;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
private void initializeRandom() {
|
2011-07-28 18:22:31 +00:00
|
|
|
synchronized (_lock17) {
|
2005-07-04 20:44:17 +00:00
|
|
|
if (_random == null) {
|
2010-03-08 00:48:56 +00:00
|
|
|
//if (true)
|
2005-10-22 18:06:02 +00:00
|
|
|
_random = new FortunaRandomSource(this);
|
2010-03-08 00:48:56 +00:00
|
|
|
//else if ("true".equals(getProperty("i2p.weakPRNG", "false")))
|
|
|
|
// _random = new DummyPooledRandomSource(this);
|
|
|
|
//else
|
|
|
|
// _random = new PooledRandomSource(this);
|
2005-07-04 20:44:17 +00:00
|
|
|
}
|
big ol' update to strip out the singletons, replacing them with
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
2004-04-24 11:54:35 +00:00
|
|
|
_randomInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
2009-02-25 00:05:30 +00:00
|
|
|
|
2011-06-14 19:27:46 +00:00
|
|
|
/**
|
|
|
|
* WARNING - Shutdown tasks are not executed in an I2PAppContext.
|
|
|
|
* You must be in a RouterContext for the tasks to be executed
|
|
|
|
* at shutdown.
|
|
|
|
* This method moved from Router in 0.7.1 so that clients
|
|
|
|
* may use it without depending on router.jar.
|
|
|
|
* @since 0.7.1
|
|
|
|
*/
|
2009-02-25 00:05:30 +00:00
|
|
|
public void addShutdownTask(Runnable task) {
|
|
|
|
_shutdownTasks.add(task);
|
|
|
|
}
|
|
|
|
|
2011-06-14 19:27:46 +00:00
|
|
|
/**
|
|
|
|
* @return an unmodifiable Set
|
|
|
|
* @since 0.7.1
|
|
|
|
*/
|
2009-02-25 00:05:30 +00:00
|
|
|
public Set<Runnable> getShutdownTasks() {
|
2011-06-14 19:27:46 +00:00
|
|
|
return Collections.unmodifiableSet(_shutdownTasks);
|
2009-02-25 00:05:30 +00:00
|
|
|
}
|
|
|
|
|
2009-12-19 16:37:44 +00:00
|
|
|
/**
|
|
|
|
* Use this instead of context instanceof RouterContext
|
|
|
|
* @since 0.7.9
|
|
|
|
*/
|
|
|
|
public boolean isRouterContext() {
|
|
|
|
return false;
|
|
|
|
}
|
2010-12-01 18:57:05 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Use this to connect to the router in the same JVM.
|
|
|
|
* @return always null in I2PAppContext, the client manager if in RouterContext
|
|
|
|
* @since 0.8.3
|
|
|
|
*/
|
|
|
|
public InternalClientManager internalClientManager() {
|
|
|
|
return null;
|
|
|
|
}
|
2011-07-03 13:46:29 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is the wrapper present?
|
|
|
|
* @since 0.8.8
|
|
|
|
*/
|
|
|
|
public boolean hasWrapper() {
|
|
|
|
return System.getProperty("wrapper.version") != null;
|
|
|
|
}
|
2005-10-22 18:06:02 +00:00
|
|
|
}
|