Config management and installation
A couple of questions keep coming up about Geronimo's configuration management system; things like: * How do I change things during installation? * How do I change things when the server is not running? * Are we going to give the configuration plans to users? * WTF is all this stuff anyway? I was going to include background here but thought it was easier to place it directly on the wiki. It can be found at: http://wiki.apache.org/geronimo/Architecture/ConfigurationManagement With that in mind, here we go ... During installation we are really doing three things: 1) Installing the kernel and configuration management system 2) Installing the configuration bundles we want this server to run 3) Performing local-server configuration overrides The first is easy, just install the jars and any of their dependencies in the appropriate place. The user will need to specify where that is, and will need to specify the configuration management system being used (e.g. what are the default Repository, ConfigurationManager and ConfigStore implementations). This gives us a minimal environment where we can install other configuration bundles and which can run *inside the installer.* On to phase two. --- Phase Two Which configuration bundles to install will depend on just what the user wants this server to do: is it full J2EE or just the web teir? do they want the deployment system configured? is this just an app client environment? Based on the responses, the installer can build a list of configuration bundles to install, and then use the environment built in phase one to to install them. This leaves us with a server environment built to the user's specification with standard bundles installed. That may be enough, but if there are local overrides needed, on to phase three. --- Phase Three Once the bundles have been installed, the user may still have local overrides. For example, we may have installed a generic HTTP connector listening on port 8080 and they may want to change that. The installer has access to the Configuration instances it installed and to the persistent properties of the GBeans they contain. Values specified in the installer can be used to override those property values simply by setting the GBean attributes. The GBeans do not need to be started to do that so there is no risk of conflict with other things running on the system. When the installer shuts down its kernel the GBean state will be persisted, ready to be restored the first time the user starts the server. --- There is no requirement here to give the actual source plans to users. They don't form a very friendly UI :-) and instead we should be using steps in the installer for the local configuration. Is there an easy way to make that modular (e.g. by including helper code in the bundle itself)? Having said that, the plans do form the ultimate definition of what the bundle will contain and I would include them in the distro as documentation and so that users don't have to get them from a source bundle. We did that with Gluecode's distro. --- OK, I hope that makes some kind of sense. If it sounds vaguely familiar, it should do - it is very similay to how the assembly module pulls things together. I'd almost be tempted to describe installation as 'assemble-on-site'. -- Jeremy
Re: API and serialization compatibility, was: Build Failure
Tim Ellison wrote: Jeremy Boynes <[EMAIL PROTECTED]> wrote on 14-05-2005 17:47:31: Another thing to remember is that the only classes where serialization compatibility really matters are those that are actually placed in persistent attributes. I would hope all the projects we use do support serialization properly, including providing UIDs and dealing with version drift; if not we should encourage them to do so and help where necessary - it is generally a /good thing/. That will make configuration management easier for both system administrators as well as the runtime and deployment systems. Glad you agree ;-) http://issues.apache.org/jira/browse/GERONIMO-644 Sure do :-) I assigned this to me as a place holder - if you can provide patches that add the SUIDs I will make sure they get applied (at least in Geronimo and other projects where I can). -- Jeremy
Re: [POLL] API and Implementation serialization compatibility and upgrading
Aaron Mulder wrote: I'd like some more information before answering this poll. Namely, what exactly is serialized? I guess I was under the impression that "configuration information" was serialized. You make it sound like, for example, ActiveMQ itself is serialized. Shouldn't we be able to serialize a bunch of settings (port=61616, active transport 1 = vm://localhost, active transport 2 = tcp://localhost:61616, ...) and apply those to version N+1 of ActiveMQ, so long as it didn't remove settings we use or add new required ones without defaults that we don't use? Are we just not doing that? I guess I need to take a closer look. Also, wearing my end user hat, I'm not as concerned about this issue as stated -- Every time I upgrade, for example, JBoss, I install it into a new directory, reapply any configuration changes, and redeploy my apps. It might be different if the product offered an "upgrade in place" install option. Still, I upgrade pretty rarely. So an easy upgrade path is probably for me, at best, a "nice to have". I posted those comments I promised and hope they clarify why this is a big deal to me - basically, that massive deployment madates automated "upgrade in place" In reality, with the model you describe applications will always get redeployed (and hence the config bundles rebuilt) in the new configuration and none of the versioning issues apply. I'm more concerned about the inability to conveniently edit serialized configuration information, which I hope to take up on the other thread that Jeremy was going to start. That is a lot more of a common issue for me -- more of a "must have". Let's run through the use cases there as I think there are many options for this. -- Jeremy
[jira] Assigned: (GERONIMO-644) Serialized form of GBeans objects must each declare SUID
[ http://issues.apache.org/jira/browse/GERONIMO-644?page=all ] Jeremy Boynes reassigned GERONIMO-644: -- Assign To: Jeremy Boynes > Serialized form of GBeans objects must each declare SUID > > > Key: GERONIMO-644 > URL: http://issues.apache.org/jira/browse/GERONIMO-644 > Project: Geronimo > Type: Bug > Reporter: Tim Ellison > Assignee: Jeremy Boynes > > Since Geronimo exchanges config information via serialized form of Java > objects, its imperative that the serializable classes declare a > serialVersionUID. If they don't then the serialized form is not necessarily > compatible across Java implementations (or even Java compilers) [1]. > The case in point is the wire format classes in ActiveMQ (e.g. > "org.codehaus.activemq.message.DefaultWireFormat") which are marked > serializable and do not declare a static ID. I've tried raising this with > ActiveMQ [2] but without success. > I can provide the required SUID in each case, but it looks like I might need > help to get it into the ActiveMQ code. > [1] > http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100 > [2] http://article.gmane.org/gmane.comp.java.activemq.devel/486 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [POLL] API and Implementation serialization compatibility and upgrading
Phil Steitz wrote: Aaron Mulder wrote: Also, wearing my end user hat, I'm not as concerned about this issue as stated -- Every time I upgrade, for example, JBoss, I install it into a new directory, reapply any configuration changes, and redeploy my apps. It might be different if the product offered an "upgrade in place" install option. Still, I upgrade pretty rarely. So an easy upgrade path is probably for me, at best, a "nice to have". I'm more concerned about the inability to conveniently edit serialized configuration information, which I hope to take up on the other thread that Jeremy was going to start. That is a lot more of a common issue for me -- more of a "must have". Aaron As a user, I pretty much agree with Aaron (both points), with the following additional comment on the first one: Major version upgrades are relatively rare events, but applying patches / service packs / whatever they may be called is more common and sometimes needs to be done quickly with minimal disruption. Having to redeploy all apps on a server to which a patch is applied is not ideal. Having strange things happen after patches are applied is even less fun ;-) So I guess it all depends on what exactly we mean by "upgrade"... I put my thoughts on the wiki: http://wiki.apache.org/geronimo/Architecture/ConfigurationManagement My expectation is that if the original server and a "patched" server can both provide the environment the application expects then it will run identically on both systems. I would expect the change process to be something like: * get patched version of server bundle from somewhere * install the patched bundle in a test server * check the existing application still runs and the problem is fixed * build a new application bundle depending on the patched server version you then have a couple of choices for rollout, either * push patched server bundle to production * pro-actively push to runtime servers, replacing the buggy server or * push patched server bundle to production * push updated application bundle to production * roll new application bundle to runtime servers as appropriate * each runtime server will get the patched server bundle from config control so that it can support the new application version and other variations of either approach. -- Jeremy
[jira] Assigned: (GERONIMO-647) Latest GBean naming conventions
[ http://issues.apache.org/jira/browse/GERONIMO-647?page=all ] David Jencks reassigned GERONIMO-647: - Assign To: David Jencks > Latest GBean naming conventions > --- > > Key: GERONIMO-647 > URL: http://issues.apache.org/jira/browse/GERONIMO-647 > Project: Geronimo > Type: Bug > Environment: All Environments > Reporter: anita kulshreshtha > Assignee: David Jencks > Priority: Minor > Attachments: UnavailableEJBReferenceBuilder.patch, > UnavailableServiceReferenceBuilder.patch, UnavailableWebServiceBuilder.patch > > Following classes need to be updated to reflect the latest GBean naming > conventions: >UnavailableEJBReferenceBuilder.java >UnavailableServiceReferenceBuilder.java >UnavailableWebServiceBuilder.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
