Jnode Configuration Tool
Submitted by jalynch on Tue, 06/01/2004 - 23:26.
It is well decided that Jnode will consist of a net of components; plugins that represent every part of an os: applications, libraries, services, clients, even drivers all follow the same patterns and rules. Every component has the same status so that they can all be treated in a consistent way.
It follows then that the components should be configurable in a consistent manor.
I propose a Configuration Tool that will act as a one-stop management center for ajusting settings throughout the entire os. Since this too is not-unlike a component architecture I would be happy to begin work on it.
The general design of the tool will be like this, components that wish to be customizable register themselves with the tool at install time (install time being a benifit of my plugin manager). Registered components will then have their methods invoked dynamically by commands from a user. The affected components should then persist their state (in my oodb 
so that the change will not be lost.
That is the general layout, but I am not decided on how to accomplish it.
I would appreciate any ideas on how to best to proceed.
Thanks,
Alex
- Login to post comments
Persistent configuration data
Hi all,
See this for an implementation.
Ewout
Persistent State of Classes and Class Evolution
Hi,
have you thinked how to manage the problem of (Serialized) Classes and their Evolution into your Persistent OODB ?
Suppose that I update a package that has serialized classes into your OODB. How can we handle this ?
Ah, in Prevayler they have also more versions of SnapshotManagers (null, Serializers, XML, GZipped, etc.) for the entire Data.
I've read a lot of posts about this problem in other similar products.
You can find some info about this at:
http://www.prevayler.org/wiki.jsp?topic=SchemaEvolution
And something other from www.eclipse.org ...
I hope this will be useful to you.
Bye,
Sandro
Class def change
I have encountered this problem in my personal development and have take steps to address it.
The current version of my persistor supports two modes of persistence, io.Serialization and beans.XMLEncoding.
Serialization of course does not adjust to class def changes, however xml can. The changes that effect xml encoding surround the pressence of complete bean properties (get and set). If either part is missing the data represented by the propery will not be recoverable.
There are three property change senarios:
1) A property that was in ClassA is no longer in ClassB: the data from that property will be lost.
2) A property is in ClassB that was not in ClassA: the data represented by the new property will be null.
3=1+2) A property in ClassA is renamed in ClassB: the data of the original property will be lost and the data of the new property will be null.
With these thoughts in mind, a developer could provide himself a reliable way to transform data from an old version to a new version, just by giving it some thought.
Is this suficient?
Alex
1) propery
Class and Changes
Hi,
I think that having specific Import/Export Classes to Upgrade or Downgrade Serialized Version of data should be sufficent.
The problem is that any Programmer should implement them as needed, with the risk of not being able to read the data serialized.
But and implementing also a default Exporter given the class name of the exporter to use (io.Serialization, beans.XMLEncoding, Skaringa, XStream, Xpp3, etc. ) ?
In this way there wouldn't be the problem to have data inside the storage that is not readable, or at least we cold show what is represented in that data.
To minimize these problems I've seen (from the code samples given with the free download) that in the JE DB (from SleepyCat.com), they transform in byte[] any field of the Objects to persist ... should be another approach, I don't know if it's better, or more time-consuming than the default, but could be another useful approach to study.
Bye,
Sandro
JMX
Why don't you use JMX? That is the de-facto standard in j2se for (remote) configuration and management? There is an opensource implementation also (http://mx4j.sf.net), which is very easy to use.
And if you need some nice UI for , there is http://mc4j.sf.net
Resources
These apear to be excellent resources. The licence for mx4j is pretty straitforward: The licence must follow the code, the MX4J Project must be recongnised by code users, and the authors are indemnified of every thing. Sure.
mc4j is more complicated. It is called the Sapient Public Licence and is based on the Mozilla Public Licence. The SPL only re-references the entities that are to be recongnised and indemnified to the mc4j authors. The MPL itself is quite long, but because it is well known, I thought I would just ask, instead of reading it all.
Is the MPL(1.1) acceptible?
Alex
LGPL JMX
As well as mx4j, there is XMOJO (http://www.xmojo.org) and ofcourse JBoss (http://jboss.org), both are under the LGPL.
License
I have now read all of the SPL (MPL1.1) for mc4j. It seams to me that it is OK. Does any one have any comments?
Alex
Installer
Hi,
how this is related to the JNode Installer proposal under the Documentation / Proposal (and the Gentoo Portage Documentation described there) ? But that was only a partial solution for the full problem ...
The Configuration Tool you say is only the User Front-End, but the Back-end part what is ? Someone is implementing it ?
Your Tool should use that Services (when available).
I think it's correct to have an Installer Tool on OS-Level, where every component MUST pass throught (forced by the OS) to be installed (and to have the Execute grants).
But I think also that we should keep attention to NOT replicate the Windows Registry and the dll/ocx registration/deregistration pain.
For example, and are you sure to lock the entire system to the availability of your OODB ? Or could be used only when necessary (and if not available, simply disable installations ... for ex.). And how can the OS make a silent backup (zipped) copy of that informations t prevent corruption ?
Your solution is good, but we should find a way to implement this in a solid manner, to avoid lock os the System (or at least we should know the potential critical point-of-failures). Because this will be a critical part of the System.
Bye,
Sandro
Reply
>how this is related to the JNode Installer proposal under the >Documentation / Proposal (and the Gentoo Portage Documentation ?>described there) ?
The two are not directly related. That proposal was for a system wide installer. This is for a central configuation point for installed components.
>The Configuration Tool you say is only the User Front-End, but the >Back-end part what is ? Someone is implementing it ?
I will implement the front and back together. Neatly.
>I think it's correct to have an Installer Tool on OS-Level, where >every component MUST pass throught (forced by the OS) to be >installed (and to have the Execute grants).
This is an excellent idea because it forces consistency of behavour.
My component system handles installation of plugins. First the jar data is stored in a secure place. Then any declared ServiceAgent for the plugin is instantiated and given an install() signal. At this time the plugin may do any additional setup that it needs, like registering to be configured by this Configuation Tool.
>But I think also that we should keep attention to NOT replicate the >Windows Registry and the dll/ocx registration/deregistration pain.
I agree completely. My oodb is intended only to be a persistence mechinism not a registry.
>For example, and are you sure to lock the entire system to the >availability of your OODB ? Or could be used only when necessary
>(and if not available, simply disable installations ... for ex.).
The desition to use my systems must be made by the developers, not me.
As for availablity, my component manager depends directly on the oodb, so it could not be a plugin. It must reside with the component manager in a small core-set of classes.
> And how can the OS make a silent backup (zipped) copy of that >informations t prevent corruption ?
This is the first thing that my componet manager does. The data copy is placed in the oodb.
>Your solution is good, but we should find a way to implement this in >a solid manner, to avoid lock os the System (or at least we should >know the potential critical point-of-failures). Because this will be >a critical part of the System.
Your point is well taken, solidarity and reliablity are the most important factors of core systems. I have been refining my systems for several months now, so all of the realy huge bugs are out, however there still remain a few small problems. Most of the problems would take a fairly large amount of detail to explain.
Do you really want to know? I will enumerate them if you like.
Thanks for you feed back,
Alex
Merge some features
Hi Alex,
don't you think that could be useful to merge (at least only some features) the JNode Installer with your Configuration Tool (Back-end part) ? So for ex. we could have the same storage engine used in more than one point of the system, without having two or more different approaches. And the Installer could determine where to Install also for the Plugins, from their Category ...
Finally, in the Configuation Point are you planning also to give the Security Permission for PlugIns and Applications ? And to enable/disable without uninstalling ?
I imagine something like the Personal Firewall ZoneAlarm, where the User give the necessary Grants as required at runtime this could be another Os-Level Component critical to many Tools in JNode, tightly coupled also with the Security Manager.
Bye,
Sandro
Features
My transparent persister has a public api and can be used by any part of the system. It will be used by the Configuration Tool to maintain data. There is currently no concept of plugin category. The only diference amoung plugins is that some may define a ServiceAgent to catch signals (install, startup, shutdown unistall) and some may not.
As for security permissions, do you realy think it is a good idea to let a user manipulate security controles? I can invision a web site that sais, "After you download the plugin, go to the configuration tool and grant PluginDeath full access rights." Ah!
RE: Features
> As for security permissions, do you realy think it is a good idea to let a user manipulate security controles?
I think that by default any plugin/application could read/write only the dir where is installed (transparantly by the OS Installer), and a dir under the user profile, and read only for the rest of the System. The jnode dir could also be no-access by default, to force Applications to use naming services or public API.
But I know that Applications have different restrictions than Drivers or other Plugins for the System ... could be that my idea could work better only for Applications. For ex. if an Application at Runtime need to read/write to some dir, the User (with Administrator Role) could give/deny it, and also for opening network sockets.
And your Config Tool could be a place where the User could return later and review/enable/disable the given grants.
The key role is in the OS: is JNode that must ensure that anything doesn't work without explicit permissions, granted for ex. by your Config Tool. Anything could have denied write access to the jnode dir, except for some OS Tools if it's the case ... and to give the read/write permission to something other to the OS dir could require the packages to be digitally signed, and downloaded by one of the JNoder Mirror Servers.
Do you understand in my idea the coupling between the OS Installer, the Config Tool, and Security Manager ?
The same Security Problem is with the JNode Classes that manage directly the Hardware: how to restrict the usage of these classes (I hope not only with package/classes not public) ? At the moment I know JNode only a few.
The OS itself should find a way to protect from usage of some features ... any idea ?
Bye,
Sandro
Test Client
Hi Alex,
This week I have begun to implement a very simple tool (with a charva user interface) that is a bit similar to your ideas about the configuration tool you have presented above. I call it a 'Test Client' and basically it is intended as a debugging/testing tool.
What it does is simply this:
you begin with all objects bound to a naming service, and then it lets you inspect those objects: see the values of the attributes and invoke methods on it (I used reflection). Then you can use these values again a starting point, and inspect its properties and methods, etc., so you can walk an abject hierarchy with the tool.
So basically you would add the component that you want to debug to a naming service (more on this later), and then you can inspect the state of this object during runtime, and also invoke methods on it, etc.
So it's nothing fancy, I just needed it because at certain points in debugging I wanted to know what happens with some objects.
About the naming service: currently you can use InitialNaming but I intend to add a general naming interface (that for example InitialNaming could implement by default), and then a UserNaming or DebugNaming or whatever can implement it.
I'll try to commit this thing this week (it's nothing fancy, I'll just have to find some time to finish it).
Btw do you plan to commit your developments (e.g the persistance mechanism) anytime soon?
Andras
Good Start
This is a good start. One important detail is that the focus of my project is on persistent state, while yours is on runtime state. The name binding system would need to be persistent, so I believe I will make one of my own (a very lite one). Also the objects that are effected need to be persisistent. I was considering requiring that registered objects be object proxies from the persistence mechinism. This would insure that state changes are persisted. The client that actually wished to be configured could load the object proxy at run time and set its state with that information.
As for me commiting my work, I have not yet been given access rights. I have submited my work to Ewout and a few other intersted parties, but I have not recieved any word. (Of course Ewout might have other things on his mind
What do you (any body) think,
Alex