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;
|
2004-05-17 03:38:53 +00:00
|
|
|
import java.util.HashSet;
|
|
|
|
import java.util.Properties;
|
|
|
|
import java.util.Set;
|
|
|
|
|
|
|
|
import net.i2p.client.naming.NamingService;
|
2005-09-18 22:36:10 +00:00
|
|
|
import net.i2p.client.naming.PetNameDB;
|
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;
|
2005-07-04 20:44:17 +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;
|
2004-05-17 03:38:53 +00:00
|
|
|
import net.i2p.data.RoutingKeyGenerator;
|
|
|
|
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;
|
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;
|
2005-04-24 18:42:02 +00:00
|
|
|
import net.i2p.util.PooledRandomSource;
|
2008-07-16 13:42:54 +00:00
|
|
|
import net.i2p.util.RandomSource;
|
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 */
|
|
|
|
protected static I2PAppContext _globalAppContext;
|
|
|
|
|
2004-04-24 22:29:01 +00:00
|
|
|
private Properties _overrideProps;
|
|
|
|
|
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;
|
2005-09-18 22:36:10 +00:00
|
|
|
private PetNameDB _petnameDb;
|
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 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;
|
2005-09-18 22:36:10 +00:00
|
|
|
private volatile boolean _petnameDbInitialized;
|
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 _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
|
2009-02-25 00:05:30 +00:00
|
|
|
private 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;
|
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
|
|
|
/**
|
|
|
|
* Pull the default context, creating a new one if necessary, else using
|
|
|
|
* the first one created.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
public static I2PAppContext getGlobalContext() {
|
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
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Lets root a brand new context
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Lets root a brand new context
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
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
|
|
|
/**
|
|
|
|
* @param doInit should this context be used as the global one (if necessary)?
|
|
|
|
*/
|
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) {
|
|
|
|
if (_globalAppContext == null)
|
|
|
|
_globalAppContext = 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
|
|
|
}
|
|
|
|
}
|
2004-04-24 22:29:01 +00:00
|
|
|
_overrideProps = 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;
|
2005-09-18 22:36:10 +00:00
|
|
|
_petnameDb = 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
|
|
|
_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;
|
2009-02-25 00:05:30 +00:00
|
|
|
_shutdownTasks = new ConcurrentHashSet(0);
|
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.
|
|
|
|
*/
|
|
|
|
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) {
|
|
|
|
_configDir = new File(s);
|
|
|
|
if (!_configDir.exists())
|
|
|
|
_configDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_configDir = _baseDir;
|
|
|
|
}
|
|
|
|
// router defaults to config
|
|
|
|
s = getProperty("i2p.dir.router");
|
|
|
|
if (s != null) {
|
|
|
|
_routerDir = new File(s);
|
|
|
|
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) {
|
|
|
|
_logDir = new File(s);
|
|
|
|
if (!_logDir.exists())
|
|
|
|
_logDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_logDir = _routerDir;
|
|
|
|
}
|
|
|
|
s = getProperty("i2p.dir.app");
|
|
|
|
if (s != null) {
|
|
|
|
_appDir = new File(s);
|
|
|
|
if (!_appDir.exists())
|
|
|
|
_appDir.mkdir();
|
|
|
|
} else {
|
|
|
|
_appDir = _routerDir;
|
|
|
|
}
|
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
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
public File getBaseDir() { return _baseDir; }
|
|
|
|
public File getConfigDir() { return _configDir; }
|
|
|
|
public File getRouterDir() { return _routerDir; }
|
|
|
|
public File getPIDDir() { return _pidDir; }
|
|
|
|
public File getLogDir() { return _logDir; }
|
|
|
|
public File getAppDir() { return _appDir; }
|
|
|
|
public File getTempDir() {
|
|
|
|
// fixme don't synchronize every time
|
|
|
|
synchronized (this) {
|
|
|
|
if (_tmpDir == null) {
|
|
|
|
String d = getProperty("i2p.dir.temp", System.getProperty("java.io.tmpdir"));
|
|
|
|
// our random() probably isn't warmed up yet
|
2009-06-15 15:35:25 +00:00
|
|
|
String f = "i2p-" + Math.abs((new java.util.Random()).nextInt()) + ".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 = new File(d, f);
|
|
|
|
if (_tmpDir.exists()) {
|
|
|
|
// good or bad ?
|
|
|
|
} else if (_tmpDir.mkdir()) {
|
|
|
|
_tmpDir.deleteOnExit();
|
|
|
|
} else {
|
|
|
|
System.err.println("Could not create temp dir " + _tmpDir.getAbsolutePath());
|
|
|
|
_tmpDir = new File(_routerDir, "tmp");
|
|
|
|
_tmpDir.mkdir();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return _tmpDir;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** don't rely on deleteOnExit() */
|
|
|
|
public void deleteTempDir() {
|
|
|
|
synchronized (this) {
|
|
|
|
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
|
|
|
*
|
|
|
|
* @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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
if (_namingService == null) {
|
|
|
|
_namingService = NamingService.createInstance(this);
|
|
|
|
}
|
|
|
|
_namingServiceInitialized = true;
|
|
|
|
}
|
2005-09-18 22:36:10 +00:00
|
|
|
}
|
|
|
|
|
2009-11-28 14:37:07 +00:00
|
|
|
/** @deprecated unused */
|
2005-09-18 22:36:10 +00:00
|
|
|
public PetNameDB petnameDb() {
|
2008-11-26 15:56:36 +00:00
|
|
|
if (!_petnameDbInitialized)
|
|
|
|
initializePetnameDb();
|
2005-09-18 22:36:10 +00:00
|
|
|
return _petnameDb;
|
|
|
|
}
|
2008-11-26 15:56:36 +00:00
|
|
|
|
2009-11-28 14:37:07 +00:00
|
|
|
/** @deprecated unused */
|
2005-09-18 22:36:10 +00:00
|
|
|
private void initializePetnameDb() {
|
|
|
|
synchronized (this) {
|
|
|
|
if (_petnameDb == null) {
|
|
|
|
_petnameDb = new PetNameDB();
|
|
|
|
}
|
|
|
|
_petnameDbInitialized = 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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
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
|
|
|
|
|
|
|
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
|
|
|
|
2006-09-27 06:00:33 +00:00
|
|
|
private void initializeHMAC256() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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.
|
|
|
|
*
|
|
|
|
*/
|
2006-09-27 04:02:13 +00:00
|
|
|
public Clock clock() { // overridden in RouterContext
|
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
|
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
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
|
|
|
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() {
|
|
|
|
synchronized (this) {
|
2005-07-04 20:44:17 +00:00
|
|
|
if (_random == null) {
|
2005-10-22 18:06:02 +00:00
|
|
|
if (true)
|
|
|
|
_random = new FortunaRandomSource(this);
|
|
|
|
else if ("true".equals(getProperty("i2p.weakPRNG", "false")))
|
2005-07-04 20:44:17 +00:00
|
|
|
_random = new DummyPooledRandomSource(this);
|
|
|
|
else
|
|
|
|
_random = new PooledRandomSource(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
|
|
|
_randomInitialized = true;
|
|
|
|
}
|
|
|
|
}
|
2009-02-25 00:05:30 +00:00
|
|
|
|
|
|
|
public void addShutdownTask(Runnable task) {
|
|
|
|
_shutdownTasks.add(task);
|
|
|
|
}
|
|
|
|
|
|
|
|
public Set<Runnable> getShutdownTasks() {
|
|
|
|
return new HashSet(_shutdownTasks);
|
|
|
|
}
|
|
|
|
|
2009-12-19 16:37:44 +00:00
|
|
|
/**
|
|
|
|
* Use this instead of context instanceof RouterContext
|
|
|
|
* @since 0.7.9
|
|
|
|
*/
|
|
|
|
public boolean isRouterContext() {
|
|
|
|
return false;
|
|
|
|
}
|
2005-10-22 18:06:02 +00:00
|
|
|
}
|