Re: Commit configId to moduleId?
Another reason I don't like '.car' is that to some people it has a meaning in Java Web Start (client archive). I remember when I first saw .car files, I googled to see what they were but after following it up on IRC found out it wasn't anything to do with Web Start. http://www.google.com/search?hl=en&q=%2B%22client+archives%22+%2Bjnlp+%2Bcar+&btnG=Search&meta= I just wonder how many people will ask us what the 'car' part of the module names that are displayed during startup mean etc. John Aaron Mulder wrote: Just to clarify, the actual file extension in the form of a file extension is only use in a developer's local Maven repository during a build, and for plugin download files. It's kind of a semantic distinction, but I believe the repository logic is that iy uses the "type" specified in the module ID in the directory name in the repository, so the entries in the repostory are like group/artifact/version/artifact-version.type/ so there is a ".car/" in the directory name (but not in any file names). Bottom line, if we want to change anything, we need to change the standard "type", so for example "geronimo/j2ee-server/1.1/mod" instead of "geronimo/j2ee-server/1.1/car" I'm OK with that, but I don't feel strongly that it needs to be done. I guess I'm kind of a +/- 0. Thanks, Aaron On 5/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Looks like .mdl is already taken. http://www.graphics.cornell.edu/online/formats/mdl/ +1 for ,mod Thanks Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: > +1 > > - sachin > > > > On May 6, 2006, at 3:24 AM, John Sisson wrote: > > > I also was just about to suggest a .module extension, but after > > further thought, having an extension longer than three characters > > is likely to reintroduce the filename length issues (under geronimo > > > \repository) on Windows during the builds. > > > > How about .mod or .mdl. > > > > John > > > > Jason Dillon wrote: > >> I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. > > >> I think that the ear/war/rar thing is lame to start with, the > >> folks that continue to use the same lame extension naming system > >> (sar, har, dar, car) just perpetuate this silly system that Sun > >> dropped on us. > >> > >> If we need to use extensions to clarify what something is, then > >> lets use something more sensible. Like for a module, why not just > > >> use .module? If you want to still say its a jar, > >> then .module.jar, but please lets not make it a .mar. > >> > >> --jason > >> > >> > >> On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: > >> > >>> Sounds like the consensus is to change it (although I don't > >>> remember a formal vote although I do remember the discussion). > >>> For my part it sounds like we're changing the configId to > >>> moduleId to decrease confusion. It seems odd that the modules > >>> are called CARs (Configuration Archives) or some such thing. I > >>> think we're making the server more confusing because now less > >>> things actually line up from a naming perspective. > >>> > >>> It just doesn't feel like we're giving our users a lot of > stability. > >>> > >>> As David said, Just my $0.02. > >>> > >>> I would like to see more input from people though. I've been > >>> travelling so I must have missed the vote to put it in. > >>> > >>> Dain Sundstrom wrote: > I think now is the time to discuss if we want to commit the > change from configId to moduleId. If we decide to commit the > patch, the timing of the actual commit will be determined by > Kevan to have the smallest impact on the TCK. The patch makes > the following changes: > o Renamed root element from "configuration" to "module" > o Renamed environment element from "configId" to "moduleId" > o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo- > module-1.1.xsd" > Based on conversations over the past few days, I think we all > agree that "configuration" is a poor name choice, and we want to > > change it. I also think that we all agree that if we are going > > to make the change we should change the xml schemas before 1.1 > ships to have minimal impact on users (we already have schema > changes going into 1.1). > Should we commit? > -dain > >>> > >> > >> > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Commit configId to moduleId?
On May 5, 2006, at 7:54 PM, Matt Hogstrom wrote: Dave, thanks for the reminder of the vote. I was thinking in terms of Dain's first note in this chain. I believe I voted +1 in that original moduleId thread. After considering this further I'm revising my opinion as I don't think we're solving the problem; just creating new ones. I think I'd be more in favor of making the terminology consistent throughout the server but that is more than can be contained in 1.1. To be honest, I'm not sure what you'd call it. We had an idea proposed followed by a bunch of +1s, but of course "[vote]" wasn't in the title. So your guess is as good as mine :) Regardless, let's hear from Kevan. And anyone who wants to speak their mind on the subject. Thanks for keeping me honest :) Keeping an honest man honest is a one man job. -David
Re: Thinking about 1.2 and moving forward
On 5/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'm consolidating here my recollections of discussion on the list about what to do. The idea that made the most sense to me was to move the current trunk to another branch and copy the 1.1 branch to trunk. We'd then have people merge their changes from the the old trunk to the new and start on 1.2. Hi Matt, Nice you've asked about it ;) I'm almost certain to be the only one who didn't fancy doing as you described, but it seems there's no other way to work it out. Although there's much done wrt M2 conversion, I think we can do it *again* hopefully without much pain along the way...unless Prasad and Anita object. I think the 1.1 branch has existed too long and it's time to wipe it out and never ever done such a lengthy break-off again. Matt Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-1974) Can't "redeploy" a copy of an application using a different version in the module ID
[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=comments#action_12378253 ] Aaron Mulder commented on GERONIMO-1974: Another bug releated to this issue -- when you redeploy to get a new version, the config.xml keeps the original version, so the server fails on restart. A feature was added to the attribute manager to migrate settings to a newer version -- we need to call this from the configuration manager. > Can't "redeploy" a copy of an application using a different version in the > module ID > > > Key: GERONIMO-1974 > URL: http://issues.apache.org/jira/browse/GERONIMO-1974 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Dain Sundstrom > Priority: Blocker > Fix For: 1.1 > Attachments: 1974-redeploy-improvements.patch, redeploy-stacktrace.txt > > If you deploy an application with version foo/bar/1.0/baz and then change the > plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- 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
Thinking about 1.2 and moving forward
I think we're at the point where 1.1 needs to bake for a bit and we'll release it in a few weeks. Since I expect that folks will want to get to putting in new feature and functions for 1.2 I wanted to kick off a thread to get that discussion going. I'm consolidating here my recollections of discussion on the list about what to do. The idea that made the most sense to me was to move the current trunk to another branch and copy the 1.1 branch to trunk. We'd then have people merge their changes from the the old trunk to the new and start on 1.2. I'm not sure about timing but it might be nice to have this work done before Java One and the hackathons. Thoughts? Matt
Re: svn commit: r400233 - in /geronimo/branches/1.1: applications/daytrader/core/ applications/daytrader/ear/ applications/daytrader/ejb/ applications/daytrader/streamer/ applications/daytrader/web/ a
Thanks Kevan and John. Kevan Miller wrote: On May 6, 2006, at 11:05 AM, Matt Hogstrom wrote: John, Is there an issue in DayTrader that required us to add the directories back into the branch? I'm working to completely remove it. Let me know what the problem is and we can work to remove the monster. John didn't add them, I did -- not intentionally... The dirs didn't show up in a diff I ran before committing. I'm not sure why the dirs were still there... Is there some procedure that I'm not following properly? I'll consult the svn doc, when I have a few moments... --kevan John Sisson wrote: FYI, I removed the directories added in this commit. See URL: http://svn.apache.org/viewcvs?rev=400273&view=rev Log: GERONIMO-1640 Delete directories that were accidentally added in previous checkin. John [EMAIL PROTECTED] wrote: Author: kevan Date: Fri May 5 21:03:29 2006 New Revision: 400233 URL: http://svn.apache.org/viewcvs?rev=400233&view=rev Log: GERONIMO-1640 Upgrade Tomcat version to 5.5.15. For compliant jsp operation, upgrade required that Jasper config option 'development' be configured to false. So, involved a bit more than simple version change... Added: geronimo/branches/1.1/applications/daytrader/core/ geronimo/branches/1.1/applications/daytrader/ear/ geronimo/branches/1.1/applications/daytrader/ejb/ geronimo/branches/1.1/applications/daytrader/streamer/ geronimo/branches/1.1/applications/daytrader/web/ geronimo/branches/1.1/applications/daytrader/wsappclient/ geronimo/branches/1.1/applications/jmxdebug/ geronimo/branches/1.1/modules/interop/ Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml geronimo/branches/1.1/etc/explicit_versions.properties geronimo/branches/1.1/etc/project.properties geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java geronimo/branches/1.1/modules/tomcat/src/resources/META-INF/geronimo-tomcat/var/catalina/conf/web.xml Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml (original) +++ geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml Fri May 5 21:03:29 2006 @@ -93,8 +93,9 @@ name="servletClass">org.apache.jasper.servlet.JspServlet 0 - logVerbosityLevel=DEBUG + development=false fork=false + logVerbosityLevel=DEBUG xpoweredBy=false name="servletMappings">*.jsp,*.jspf,*.jspx,*.xsp Modified: geronimo/branches/1.1/etc/explicit_versions.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/explicit_versions.properties?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/explicit_versions.properties (original) +++ geronimo/branches/1.1/etc/explicit_versions.properties Fri May 5 21:03:29 2006 @@ -45,7 +45,7 @@ howl///=0.1.11 #security: hsqldb///=1.7.2.2 -jasper///=5.5.12 +jasper///=5.5.15 javacc///=2.1 jdbm///=0.20-dev jdom///=1.0 @@ -73,8 +73,8 @@ standard_taglibs///=1.1.1 stax/stax//jar=1.1.1-dev stax/stax_api//jar=1.0 -tomcat_ajp///=5.5.9 -tomcat///=5.5.9 +tomcat_ajp///=5.5.15 +tomcat///=5.5.15 tomcat_servlet_examples///=5.5.15 tomcat_jsp_examples///=5.5.15 wadi///=2.0M1 Modified: geronimo/branches/1.1/etc/project.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/project.properties?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/project.properties (original) +++ geronimo/branches/1.1/etc/project.properties Fri May 5 21:03:29 2006 @@ -155,7 +155,7 @@ howl_version=0.1.11 #security: hsqldb_version=1.7.2.2 -jasper_version=5.5.12 +jasper_version=5.5.15 javacc_version=2.1 jdbm_version=0.20-dev jdom_version=1.0 @@ -183,8 +183,8 @@ standard_taglibs_version=1.1.1 stax_version=1.1.1-dev stax_api_version=1.0 -tomcat_ajp_version=5.5.9 -tomcat_version=5.5.9 +tomcat_ajp_version=5.5.15 +tomcat_version=5.5.15 tomcat_servlet_examples_version=5.5.15 tomcat_jsp_examples_version=5.5.15 wadi_version=2.0M1 Modified: geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/dep
Re: Commit configId to moduleId?
I actually don't see any reason why not just leave them as .jar files really. The server needs to know how to treat .jar files different anyways (libraries vs. ejb-jars). :-\ --jason On May 6, 2006, at 10:56 AM, Aaron Mulder wrote: Just to clarify, the actual file extension in the form of a file extension is only use in a developer's local Maven repository during a build, and for plugin download files. It's kind of a semantic distinction, but I believe the repository logic is that iy uses the "type" specified in the module ID in the directory name in the repository, so the entries in the repostory are like group/artifact/version/artifact-version.type/ so there is a ".car/" in the directory name (but not in any file names). Bottom line, if we want to change anything, we need to change the standard "type", so for example "geronimo/j2ee-server/1.1/mod" instead of "geronimo/j2ee-server/1.1/car" I'm OK with that, but I don't feel strongly that it needs to be done. I guess I'm kind of a +/- 0. Thanks, Aaron On 5/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Looks like .mdl is already taken. http://www.graphics.cornell.edu/online/formats/mdl/ +1 for ,mod Thanks Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: > +1 > > - sachin > > > > On May 6, 2006, at 3:24 AM, John Sisson wrote: > > > I also was just about to suggest a .module extension, but after > > further thought, having an extension longer than three characters > > is likely to reintroduce the filename length issues (under geronimo > > > \repository) on Windows during the builds. > > > > How about .mod or .mdl. > > > > John > > > > Jason Dillon wrote: > >> I'd be happy if we never ended up calling any file a .[a-zA-Z] ar. > > >> I think that the ear/war/rar thing is lame to start with, the > >> folks that continue to use the same lame extension naming system > >> (sar, har, dar, car) just perpetuate this silly system that Sun > >> dropped on us. > >> > >> If we need to use extensions to clarify what something is, then > >> lets use something more sensible. Like for a module, why not just > > >> use .module? If you want to still say its a jar, > >> then .module.jar, but please lets not make it a .mar. > >> > >> --jason > >> > >> > >> On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: > >> > >>> Sounds like the consensus is to change it (although I don't > >>> remember a formal vote although I do remember the discussion). > >>> For my part it sounds like we're changing the configId to > >>> moduleId to decrease confusion. It seems odd that the modules > >>> are called CARs (Configuration Archives) or some such thing. I > >>> think we're making the server more confusing because now less > >>> things actually line up from a naming perspective. > >>> > >>> It just doesn't feel like we're giving our users a lot of > stability. > >>> > >>> As David said, Just my $0.02. > >>> > >>> I would like to see more input from people though. I've been > >>> travelling so I must have missed the vote to put it in. > >>> > >>> Dain Sundstrom wrote: > I think now is the time to discuss if we want to commit the > change from configId to moduleId. If we decide to commit the > patch, the timing of the actual commit will be determined by > Kevan to have the smallest impact on the TCK. The patch makes > the following changes: > o Renamed root element from "configuration" to "module" > o Renamed environment element from "configId" to "moduleId" > o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo- > module-1.1.xsd" > Based on conversations over the past few days, I think we all > agree that "configuration" is a poor name choice, and we want to > > change it. I also think that we all agree that if we are going > > to make the change we should change the xml schemas before 1.1 > ships to have minimal impact on users (we already have schema > changes going into 1.1). > Should we commit? > -dain > >>> > >> > >> > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Commit configId to moduleId?
Just to clarify, the actual file extension in the form of a file extension is only use in a developer's local Maven repository during a build, and for plugin download files. It's kind of a semantic distinction, but I believe the repository logic is that iy uses the "type" specified in the module ID in the directory name in the repository, so the entries in the repostory are like group/artifact/version/artifact-version.type/ so there is a ".car/" in the directory name (but not in any file names). Bottom line, if we want to change anything, we need to change the standard "type", so for example "geronimo/j2ee-server/1.1/mod" instead of "geronimo/j2ee-server/1.1/car" I'm OK with that, but I don't feel strongly that it needs to be done. I guess I'm kind of a +/- 0. Thanks, Aaron On 5/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Looks like .mdl is already taken. http://www.graphics.cornell.edu/online/formats/mdl/ +1 for ,mod Thanks Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: > +1 > > - sachin > > > > On May 6, 2006, at 3:24 AM, John Sisson wrote: > > > I also was just about to suggest a .module extension, but after > > further thought, having an extension longer than three characters > > is likely to reintroduce the filename length issues (under geronimo > > > \repository) on Windows during the builds. > > > > How about .mod or .mdl. > > > > John > > > > Jason Dillon wrote: > >> I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. > > >> I think that the ear/war/rar thing is lame to start with, the > >> folks that continue to use the same lame extension naming system > >> (sar, har, dar, car) just perpetuate this silly system that Sun > >> dropped on us. > >> > >> If we need to use extensions to clarify what something is, then > >> lets use something more sensible. Like for a module, why not just > > >> use .module? If you want to still say its a jar, > >> then .module.jar, but please lets not make it a .mar. > >> > >> --jason > >> > >> > >> On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: > >> > >>> Sounds like the consensus is to change it (although I don't > >>> remember a formal vote although I do remember the discussion). > >>> For my part it sounds like we're changing the configId to > >>> moduleId to decrease confusion. It seems odd that the modules > >>> are called CARs (Configuration Archives) or some such thing. I > >>> think we're making the server more confusing because now less > >>> things actually line up from a naming perspective. > >>> > >>> It just doesn't feel like we're giving our users a lot of > stability. > >>> > >>> As David said, Just my $0.02. > >>> > >>> I would like to see more input from people though. I've been > >>> travelling so I must have missed the vote to put it in. > >>> > >>> Dain Sundstrom wrote: > I think now is the time to discuss if we want to commit the > change from configId to moduleId. If we decide to commit the > patch, the timing of the actual commit will be determined by > Kevan to have the smallest impact on the TCK. The patch makes > the following changes: > o Renamed root element from "configuration" to "module" > o Renamed environment element from "configId" to "moduleId" > o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo- > module-1.1.xsd" > Based on conversations over the past few days, I think we all > agree that "configuration" is a poor name choice, and we want to > > change it. I also think that we all agree that if we are going > > to make the change we should change the xml schemas before 1.1 > ships to have minimal impact on users (we already have schema > changes going into 1.1). > Should we commit? > -dain > >>> > >> > >> > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1925) JSP Example Plugin Install/Uninstall/Install doesn't work
[ http://issues.apache.org/jira/browse/GERONIMO-1925?page=comments#action_12378232 ] Kevan Miller commented on GERONIMO-1925: I've inverted the default ClassLoader. The new ClassLoader, JarFileClassLoader is now the default. To run with the old ClassLoader, use -DXorg.apache.geronimo.OldClassLoader=true > JSP Example Plugin Install/Uninstall/Install doesn't work > - > > Key: GERONIMO-1925 > URL: http://issues.apache.org/jira/browse/GERONIMO-1925 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: Plugins > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Dain Sundstrom > Priority: Critical > Fix For: 1.1 > > From dev list: > I ran the following test with today's build : > 1. From console click plugins --> Search Plugins --> Jakarta JSP > Examples --> install plugin --> start g/jsp-examples../car > 2. Web App Wars --> stop --> uninstall (jsp-examples) > 3. repeat 1. > After clicking on 'plugins' the warnings are printed. The car is > installed and started successfully and works. an error occurs in step2. > The stack trace appears during 'start ' in step 3. -- 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: svn commit: r400233 - in /geronimo/branches/1.1: applications/daytrader/core/ applications/daytrader/ear/ applications/daytrader/ejb/ applications/daytrader/streamer/ applications/daytrader/web/ a
On May 6, 2006, at 11:05 AM, Matt Hogstrom wrote: John, Is there an issue in DayTrader that required us to add the directories back into the branch? I'm working to completely remove it. Let me know what the problem is and we can work to remove the monster. John didn't add them, I did -- not intentionally... The dirs didn't show up in a diff I ran before committing. I'm not sure why the dirs were still there... Is there some procedure that I'm not following properly? I'll consult the svn doc, when I have a few moments... --kevan John Sisson wrote: FYI, I removed the directories added in this commit. See URL: http://svn.apache.org/viewcvs?rev=400273&view=rev Log: GERONIMO-1640 Delete directories that were accidentally added in previous checkin. John [EMAIL PROTECTED] wrote: Author: kevan Date: Fri May 5 21:03:29 2006 New Revision: 400233 URL: http://svn.apache.org/viewcvs?rev=400233&view=rev Log: GERONIMO-1640 Upgrade Tomcat version to 5.5.15. For compliant jsp operation, upgrade required that Jasper config option 'development' be configured to false. So, involved a bit more than simple version change... Added: geronimo/branches/1.1/applications/daytrader/core/ geronimo/branches/1.1/applications/daytrader/ear/ geronimo/branches/1.1/applications/daytrader/ejb/ geronimo/branches/1.1/applications/daytrader/streamer/ geronimo/branches/1.1/applications/daytrader/web/ geronimo/branches/1.1/applications/daytrader/wsappclient/ geronimo/branches/1.1/applications/jmxdebug/ geronimo/branches/1.1/modules/interop/ Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml geronimo/branches/1.1/etc/explicit_versions.properties geronimo/branches/1.1/etc/project.properties geronimo/branches/1.1/modules/jetty-builder/src/java/org/ apache/geronimo/jetty/deployment/JettyModuleBuilder.java geronimo/branches/1.1/modules/tomcat/src/resources/META-INF/ geronimo-tomcat/var/catalina/conf/web.xml Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/ plan.xml URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/configs/ jetty-deployer/src/plan/plan.xml? rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/configs/jetty-deployer/src/plan/ plan.xml (original) +++ geronimo/branches/1.1/configs/jetty-deployer/src/plan/ plan.xml Fri May 5 21:03:29 2006 @@ -93,8 +93,9 @@ name="servletClass">org.apache.jasper.servlet.JspServlet 0 - logVerbosityLevel=DEBUG + development=false fork=false + logVerbosityLevel=DEBUG xpoweredBy=false name="servletMappings">*.jsp,*.jspf,*.jspx,*.xsp Modified: geronimo/branches/1.1/etc/explicit_versions.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/ explicit_versions.properties? rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/explicit_versions.properties (original) +++ geronimo/branches/1.1/etc/explicit_versions.properties Fri May 5 21:03:29 2006 @@ -45,7 +45,7 @@ howl///=0.1.11 #security: hsqldb///=1.7.2.2 -jasper///=5.5.12 +jasper///=5.5.15 javacc///=2.1 jdbm///=0.20-dev jdom///=1.0 @@ -73,8 +73,8 @@ standard_taglibs///=1.1.1 stax/stax//jar=1.1.1-dev stax/stax_api//jar=1.0 -tomcat_ajp///=5.5.9 -tomcat///=5.5.9 +tomcat_ajp///=5.5.15 +tomcat///=5.5.15 tomcat_servlet_examples///=5.5.15 tomcat_jsp_examples///=5.5.15 wadi///=2.0M1 Modified: geronimo/branches/1.1/etc/project.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/ project.properties?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/project.properties (original) +++ geronimo/branches/1.1/etc/project.properties Fri May 5 21:03:29 2006 @@ -155,7 +155,7 @@ howl_version=0.1.11 #security: hsqldb_version=1.7.2.2 -jasper_version=5.5.12 +jasper_version=5.5.15 javacc_version=2.1 jdbm_version=0.20-dev jdom_version=1.0 @@ -183,8 +183,8 @@ standard_taglibs_version=1.1.1 stax_version=1.1.1-dev stax_api_version=1.0 -tomcat_ajp_version=5.5.9 -tomcat_version=5.5.9 +tomcat_ajp_version=5.5.15 +tomcat_version=5.5.15 tomcat_servlet_examples_version=5.5.15 tomcat_jsp_examples_version=5.5.15 wadi_version=2.0M1 Modified: geronimo/branches/1.1/modules/jetty-builder/src/java/ org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/ jetty-builder/src/java/org/apache/geronimo/jetty/deployment/ JettyModuleBuilder.java?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/modules/jetty-builder/src/java/org/ apache/geronimo/jetty/deployment/JettyModuleBuilder.ja
Re: svn commit: r400233 - in /geronimo/branches/1.1: applications/daytrader/core/ applications/daytrader/ear/ applications/daytrader/ejb/ applications/daytrader/streamer/ applications/daytrader/web/ a
John, Is there an issue in DayTrader that required us to add the directories back into the branch? I'm working to completely remove it. Let me know what the problem is and we can work to remove the monster. John Sisson wrote: FYI, I removed the directories added in this commit. See URL: http://svn.apache.org/viewcvs?rev=400273&view=rev Log: GERONIMO-1640 Delete directories that were accidentally added in previous checkin. John [EMAIL PROTECTED] wrote: Author: kevan Date: Fri May 5 21:03:29 2006 New Revision: 400233 URL: http://svn.apache.org/viewcvs?rev=400233&view=rev Log: GERONIMO-1640 Upgrade Tomcat version to 5.5.15. For compliant jsp operation, upgrade required that Jasper config option 'development' be configured to false. So, involved a bit more than simple version change... Added: geronimo/branches/1.1/applications/daytrader/core/ geronimo/branches/1.1/applications/daytrader/ear/ geronimo/branches/1.1/applications/daytrader/ejb/ geronimo/branches/1.1/applications/daytrader/streamer/ geronimo/branches/1.1/applications/daytrader/web/ geronimo/branches/1.1/applications/daytrader/wsappclient/ geronimo/branches/1.1/applications/jmxdebug/ geronimo/branches/1.1/modules/interop/ Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml geronimo/branches/1.1/etc/explicit_versions.properties geronimo/branches/1.1/etc/project.properties geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java geronimo/branches/1.1/modules/tomcat/src/resources/META-INF/geronimo-tomcat/var/catalina/conf/web.xml Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml (original) +++ geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml Fri May 5 21:03:29 2006 @@ -93,8 +93,9 @@ name="servletClass">org.apache.jasper.servlet.JspServlet 0 - logVerbosityLevel=DEBUG + development=false fork=false + logVerbosityLevel=DEBUG xpoweredBy=false name="servletMappings">*.jsp,*.jspf,*.jspx,*.xsp Modified: geronimo/branches/1.1/etc/explicit_versions.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/explicit_versions.properties?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/explicit_versions.properties (original) +++ geronimo/branches/1.1/etc/explicit_versions.properties Fri May 5 21:03:29 2006 @@ -45,7 +45,7 @@ howl///=0.1.11 #security: hsqldb///=1.7.2.2 -jasper///=5.5.12 +jasper///=5.5.15 javacc///=2.1 jdbm///=0.20-dev jdom///=1.0 @@ -73,8 +73,8 @@ standard_taglibs///=1.1.1 stax/stax//jar=1.1.1-dev stax/stax_api//jar=1.0 -tomcat_ajp///=5.5.9 -tomcat///=5.5.9 +tomcat_ajp///=5.5.15 +tomcat///=5.5.15 tomcat_servlet_examples///=5.5.15 tomcat_jsp_examples///=5.5.15 wadi///=2.0M1 Modified: geronimo/branches/1.1/etc/project.properties URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/project.properties?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/etc/project.properties (original) +++ geronimo/branches/1.1/etc/project.properties Fri May 5 21:03:29 2006 @@ -155,7 +155,7 @@ howl_version=0.1.11 #security: hsqldb_version=1.7.2.2 -jasper_version=5.5.12 +jasper_version=5.5.15 javacc_version=2.1 jdbm_version=0.20-dev jdom_version=1.0 @@ -183,8 +183,8 @@ standard_taglibs_version=1.1.1 stax_version=1.1.1-dev stax_api_version=1.0 -tomcat_ajp_version=5.5.9 -tomcat_version=5.5.9 +tomcat_ajp_version=5.5.15 +tomcat_version=5.5.15 tomcat_servlet_examples_version=5.5.15 tomcat_jsp_examples_version=5.5.15 wadi_version=2.0M1 Modified: geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java URL: http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java?rev=400233&r1=400232&r2=400233&view=diff == --- geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java (original) +++ geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java Fri May 5 21:03:29 2006 @@ -840,6 +840,7 @@ String servletName = servletType.getServletName().getStringValue().trim(); AbstractName servletAbstractName = earContext.getNaming().createChildName(webModul
Re: Commit configId to moduleId?
Looks like .mdl is already taken. http://www.graphics.cornell.edu/online/formats/mdl/ +1 for ,mod Thanks Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: > +1 > > - sachin > > > > On May 6, 2006, at 3:24 AM, John Sisson wrote: > > > I also was just about to suggest a .module extension, but after > > further thought, having an extension longer than three characters > > is likely to reintroduce the filename length issues (under geronimo > > > \repository) on Windows during the builds. > > > > How about .mod or .mdl. > > > > John > > > > Jason Dillon wrote: > >> I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. > > >> I think that the ear/war/rar thing is lame to start with, the > >> folks that continue to use the same lame extension naming system > >> (sar, har, dar, car) just perpetuate this silly system that Sun > >> dropped on us. > >> > >> If we need to use extensions to clarify what something is, then > >> lets use something more sensible. Like for a module, why not just > > >> use .module? If you want to still say its a jar, > >> then .module.jar, but please lets not make it a .mar. > >> > >> --jason > >> > >> > >> On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: > >> > >>> Sounds like the consensus is to change it (although I don't > >>> remember a formal vote although I do remember the discussion). > >>> For my part it sounds like we're changing the configId to > >>> moduleId to decrease confusion. It seems odd that the modules > >>> are called CARs (Configuration Archives) or some such thing. I > >>> think we're making the server more confusing because now less > >>> things actually line up from a naming perspective. > >>> > >>> It just doesn't feel like we're giving our users a lot of > stability. > >>> > >>> As David said, Just my $0.02. > >>> > >>> I would like to see more input from people though. I've been > >>> travelling so I must have missed the vote to put it in. > >>> > >>> Dain Sundstrom wrote: > I think now is the time to discuss if we want to commit the > change from configId to moduleId. If we decide to commit the > patch, the timing of the actual commit will be determined by > Kevan to have the smallest impact on the TCK. The patch makes > the following changes: > o Renamed root element from "configuration" to "module" > o Renamed environment element from "configId" to "moduleId" > o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo- > module-1.1.xsd" > Based on conversations over the past few days, I think we all > agree that "configuration" is a poor name choice, and we want to > > change it. I also think that we all agree that if we are going > > to make the change we should change the xml schemas before 1.1 > ships to have minimal impact on users (we already have schema > changes going into 1.1). > Should we commit? > -dain > >>> > >> > >> > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Commit configId to moduleId?
+1 - sachin On May 6, 2006, at 3:24 AM, John Sisson wrote: I also was just about to suggest a .module extension, but after further thought, having an extension longer than three characters is likely to reintroduce the filename length issues (under geronimo \repository) on Windows during the builds. How about .mod or .mdl. John Jason Dillon wrote: I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. I think that the ear/war/rar thing is lame to start with, the folks that continue to use the same lame extension naming system (sar, har, dar, car) just perpetuate this silly system that Sun dropped on us. If we need to use extensions to clarify what something is, then lets use something more sensible. Like for a module, why not just use .module? If you want to still say its a jar, then .module.jar, but please lets not make it a .mar. --jason On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: Sounds like the consensus is to change it (although I don't remember a formal vote although I do remember the discussion). For my part it sounds like we're changing the configId to moduleId to decrease confusion. It seems odd that the modules are called CARs (Configuration Archives) or some such thing. I think we're making the server more confusing because now less things actually line up from a naming perspective. It just doesn't feel like we're giving our users a lot of stability. As David said, Just my $0.02. I would like to see more input from people though. I've been travelling so I must have missed the vote to put it in. Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from "configuration" to "module" o Renamed environment element from "configId" to "moduleId" o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo- module-1.1.xsd" Based on conversations over the past few days, I think we all agree that "configuration" is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
[jira] Updated: (GERONIMO-1993) Build failure during assembly of j2ee-installer
[ http://issues.apache.org/jira/browse/GERONIMO-1993?page=all ] Anita Kulshreshtha updated GERONIMO-1993: - Attachment: j2ee-installer.patch This patch removes sample applications, i.e *-example-* and daytrader application. They can not be installed using the installer. This is consistent with the other server assemblies. This will allow successful build on windows. The corresponding entries must be removed from the selection panel. > Build failure during assembly of j2ee-installer > --- > > Key: GERONIMO-1993 > URL: http://issues.apache.org/jira/browse/GERONIMO-1993 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: installer > Versions: 1.1 > Environment: Win XP > Reporter: Anita Kulshreshtha > Assignee: Anita Kulshreshtha > Priority: Minor > Fix For: 1.1 > Attachments: j2ee-installer.patch > > The build is failing during the assembly of j2ee-installer. The installer > still allows the jsp-examples-* and servlet-examples-* cars to be > installed in the server repository. The other servers i.e. j2ee-*-server do > not install these configurations anymore. We should remove these from the > installer as well. This may not be an issue on linux machines. > .. >[java] Adding resource: ImgPacksPanel.img.17 > [java] Adding resource: ImgPacksPanel.img.18 > [java] Adding resource: ImgPacksPanel.img.19 > [java] Adding resource: ImgPacksPanel.img.20 > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InstallPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ProcessPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.
[jira] Closed: (GERONIMO-1867) Startup output from --long badly formatted (regression from 1.0)
[ http://issues.apache.org/jira/browse/GERONIMO-1867?page=all ] John Sisson closed GERONIMO-1867: - Resolution: Fixed > Startup output from --long badly formatted (regression from 1.0) > > > Key: GERONIMO-1867 > URL: http://issues.apache.org/jira/browse/GERONIMO-1867 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: startup/shutdown > Versions: 1.1 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.1 > > The n/total count for each configuration is displayed in the wrong position > on the line. ( IIRC djencks said he changed the startup output from what was > in 1.0 so you could see which configuration is currently starting. > Previously in 1.0 a line was only output when a configuration had started ). > For example: > Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in 1/16 0s > needs to be changed to display : > Configuration 1/16 geronimo/rmi-naming/1.1-SNAPSHOT/car started in 0s > Also it would look better if the startup times are aligned for easier reading > and comparison. This should be possible from memory as we should be able to > calculate the longest configuration name before we start. > Here is an example of the current output: > $./geronimo.sh run --long > Using GERONIMO_BASE: > /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/j2se > Booting Geronimo Kernel (in Java 1.4.2_10)... > Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in 1/16 0s > Configuration geronimo/j2ee-server/1.1-SNAPSHOT/car started in 2/16 2s > Configuration geronimo/j2ee-security/1.1-SNAPSHOT/car started in 3/16 1s > Configuration geronimo/system-database/1.1-SNAPSHOT/car started in 4/16 4s > Configuration geronimo/activemq-broker/1.1-SNAPSHOT/car started in 5/16 2s > Configuration geronimo/activemq/1.1-SNAPSHOT/car started in 6/16 0s > Configuration geronimo/tomcat/1.1-SNAPSHOT/car started in 7/16 4s > Configuration geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car started in > 8/16 1s > Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car started in 9/16 1s > Configuration geronimo/tomcat-deployer/1.1-SNAPSHOT/car started in 10/16 0s > Configuration geronimo/welcome-tomcat/1.1-SNAPSHOT/car started in 11/16 0s > Configuration geronimo/webconsole-tomcat/1.1-SNAPSHOT/car started in 12/16 > 2s > Configuration geronimo/jmxdebug-tomcat/1.1-SNAPSHOT/car started in 13/16 1s > Configuration geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car started in 14/16 > 0s > Configuration geronimo/hot-deployer/1.1-SNAPSHOT/car started in 15/16 1s > Configuration geronimo/sharedlib/1.1-SNAPSHOT/car started in 16/16 0s > Startup completed in 25 seconds > > After the fix, the output now looks like the following (note that the > configuration names are padded to the length of the longest configuration > name so the startup times line up): > C:\test>geronimo-1.1-SNAPSHOT\bin\geronimo.bat run --long > Using GERONIMO_BASE: C:\test\geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: C:\test\geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: C:\test\geronimo-1.1-SNAPSHOT\var\temp > Using JRE_HOME:C:\j2sdk1.4.2_10 > Booting Geronimo Kernel (in Java 1.4.2_10)... > Configuration 1/20 geronimo/rmi-naming/1.1-SNAPSHOT/car >started in 0s > Configuration 2/20 geronimo/j2ee-server/1.1-SNAPSHOT/car >started in 1s > Configuration 3/20 geronimo/j2ee-security/1.1-SNAPSHOT/car >started in 1s > Configuration 4/20 geronimo/axis/1.1-SNAPSHOT/car >started in 0s > Configuration 5/20 geronimo/openejb/1.1-SNAPSHOT/car >started in 0s > Configuration 6/20 geronimo/system-database/1.1-SNAPSHOT/car >started in 2s > Configuration 7/20 geronimo/activemq-broker/1.1-SNAPSHOT/car >started in 1s > Configuration 8/20 geronimo/activemq/1.1-SNAPSHOT/car >started in 1s > Configuration 9/20 geronimo/tomcat/1.1-SNAPSHOT/car >started in 2s > Configuration 10/20 geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car >started in 1s > Configuration 11/20 geronimo/j2ee-deployer/1.1-SNAPSHOT/car >started in 0s > Configuration 12/20 geronimo/openejb-de
[jira] Updated: (GERONIMO-1867) Startup output from --long badly formatted (regression from 1.0)
[ http://issues.apache.org/jira/browse/GERONIMO-1867?page=all ] John Sisson updated GERONIMO-1867: -- Description: The n/total count for each configuration is displayed in the wrong position on the line. ( IIRC djencks said he changed the startup output from what was in 1.0 so you could see which configuration is currently starting. Previously in 1.0 a line was only output when a configuration had started ). For example: Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in 1/16 0s needs to be changed to display : Configuration 1/16 geronimo/rmi-naming/1.1-SNAPSHOT/car started in 0s Also it would look better if the startup times are aligned for easier reading and comparison. This should be possible from memory as we should be able to calculate the longest configuration name before we start. Here is an example of the current output: $./geronimo.sh run --long Using GERONIMO_BASE: /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/sissonj/OpenSourceJava/asf/geronimo/branches/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/j2se Booting Geronimo Kernel (in Java 1.4.2_10)... Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in 1/16 0s Configuration geronimo/j2ee-server/1.1-SNAPSHOT/car started in 2/16 2s Configuration geronimo/j2ee-security/1.1-SNAPSHOT/car started in 3/16 1s Configuration geronimo/system-database/1.1-SNAPSHOT/car started in 4/16 4s Configuration geronimo/activemq-broker/1.1-SNAPSHOT/car started in 5/16 2s Configuration geronimo/activemq/1.1-SNAPSHOT/car started in 6/16 0s Configuration geronimo/tomcat/1.1-SNAPSHOT/car started in 7/16 4s Configuration geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car started in 8/16 1s Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car started in 9/16 1s Configuration geronimo/tomcat-deployer/1.1-SNAPSHOT/car started in 10/16 0s Configuration geronimo/welcome-tomcat/1.1-SNAPSHOT/car started in 11/16 0s Configuration geronimo/webconsole-tomcat/1.1-SNAPSHOT/car started in 12/16 2s Configuration geronimo/jmxdebug-tomcat/1.1-SNAPSHOT/car started in 13/16 1s Configuration geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car started in 14/16 0s Configuration geronimo/hot-deployer/1.1-SNAPSHOT/car started in 15/16 1s Configuration geronimo/sharedlib/1.1-SNAPSHOT/car started in 16/16 0s Startup completed in 25 seconds After the fix, the output now looks like the following (note that the configuration names are padded to the length of the longest configuration name so the startup times line up): C:\test>geronimo-1.1-SNAPSHOT\bin\geronimo.bat run --long Using GERONIMO_BASE: C:\test\geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: C:\test\geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\test\geronimo-1.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Booting Geronimo Kernel (in Java 1.4.2_10)... Configuration 1/20 geronimo/rmi-naming/1.1-SNAPSHOT/car started in 0s Configuration 2/20 geronimo/j2ee-server/1.1-SNAPSHOT/car started in 1s Configuration 3/20 geronimo/j2ee-security/1.1-SNAPSHOT/car started in 1s Configuration 4/20 geronimo/axis/1.1-SNAPSHOT/car started in 0s Configuration 5/20 geronimo/openejb/1.1-SNAPSHOT/car started in 0s Configuration 6/20 geronimo/system-database/1.1-SNAPSHOT/car started in 2s Configuration 7/20 geronimo/activemq-broker/1.1-SNAPSHOT/car started in 1s Configuration 8/20 geronimo/activemq/1.1-SNAPSHOT/car started in 1s Configuration 9/20 geronimo/tomcat/1.1-SNAPSHOT/car started in 2s Configuration 10/20 geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car started in 1s Configuration 11/20 geronimo/j2ee-deployer/1.1-SNAPSHOT/car started in 0s Configuration 12/20 geronimo/openejb-deployer/1.1-SNAPSHOT/car started in 0s Configuration 13/20 geronimo/client-deployer/1.1-SNAPSHOT/car started in 0s Configuration 14/20 geronimo/axis-deployer/1.1-SNAPSHOT/car started in 0s Configuration 15/20 geronimo/sharedlib/1.1-SNAPSHOT/car started in 0s Configuration 16/20 geronimo/tomcat-deployer/1.1-SNAPSHOT/car started in 0s Configuration 17/20 geronimo/welcome-tomcat/1.1-SNAPSHOT/car started in 0s C
Re: Directory Update (Jeff?)
Alex, Oh, I've been searching in old "directory" and "directory-network" groups rather than "org/apache/directory/server/apacheds-core". Thank you for pointing the right group id. 2006/5/5, Alex Karasulu <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Hi, > > I have created a patch to move the G directory module to ApacheDS 1.0 > RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at > /maven nor at /maven2. The most recent version is 0.9.3. The same > situation for MINA. So I can't post the patch right now since it will > not work without these jars. > Alex, I just want to let you know about this situation. > Hmmm I'm seeing the RC2 jars just fine. Take a look here at the core jar for example: http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ Also MINA stuff is here: http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/ HTH, Alex > 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>: >> Aaron Mulder wrote: >> > I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. >> > >> Ya all including RC1 should be in the M2 repo if not let me know. >> >> Alex >> > Thanks, >> > Aaron >> > >> > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> > >> >> Alex, >> >> >> >> Can you get the jars in ibiblio and I can get the integration >> going? I >> >> am only seeing 0.9.2 in ibiblio at the moment. >> >> >> >> Thanks, >> >> >> >> Jeff >> >> >> >> Alex Karasulu wrote: >> >> >> >>> Jeff Genender wrote: >> >>> >> If the changes are not huge, I can probably do it. Alex, are the >> updates significant? >> >> >>> Since 0.9.2 I'd say RC1 is a significant update. There are >> package name >> >>> changes to comply with Directory's TLP domain name which are >> perhaps the >> >>> most significant changes. There are changes to a couple >> dependencies. >> >>> For the most part the code has been cleaned up and several >> *severe* bugs >> >>> have been corrected and tested. RC1 is also an order of >> magnitude faster. >> >>> >> >>> We plan to get another 1.0 release candidate (RC2) out soon >> perhaps by >> >>> the end of this week coming week or week there after. But >> looking at >> >>> emails out there from Dain and Aaron it sounds to me like the >> update to >> >>> G can take place any time after the 1.1 release. Let us know if you >> >>> have any problems or need a hand while performing an upgrade >> either to >> >>> RC1 or RC2 when it comes out. >> >>> >> >>> Regards, >> >>> Alex -- Alexei Zakharov, Intel Middleware Product Division
[jira] Assigned: (GERONIMO-1993) Build failure during assembly of j2ee-installer
[ http://issues.apache.org/jira/browse/GERONIMO-1993?page=all ] Anita Kulshreshtha reassigned GERONIMO-1993: Assign To: Anita Kulshreshtha > Build failure during assembly of j2ee-installer > --- > > Key: GERONIMO-1993 > URL: http://issues.apache.org/jira/browse/GERONIMO-1993 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: installer > Versions: 1.1 > Environment: Win XP > Reporter: Anita Kulshreshtha > Assignee: Anita Kulshreshtha > Priority: Minor > Fix For: 1.1 > > The build is failing during the assembly of j2ee-installer. The installer > still allows the jsp-examples-* and servlet-examples-* cars to be > installed in the server repository. The other servers i.e. j2ee-*-server do > not install these configurations anymore. We should remove these from the > installer as well. This may not be an issue on linux machines. > .. >[java] Adding resource: ImgPacksPanel.img.17 > [java] Adding resource: ImgPacksPanel.img.18 > [java] Adding resource: ImgPacksPanel.img.19 > [java] Adding resource: ImgPacksPanel.img.20 > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InstallPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ProcessPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InfoPanel.jar > [java] Adding content of jar: > file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim > o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/FinishPanel.jar > [java] -> Fatal error : > [java] > D:\X\geronimo\geronimo-1.1\assemblies\j2ee-installer/target/geronimo-1.1
[jira] Updated: (GERONIMO-1995) The installer should allow the default settings to be restored
[ http://issues.apache.org/jira/browse/GERONIMO-1995?page=all ] Anita Kulshreshtha updated GERONIMO-1995: - Description: The panel that allows the selection of components should have a 'restore defaults' button. New users might want to check/uncheck boxes to see the dependencies. It would be nice if they could go back to the default state. was: The panel that allows the selection of components shuld have a 'restore defaults' button. New users might want to check/uncheck boxes to see the dependencies. It would be nice if they could go back to the default state. > The installer should allow the default settings to be restored > -- > > Key: GERONIMO-1995 > URL: http://issues.apache.org/jira/browse/GERONIMO-1995 > Project: Geronimo > Type: Wish > Security: public(Regular issues) > Components: installer > Versions: 1.1 > Environment: All > Reporter: Anita Kulshreshtha > Priority: Trivial > Fix For: 1.1 > > The panel that allows the selection of components should have a 'restore > defaults' button. New users might want to > check/uncheck boxes to see the dependencies. It would be nice if they could > go back to the default state. -- 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
[jira] Created: (GERONIMO-1995) The installer should allow the default settings to be restored
The installer should allow the default settings to be restored -- Key: GERONIMO-1995 URL: http://issues.apache.org/jira/browse/GERONIMO-1995 Project: Geronimo Type: Wish Security: public (Regular issues) Components: installer Versions: 1.1 Environment: All Reporter: Anita Kulshreshtha Priority: Trivial Fix For: 1.1 The panel that allows the selection of components shuld have a 'restore defaults' button. New users might want to check/uncheck boxes to see the dependencies. It would be nice if they could go back to the default state. -- 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: svn commit: r400233 - in /geronimo/branches/1.1: applications/daytrader/core/ applications/daytrader/ear/ applications/daytrader/ejb/ applications/daytrader/streamer/ applications/daytrader/web/ a
FYI, I removed the directories added in this commit. See
URL: http://svn.apache.org/viewcvs?rev=400273&view=rev
Log:
GERONIMO-1640 Delete directories that were accidentally added in previous
checkin.
John
[EMAIL PROTECTED] wrote:
Author: kevan
Date: Fri May 5 21:03:29 2006
New Revision: 400233
URL: http://svn.apache.org/viewcvs?rev=400233&view=rev
Log:
GERONIMO-1640 Upgrade Tomcat version to 5.5.15. For compliant jsp operation,
upgrade required that Jasper config option 'development' be configured to
false. So, involved a bit more than simple version change...
Added:
geronimo/branches/1.1/applications/daytrader/core/
geronimo/branches/1.1/applications/daytrader/ear/
geronimo/branches/1.1/applications/daytrader/ejb/
geronimo/branches/1.1/applications/daytrader/streamer/
geronimo/branches/1.1/applications/daytrader/web/
geronimo/branches/1.1/applications/daytrader/wsappclient/
geronimo/branches/1.1/applications/jmxdebug/
geronimo/branches/1.1/modules/interop/
Modified:
geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml
geronimo/branches/1.1/etc/explicit_versions.properties
geronimo/branches/1.1/etc/project.properties
geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java
geronimo/branches/1.1/modules/tomcat/src/resources/META-INF/geronimo-tomcat/var/catalina/conf/web.xml
Modified: geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml?rev=400233&r1=400232&r2=400233&view=diff
==
--- geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml (original)
+++ geronimo/branches/1.1/configs/jetty-deployer/src/plan/plan.xml Fri May 5
21:03:29 2006
@@ -93,8 +93,9 @@
org.apache.jasper.servlet.JspServlet
0
- logVerbosityLevel=DEBUG
+ development=false
fork=false
+ logVerbosityLevel=DEBUG
xpoweredBy=false
*.jsp,*.jspf,*.jspx,*.xsp
Modified: geronimo/branches/1.1/etc/explicit_versions.properties
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/explicit_versions.properties?rev=400233&r1=400232&r2=400233&view=diff
==
--- geronimo/branches/1.1/etc/explicit_versions.properties (original)
+++ geronimo/branches/1.1/etc/explicit_versions.properties Fri May 5 21:03:29
2006
@@ -45,7 +45,7 @@
howl///=0.1.11
#security:
hsqldb///=1.7.2.2
-jasper///=5.5.12
+jasper///=5.5.15
javacc///=2.1
jdbm///=0.20-dev
jdom///=1.0
@@ -73,8 +73,8 @@
standard_taglibs///=1.1.1
stax/stax//jar=1.1.1-dev
stax/stax_api//jar=1.0
-tomcat_ajp///=5.5.9
-tomcat///=5.5.9
+tomcat_ajp///=5.5.15
+tomcat///=5.5.15
tomcat_servlet_examples///=5.5.15
tomcat_jsp_examples///=5.5.15
wadi///=2.0M1
Modified: geronimo/branches/1.1/etc/project.properties
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/etc/project.properties?rev=400233&r1=400232&r2=400233&view=diff
==
--- geronimo/branches/1.1/etc/project.properties (original)
+++ geronimo/branches/1.1/etc/project.properties Fri May 5 21:03:29 2006
@@ -155,7 +155,7 @@
howl_version=0.1.11
#security:
hsqldb_version=1.7.2.2
-jasper_version=5.5.12
+jasper_version=5.5.15
javacc_version=2.1
jdbm_version=0.20-dev
jdom_version=1.0
@@ -183,8 +183,8 @@
standard_taglibs_version=1.1.1
stax_version=1.1.1-dev
stax_api_version=1.0
-tomcat_ajp_version=5.5.9
-tomcat_version=5.5.9
+tomcat_ajp_version=5.5.15
+tomcat_version=5.5.15
tomcat_servlet_examples_version=5.5.15
tomcat_jsp_examples_version=5.5.15
wadi_version=2.0M1
Modified:
geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java?rev=400233&r1=400232&r2=400233&view=diff
==
---
geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java
(original)
+++
geronimo/branches/1.1/modules/jetty-builder/src/java/org/apache/geronimo/jetty/deployment/JettyModuleBuilder.java
Fri May 5 21:03:29 2006
@@ -840,6 +840,7 @@
String servletName =
servletType.getServletName().getStringValue().trim();
AbstractName servletAbstractName =
earContext.getNaming().createChildName(webModuleName, servletName,
NameFactory.SERVLET);
GBeanData servletData;
+Map initParams = new HashMap();
if (servletType.isSetServletClass()) {
String servletClassName =
servletType.getServletClass().getStringValue().trim();
Class servletClass;
@@ -872,6 +873,7 @
Re: Commit configId to moduleId?
I also was just about to suggest a .module extension, but after further thought, having an extension longer than three characters is likely to reintroduce the filename length issues (under geronimo\repository) on Windows during the builds. How about .mod or .mdl. John Jason Dillon wrote: I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. I think that the ear/war/rar thing is lame to start with, the folks that continue to use the same lame extension naming system (sar, har, dar, car) just perpetuate this silly system that Sun dropped on us. If we need to use extensions to clarify what something is, then lets use something more sensible. Like for a module, why not just use .module? If you want to still say its a jar, then .module.jar, but please lets not make it a .mar. --jason On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: Sounds like the consensus is to change it (although I don't remember a formal vote although I do remember the discussion). For my part it sounds like we're changing the configId to moduleId to decrease confusion. It seems odd that the modules are called CARs (Configuration Archives) or some such thing. I think we're making the server more confusing because now less things actually line up from a naming perspective. It just doesn't feel like we're giving our users a lot of stability. As David said, Just my $0.02. I would like to see more input from people though. I've been travelling so I must have missed the vote to put it in. Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from "configuration" to "module" o Renamed environment element from "configId" to "moduleId" o Renamed schema from "geronimo-config-1.1.xsd" to "geronimo-module-1.1.xsd" Based on conversations over the past few days, I think we all agree that "configuration" is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
