|
nk4um Moderator
Posts: 756
|
2009-12-22T10:01:12.000ZDecember 22, 2009 10:01
Hi Mark,
Currently apposite does not support updating a previous distribution to the packages of a new distribution (by, for example,
just changing repository path).
Please install 4.0.2 from a clean distro download (we think we''ve now got the lowest level boot strap sorted, so the 4.0.2
distro/repo will be stable for a while).
We will definitely be adding support for distro upgrades prior to the release of the 4.1.0 six monthly refresh in the spring.
Cheers,
Peter
|
|
nk4um User
Posts: 8
|
2009-12-22T09:49:24.000ZDecember 22, 2009 09:49Action?
Peter,
I just ran into this as I updated 4.0.1.
What is the corrective action? Install 4.0.2?
Or is there an xml file that we can rev back to?
If it is just xml files and we''re already using subversion or accu-rev, etc, could we save an old config thread, and pull
the thread?
Thanks,
Mark
|
|
nk4um Moderator
Posts: 756
|
2009-12-16T21:17:06.000ZDecember 16, 2009 21:17
OK Apposite is fixed - when reading the user modules in it was making a presumption that there was a runlevel attribute and
copying through an empty attribute in the case when there was no runlevel. It now only adds the attribute only if the user
has set one.
We''ll also ensure the module manager is tolerant - so in either case this one should not happen to anyone else.
Cheers,
p.
|
|
nk4um Moderator
Posts: 756
|
2009-12-16T21:04:17.000ZDecember 16, 2009 21:04
Hmmm thanks for reporting this. Actually this is a bug in the ModuleManager - it should at least fail safe if the runlevel
attribute is not valid (defaulting to max runlevel).
Will look at apposite - the intent is to not touch user modules - but looks like we need to look at the runlevel attribute.
As far as confidence in Apposite - aside from downloading new module versions and managing a local package cache, physically
all it ever does is write modules.xml - it never ever deletes a physical module. I guess a simple failsafe option would be
for us to take a snapshot of modules.xml and if there were a fail on load you could copy back the snapshot.
We''ll do this before Friday''s updates.
Thanks again!
P.
|
|
nk4um User
Posts: 101
|
It looks like the updater removed the runlevel from one of the modules in module.xml (a local module I created myself) and
that was causing the parseInt exception.
This kind of thing really does not give me great confidence in apposite updates. It ended up being fairly simple to track
down, but what if the corruption had been more subtle and something that would not show up until much later?
|
|
nk4um User
Posts: 101
|
I just ran 2 apposite updates, first to install the embedding tutorial, and then selecting "all updates". After that, my
installation no longer works; I get this error:
I 12:46:52 Kernel
Starting 1060-NetKernel-SE
Resource Oriented Computing Platform
Version 4.0.1
Copyright 2002-2009 1060 Research Limited http://www.1060research.com
1060, NetKernel, Resource Oriented Computing are Trademarks of 1060 Research Ltd.
I 12:46:52 ModuleManager Module Factory [org.netkernel.layer0.module.java.JavaModuleFactory] registered
I 12:46:52 ModuleManager Module Factory [org.netkernel.module.standard.StandardModuleFactory] registered
I 12:46:52 ModuleManager System changing to RunLevel [1]
I 12:46:52 ModuleManager Loading Security Module v1.1.11
I 12:46:52 ModuleManager Loading Core Meta v1.0.1
I 12:46:52 ModuleManager Loading System Services v1.5.29
I 12:46:52 ModuleManager Loading Layer1 v1.3.26
I 12:46:52 ModuleManager Commissioning Modules...
I 12:46:52 Kernel Initialising commissioned modules...
I 12:46:52 LogManager Setting logging levels to [severe=true warning=true info=true fine=false finer=false debug=false cache=false ]
I 12:46:52 Kernel NetKernel Ready, accepting requests...
I 12:46:52 ModuleManager System now at RunLevel [1]
I 12:46:52 InitEndpoint Stem System Active - Init processing started...
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.parseInt(Integer.java:497)
at org.netkernel.ext.system.init.InitEndpoint.initBoot(InitEndpoint.java:74)
at org.netkernel.ext.system.init.InitEndpoint.access$000(InitEndpoint.java:16)
at org.netkernel.ext.system.init.InitEndpoint$InitModuleManagerSyncListener.syncComplete(InitEndpoint.java:121)
at org.netkernel.layer0.boot.ModuleManager.notifySyncListener(ModuleManager.java:538)
at InnerBoot.<init>(InnerBoot.java:154)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at BootLoader.main(BootLoader.java:56)
|
Ay suggestions what the problem might be, how to undo whatever damage was done, and prevent such damage in the future?
|
