implementing out-of-console updaters like i2psnark.
- Add new update interfaces in net.i2p.update
- All update implementations moved to routerconsole update/
- Implement an UpdateManager that registers with the RouterContext
- UpdateManager handles multiple types of things to update
(router, plugins, news, ...) and methods of updating (HTTP, ...)
- UpdateManager maintains list of installed, downloaded, and available versions of everything
- Define Updaters that can check for a new version and/or download an item
- Individual Updaters register with the UpdateManager obtained from
I2PAppContext, identifying the type of update item and
update method they can handle.
- Updaters need only core libs, no router.jar or routerconsole access required.
- All checks and updates are initiated via the UpdateManager.
- All status on checks and updates in-progress or completed are
obtained from the UpdateManager. No more use of System properties
to broadcast update state.
- All update and checker tasks are intantiated on demand and threaded;
no more static references left over.
- Split out the Runners and Checkers from the Handlers and make the inheritance more sane.
- No more permanent NewsFetcher thread; run on the SimpleScheduler queue
and thread a checker task only to fetch the news.
- No more static NewsFetcher instance in routerconsole.
All helper methods that are still required are moved to NewsHelper.
The UpdateManager implements the policy for when to check and download.
All requests go through the UpdateManager.
For each update type, there's several parts:
- The xxxUpdateHandler implements the Updater
- The xxxUpdateChecker implements the UpdateTask for checking
- The xxxUpdateRunner implements the UpdateTask for downloading
New and moved classes:
web/ update/
---- -------
new ConsoleUpdateManager.java
new PluginUpdateChecker.java from PluginUpdateChecker
PluginUpdateChecker -> PluginUpdateHandler.java
PluginUpdateHandler.java -> PluginUpdateRunner
new UnsignedUpdateHandler.java
UnsignedUpdateHandler -> UnsignedUpdateRunner.java
new UnsignedUpdateChecker from NewsFetcher
UpdateHandler.java remains
new UpdateHandler.java
new UpdateRunner.java from UpdateHandler
move NewsHandler from NewsFetcher
new NewsFetcher
new NewsTimerTask
new DummyHandler
Initial checkin. Unfinished, untested, unpolished.
- Only stop a plugin before update if it was running
- Don't start a plugin after update if it was disabled
- Disable plugin if it fails version checks at startup
Jetty 6 package.
- Add several jars from the Jetty 6 distribution
- Update jetty.xml
- Add context XML files
- Update WorkingDir to migrate the content XML files
- Update RouterConsoleRunner and LocaleWebAppHandler
- Remove all old Jetty 5.1.15 local mods;
this will break Seedless using a custom Server() constructor
- Update I2PRequestLog to be a mod of NCSARequestLog from 6.1.26
- Put I2PRequestLog in its own jar
- Copy MultiPartRequest and other required classes from Jetty 5.1.15
and add it to susimail, as the replacement MultiPartFilter in
Jetty 6 is difficult to migrate to, and does not support content-type
- Update i2psnark for Jetty 6
- Disable i2psnark RunStandalone, unused and instantiated Jetty 5
- Fix up all webapp build.xml to reference new jars
Not yet working: Plugin/webapp run detection and stopping, eepsite CGI
Not well tested: Plugins, classpaths, webapps
* DataHelper: Speed up eq() (Ticket #437)
* HTTPServer: Strip inbound X-Accept-Encoding header
* netdb.jsp: HTML fixes
* Plugins: Log error when console server not found
* Reseed: Log tweak
The only defecency is that if one is running, that it considers the
entire pliugin to be running. I'm not sure if that is a good thing
or a bad thing, but the other code checks threads that way.
Loading a class would be one of them!
So we do a quick check first, If it bombs out, we delay and try again.
If it bombs after that, then we throw the ClassNotFoundException.
- Always show start button for webapps and plugins
* configclients.jsp, configupdate.jsp:
- Fix submission when entering CR in a text box
* Plugins:
- Stop all plugins at shutdown
- Log tweaks
* WebApps:
- Remove the WAC after stopping it
- Stop a WAC before starting it to prevent dups
- Negative delay means run immediately and inline
- Add methods to test class and run inline,
to propagate errors to the console
- Add javadoc for clients.config format
- Use new methods for plugins
- Check plugin key against all installed plugins
- Reword some error messages
* VersionComparator: add '-' and '_' as valid separators
to better support plugin and java version checking
