Re: Unified Tomcat/Jetty Plans
On Jul 4, 2005, at 2:49 PM, Jeremy Boynes wrote: Aaron Mulder wrote: On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. Well, if you're not going to be the release manager, perhaps instead of flaming everyone in general, you could find a qualified volunteer to be the release manager? Perhaps you could start a page on the Wiki outlining what kind of steps could go into the release procedure? Perhaps you could recommend a date for the next release that we can start working toward? Perhaps you can begin sorting through the JIRA issues and adding them to the M4 release notes document? I can think of all kinds of ways for one of us to get involved if they want to help us produce a more organized release. As I said, I have been told that I would not be welcome in that role - don't flame me for not doing what I was told would not be welcome if I did. All the things you list need to be done as part of the release, plus a lot more. The biggest things is finding someone to do it. That will need buy-in from the PMC so it needs to get its act together. All the PMC technically needs to do is vote such that any such release is an official release of the ASF. Lets just get this working... geir -- Jeremy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Unified Tomcat/Jetty Plans
Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? thanks david jencks On Jul 3, 2005, at 11:14 PM, David Jencks wrote: On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
David Jencks wrote: Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? It's the easiest yet most elegant way I could read so far. I'd recommend that way...until another better one will surface ;) david jencks Jacek
Re: Unified Tomcat/Jetty Plans
On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
RE: Unified Tomcat/Jetty Plans
Hi, Can you please take me off from the mailing list. Thanks, Rahul Jain -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 17:59 To: dev@geronimo.apache.org Subject: Re: Unified Tomcat/Jetty Plans On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Unified Tomcat/Jetty Plans
done. For the future, the usual approach is to send a message to [EMAIL PROTECTED] thanks geir On Jul 4, 2005, at 8:30 AM, Jain, Rahul wrote: Hi, Can you please take me off from the mailing list. Thanks, Rahul Jain -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: 04 July 2005 17:59 To: dev@geronimo.apache.org Subject: Re: Unified Tomcat/Jetty Plans On Jul 4, 2005, at 1:34 AM, Aaron Mulder wrote: As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. No, I don't think we're near review-then-commit at this time as I don't see the necessity to slow things down like that. That said, Jeremy has a point - in general if something will affect all users, we should get into the habit of bringing up for discussion first. Yeah, we're still early and yeah, things are changing, but there's a good balance we can find. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Unified Tomcat/Jetty Plans
I went ahead and added a separate helper class that detects the bad namespace and switches it to the new one. Unfortunately there's a bit of code in the builder just to detect the plan with a different name, but it should be easy enough to back out later. Aaron On Sun, 3 Jul 2005, David Jencks wrote: Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? thanks david jencks On Jul 3, 2005, at 11:14 PM, David Jencks wrote: On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: Which leads me back to the web plans. Some of your comments aren't clear to me. For example: How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement? Jetty and Tomcat are operating off the same XMLBeans right now. If there's further unification that can be done -- by merging runtime bits, let's work on it. But that doesn't have anything to do with the XML format. They are using the same XML but the underlying implementations are very different; if you deploy an application using the Jetty builder it will not run on a Tomcat server. If you define a common interface for the runtime there you are decoupling the builder from the runtime implementation: the builder generates code just to the standard interface. That would result in one builder and two runtimes. It would also mean the builder would not need to change as additional runtimes were added (e.g. the Jetty 6 one), provided each container only needed LCD features. Ultimately I think this is a simpler and more flexible architecture. It not only supports the LCD schema defined by the generic builder, it is also capable of supporting specialized builders for each implementation. Each specialized builder will require its own XML - experience has shown there is just so far you can go with generic properties before it becomes unusable. Eventually we will get back to where we are now with different schemas for different containers (which is another reason for not breaking all the applications). This need not be really complex as the specialized builders can extend the generic one and the specialized XML can extend the generic XML. Most of the heavy lifting is done in the generic builder (to the common inrerface) and the only code in the specialized ones is the container specific stuff. -- Jeremy
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: Dude, need you use the f-bomb? Is this -- Non-technical tip: think about the f***ing users -- honestly your idea of a professional interaction with your peers? Dude, do you think ignoring the needs of users is professional software development? That breaking everyone's application because you couldn't be bothered to think of an upgradable solution is professional behaviour? Before throwing the p-word around look in the mirror. By the way, I think you were exaggerating when you said tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out. Do you feel that's an accurate representation of the other side of this conversation? +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. I read that as saying there will continue to be drastic changes until the 1.0 release - is that interpretation inaccurate? If you were a user, in light of that statement would you look at this software now or would you wait until after 1.0? As far as stability goes, I hate to say it, but we're not there yet. I'm going to have to make massive change to my book for the next milestone. The entire security system looks nothing like it did in M3, web services were not present in M3, MDBs did not work in M3, CMP was incomplete in M3, there was no Tomcat option at all in M3, and the list goes on. Add all that up, and removing 6 characters from a namespace is a trivial change. I don't think anyone *should* be contemplating Geronimo for anything serious. We haven't even released a beta yet! You might want to re-read what you said here. M3 was incomplete, which is different from incompatible. You make a good point with respect to security though - immediately after M3 was cut, all the security definitions incompatibly changed showing that, indeed, this project really does place little value on compatibility. It's not that the change itself isn't trivial, but that it is unnecessary and impacts EVERYONE. I would have hoped someone with your extensive professional experience would have understood that. And on the topic of coordination for builds, it's true we could do better. But you know what? Flaming me (or David, not sure who you were targeting, really) doesn't help. If you'd like to propose a build, such as M4, and ask for a feature freeze while we prepare and test it, I think that would be a great idea. It would have been nice to have done that before we announced that we pass the test, but let's go from where we are. I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. Now who's exaggerating? You asked for constructive tips, one of those is when you're about to break everyone's application, bring it up on the list first as other people may be able to help you find a way to avoid doing so. That avoids firedrills after and keeps users happier. -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. Well, if you're not going to be the release manager, perhaps instead of flaming everyone in general, you could find a qualified volunteer to be the release manager? Perhaps you could start a page on the Wiki outlining what kind of steps could go into the release procedure? Perhaps you could recommend a date for the next release that we can start working toward? Perhaps you can begin sorting through the JIRA issues and adding them to the M4 release notes document? I can think of all kinds of ways for one of us to get involved if they want to help us produce a more organized release. Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: On Mon, 4 Jul 2005, Jeremy Boynes wrote: I wasn't flaming anyone in particular but everyone in general. Where is the co-ordination? There was an M4 proposal about a month ago - who is co-ordinating it? When will it be there, what will it contain? Why *isn't* there a feature freeze, or even a branch? So does this mean you're volunteering to be the release coordinator? I have already been told I would be unwelcome in that role. It is time for the PMC to get its act together. Well, if you're not going to be the release manager, perhaps instead of flaming everyone in general, you could find a qualified volunteer to be the release manager? Perhaps you could start a page on the Wiki outlining what kind of steps could go into the release procedure? Perhaps you could recommend a date for the next release that we can start working toward? Perhaps you can begin sorting through the JIRA issues and adding them to the M4 release notes document? I can think of all kinds of ways for one of us to get involved if they want to help us produce a more organized release. As I said, I have been told that I would not be welcome in that role - don't flame me for not doing what I was told would not be welcome if I did. All the things you list need to be done as part of the release, plus a lot more. The biggest things is finding someone to do it. That will need buy-in from the PMC so it needs to get its act together. -- Jeremy
Re: Unified Tomcat/Jetty Plans -- topic drift
I'd like to gently point out that thread is no longer about Jetty/Tomcat deployment descriptors. Releasing is important. I think enough people have spare cycles now. Keep in mind, JavaOne just ended, people just got back with their families, and today is a major US national holiday It's a little too early to get critical about the project getting it's act together. ;-) I've started a new thread on releasing M4. All constructive feedback can go there. Best regards, David Blevins
Unified Tomcat/Jetty Plans
I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. For the couple Tomcat-specific elements, there's a new chunk that looks like this. You could actually put in chunks like this for more than one container, if for some reason you wanted to support deploying into any (and there was more than just Tomcat that took extra params). web-app ... ... container-config container=Tomcat config-param name=TomcatRealmTomcatRealm/config-param config-param name=TomcatValveChainFirstValve/config-param /container-config ... /web-app I updated the assembly and TCK plans, and ran all the tests, itests, and TCK servlet tests, but this was a substantial change, so please let me know if you're having problems. Interestingly, this should make it pretty easy to run the TCK against Tomcat, since all the application plans will be the same and it's only the core server configuration plans would need to be changed. Thanks, Aaron
Re: Unified Tomcat/Jetty Plans
Nice! Aaron, did you leave in the virtual host...that one is important for Tomcat (and will be for Jetty once its implemented)? This is great stuff. Jeff Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. For the couple Tomcat-specific elements, there's a new chunk that looks like this. You could actually put in chunks like this for more than one container, if for some reason you wanted to support deploying into any (and there was more than just Tomcat that took extra params). web-app ... ... container-config container=Tomcat config-param name=TomcatRealmTomcatRealm/config-param config-param name=TomcatValveChainFirstValve/config-param /container-config ... /web-app I updated the assembly and TCK plans, and ran all the tests, itests, and TCK servlet tests, but this was a substantial change, so please let me know if you're having problems. Interestingly, this should make it pretty easy to run the TCK against Tomcat, since all the application plans will be the same and it's only the core server configuration plans would need to be changed. Thanks, Aaron
Re: Unified Tomcat/Jetty Plans
Never mind the virtual host question...after reviewing the code, it looks like its handled. Jeff Jeff Genender wrote: Nice! Aaron, did you leave in the virtual host...that one is important for Tomcat (and will be for Jetty once its implemented)? This is great stuff. Jeff Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. For the couple Tomcat-specific elements, there's a new chunk that looks like this. You could actually put in chunks like this for more than one container, if for some reason you wanted to support deploying into any (and there was more than just Tomcat that took extra params). web-app ... ... container-config container=Tomcat config-param name=TomcatRealmTomcatRealm/config-param config-param name=TomcatValveChainFirstValve/config-param /container-config ... /web-app I updated the assembly and TCK plans, and ran all the tests, itests, and TCK servlet tests, but this was a substantial change, so please let me know if you're having problems. Interestingly, this should make it pretty easy to run the TCK against Tomcat, since all the application plans will be the same and it's only the core server configuration plans would need to be changed. Thanks, Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. Do existing plans still work? If not, how about providing an upgrade mechanism? -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Jul 3, 2005, at 10:26 AM, Jeremy Boynes wrote: Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo- web.xml, and the namespace is the same as before without the / jetty or /tomcat on the end. Do existing plans still work? If not, how about providing an upgrade mechanism? Maybe a quick doc showing the things that you need to change by hand. -dain
Re: Unified Tomcat/Jetty Plans
On Sun, 3 Jul 2005, Jeremy Boynes wrote: Do existing plans still work? No If not, how about providing an upgrade mechanism? Jetty: remove the /jetty from the default web-app namespace Tomcat: remove the /tomcat from the default web-app namespace - If any of the following elements were used: tomcat-realm tomcat-valve-chain virtual-host Then convert them to container config params: container-config container=Tomcat config-param name=TomcatRealmTomcatRealm/config-param config-param name=TomcatValveChainFirstValve/config-param config-param name=VirtualHostwww.foo.com/config-param /container-config To update the TCK, I used a script that just ran sed to strip off the /jetty and it worked fine. Aaron
Re: Unified Tomcat/Jetty Plans
Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Do existing plans still work? No If not, how about providing an upgrade mechanism? Jetty: remove the /jetty from the default web-app namespace Tomcat: remove the /tomcat from the default web-app namespace - If any of the following elements were used: tomcat-realm tomcat-valve-chain virtual-host Then convert them to container config params: container-config container=Tomcat config-param name=TomcatRealmTomcatRealm/config-param config-param name=TomcatValveChainFirstValve/config-param config-param name=VirtualHostwww.foo.com/config-param /container-config To update the TCK, I used a script that just ran sed to strip off the /jetty and it worked fine. Aaron
Re: Unified Tomcat/Jetty Plans
On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
+1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
We will also eventually need to update the geronimo-web.xml format to accomodate virtual hosts for both Tomcat and Jetty. Currently it's a Tomcat-specific container-config param, and once supported by both containers I think we'll want it to be a top-level element on its own. In any case, it might be smart to make a list of any other configuration changes like this we anticipate making. I've got the changes to PK generation I'm planning to put in once I can get to TranQL (change the XML structure for defining key generators in openejb-jar.xml). I'm not aware of any others off the top of my head, but perhaps others are (anything in security, CORBA, or web services?). Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: We will also eventually need to update the geronimo-web.xml format to accomodate virtual hosts for both Tomcat and Jetty. Currently it's a Tomcat-specific container-config param, and once supported by both containers I think we'll want it to be a top-level element on its own. +1...this should definately be top level when we get Jetty using the virtual hosts. Jeff
Re: Unified Tomcat/Jetty Plans
Dude, need you use the f-bomb? Is this -- Non-technical tip: think about the f***ing users -- honestly your idea of a professional interaction with your peers? By the way, I think you were exaggerating when you said tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out. Do you feel that's an accurate representation of the other side of this conversation? As far as stability goes, I hate to say it, but we're not there yet. I'm going to have to make massive change to my book for the next milestone. The entire security system looks nothing like it did in M3, web services were not present in M3, MDBs did not work in M3, CMP was incomplete in M3, there was no Tomcat option at all in M3, and the list goes on. Add all that up, and removing 6 characters from a namespace is a trivial change. I don't think anyone *should* be contemplating Geronimo for anything serious. We haven't even released a beta yet! And on the topic of coordination for builds, it's true we could do better. But you know what? Flaming me (or David, not sure who you were targeting, really) doesn't help. If you'd like to propose a build, such as M4, and ask for a feature freeze while we prepare and test it, I think that would be a great idea. It would have been nice to have done that before we announced that we pass the test, but let's go from where we are. As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. Which leads me back to the web plans. Some of your comments aren't clear to me. For example: How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement? Jetty and Tomcat are operating off the same XMLBeans right now. If there's further unification that can be done -- by merging runtime bits, let's work on it. But that doesn't have anything to do with the XML format. Honestly, the easiest path is going to be to just get XMLBeans to ignore the namespace difference, since again, the XML content is the same. So I'll ask again, do you know of a way to do that? Some flag we can send it to forget the namespace and just try loading the elements that it expects? If so, let's make that change and move on, instead of arguing ad naseum over whether that change should have been made in the past. Aaron On Sun, 3 Jul 2005, Jeremy Boynes wrote: Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. Where was I exaggerating? You can also answer without being condescending. Anyway, enough with the personal comments. No one's saying that altering configuration formats is a good thing, just that it will steadily get worse the more stable the server gets. And note that an unstable release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh unstable release from that tomorrow. There's unstable and there's unstable - hopefully common sense would say that the first release after a major achievement like CTS complete is likely to garner more attention than just another weekly and hence a little more care would be in order. That your changes went in the revision after DB cut that release indicates a massive lack of co-ordination in the project. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? Do some design work before committing changes? If you send ideas to the list first then we can all review them beforehand rather than having to deal with the aftermath. Maybe it was just me, but I did not realize from your proposal that you were intending to invalidate all existing plans. How about just leaving the existing stuff there? That way existing applications will continue to work whilst the new stuff is being fleshed out. That should actually give you more flexiblity in the run up to 1.0 to get the unified solution right without interfering with the developing user base. How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement? That should simplify the builder code allowing you to support the old schemas with less duplication. Have you looked at the schema conversion stuff DJ did for the J2CA deployment descriptors
