Re: Discuss: Move Geronimo to Attic
I have not been active for a long time, so I will also be leaving. On Mar 26, 2017 3:08 PM, "Jason Dillon" wrote: I will be leaving as well. —jason On March 26, 2017 at 12:01:05 PM, Kevan Miller (kevan.mil...@gmail.com) wrote: I'll be leaving. On Fri, Mar 24, 2017 at 4:21 PM, Romain Manni-Bucau wrote: > +1 > > Le 25 mars 2017 00:17, "David Jencks" a écrit : > >> I like this approach. Thank you for making a concrete suggestion and >> taking the lead. I intend to stay on the PMC and at least occasionally help >> out. >> >> david jencks >> >> > On Mar 24, 2017, at 8:55 AM, Mark Struberg wrote: >> > >> > Of course we do not have a huge community. But a very long lasting one. >> And there is not really standstill. There have been 64 committs in the last >> 3 monts. This is actually not too bad! >> > >> > So how to move on? >> > >> > Who wants to remain active in the PMC? Who wants to leave? >> > >> > We already pinned down the parts where there certainly IS community. >> > In addition to that I would like to bring in Geronimo-Config as an >> implementation of the Microprofile-Config specification. >> > Discussions have been going on last year all work has been done by me >> on my github account. But would love to bring it over here. >> > >> > I'll dig the old projects charter and try to kick off a reboot together >> with Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to >> have a helping hand from time to time. Note that everyone is welcome, even >> if he currently has no time to commit but only wants to provide guide and >> feedback. >> > >> > The first step I recommend is be to merge various mailing lists >> together. >> > Then we need to verify the charter and probably tweak it for the new >> goal. >> > We also need to communicate that we do not further maintain the >> Geronimo Server parts. >> > >> > Any objection? >> > >> > LieGrue, >> > strub >> > >> > >> >> Am 13.03.2017 um 20:46 schrieb Kevan Miller : >> >> >> >> "need" and "in use" does not necessarily translate into community. The >> need for the geronimo components that have been discussed is not new. As >> far as I can tell, so far, that has not translated into a community. >> >> >> >> If we want to continue the project, demonstrate the community that is >> needed for the project to continue. As I stated previously, a good starting >> point: create a new charter for the project, identify active PMC >> members/committers, and obtain board approval. >> >> >> >> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg >> wrote: >> >> Hi Alan! >> >> >> >> There are quite a few things which fit into this scenario imo. >> >> >> >> I think we really miss some 'toolbox project' for EE components at the >> ASF. >> >> There was a tendency to make all those projects own TLPs for some >> time. But that approach simply doesn't scale, and we end up with the same >> people in most of those projects anyway. >> >> So moving the ones with lower activity into a common TLP would solve >> this problem. Geronimo could probably become this project. >> >> >> >> There are a lot old EE folks around which have tremendous knowledge. >> And there are certain technologies which are really cool, but have the >> classical EE-lifecycle up-down in terms of activity. >> >> That + the already existing components could be a great chance. >> >> >> >> As you already said yourself: the terms of the big fat EE servers is >> over. But nevertheless the technology and requirement behind most of the >> single parts is still valid and often unbeaten. >> >> But nowadays it's more about making it easy to plug & play those >> technology libs together more freely as they are needed. Thus moving the >> focus on maintaining the components and not the server could be really >> appreciated by the community. >> >> >> >> You said there will be community if there is a need. I fully agree, >> and even more I see a need for those parts. >> >> >> >> LieGrue, >> >> strub >> >> >> >>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera : >> >>> >> >>> After a good night’s sleep, I re-read this thread and I’ll respond >> without trying to guide you in where and how you decide to go with your >> efforts; thanks in advance for letting me reboot my reply. :) >> >>> >> >>> Any pivot that this community decides upon, will have to be justified >> to the ASF board. We will need to explain what will be different and >> justify how it will generate sustainable community activity. With regards >> to that, I have two general concerns: >> >>> • Will this this specific endeavor generate any new sustainable >> community activity? >> >>> • Will any new activity of this specific endeavor represent >> activity that is unique to Geronimo or are we doing the chores of other >> projects to provide the appearance of activity? >> >>> The current level activity, is due to spec maintenance for downstream >> dependencies and we must admit that it is quite low. Being an upstream >> “aggregator” does not
Re: Welcome Chi Run Hua as a new Geronimo committer
Congrats! ~Jason Warner On Fri, May 20, 2011 at 10:25 PM, Shawn Jiang wrote: > Congrats, Chi Run Hua ! > > On Fri, May 20, 2011 at 11:32 PM, Ivan wrote: >> >> I would like to welcome chi run hua on aboard, as he recently accepted >> the Geronimo PMC invitation to become a committer. His account was >> just created , so you should start seeing some commits from him soon. >> >> -- >> Ivan > > > > -- > Shawn >
Re: [ANNOUNCE] Congrats Donald Woods! New ASF Member
Congrats indeed. ~Jason Warner On Sun, May 2, 2010 at 9:28 AM, Kevan Miller wrote: > Wanted to let the Geronimo community know that Donald Woods is a new member > of the ASF. The ASF membership elected Donald in recognition of his many > contributions to Geronimo, OpenJPA, and Incubator projects. > > Congrats to Donald on this well deserved achievement! > > --kevan
Re: [ANNOUNCE] Ashish Jain - Geronimo's newest committer
Congrats, Ashish! ~Jason Warner On Sun, Mar 14, 2010 at 4:44 PM, Joe Bohn wrote: > All, > > Please join me in welcoming Ashish Jain as the newest committer on the > Apache Geronimo project. The Geronimo PMC is excited that Ashish has > accepted our invitation. > > Congratulations Ashish and keep up the good work! > > Joe >
Re: Welcome "Forrest" Ming Xia as a new committer
Congrats! ~Jason Warner On Thu, Mar 11, 2010 at 3:04 PM, Jay D. McHugh wrote: > Congratulations Forrest! > > Jay > > Kevan Miller wrote: > > Congrats Forrest! > > --kevan > > > > On Mar 8, 2010, at 8:54 PM, Ivan wrote: > > > >> I would like to welcome Forrest aboard, as he recently accepted the > Geronimo PMC invitation to become a committer. His account (xiaming) was > just created, so you should start seeing some commits from him soon. > >> > >> -- > >> Ivan > > >
Re: Re: Geronimo JPA 2.0 API
Donald, I believe that information is OSGi Alliance confidential that I can not discuss. Thanks, ~Jason Warner On Mon, Feb 1, 2010 at 10:23 AM, Donald Woods wrote: > Still don't like the version decision by the EEG, but guess I'll have to > update the Geronimo spec and spin another release before the final > OpenJPA 2.0.0 release. > > Jason, does the RFC 143 TCK check for expected/required metadata on the > jars? > > > -Donald > > > Original Message > Subject: Re: Geronimo JPA 2.0 API > Date: Mon, 01 Feb 2010 10:04:45 + > From: Ian Robinson > Reply-To: aries-...@incubator.apache.org > To: aries-...@incubator.apache.org > > While there is a lot of discussion in the OSGi EEG about *future* > versioning policy for APIs defined outside OSGi, there was a final > decision for JPA in the OSGi 4.2 Enterprise Specification. Which is that > the JPA 2.0 API packages should be exported as version 1.1 with a 'jpa' > attribute indicating the spec version. For example: > Export-Package: javax.persistence; version=1.1; jpa=2.0 > And the RI will be changed in line with this. I believe the RI may also > export the API packages at 2.0 but the spec won't require this. > - Ian > > 1.1 API a JPA 2.0 provider Fi for the > > On 20/01/2010 21:48, David Jencks wrote: > > Isn't there a lot of discussion of how to connect jsr versions to > > package versions? I haven't seen any conclusions. To me it seems > > obvious that if the osgi package version isn't equal to the jsr spec > > version (with suitable transformations for stuff like 1.1-MR3 jsr > > versions) the osgi ee effort will be practically unusable. > > > > So, I think the geronimo jar is packaged correctly. > > > > thanks > > david jencks > > > > On Jan 20, 2010, at 8:39 AM, Timothy Ward wrote: > > > >> > >> Hi, > >> > >> In testing I have found that the Geronimo JPA API is being exported > >> at the wrong version in its bundle manifest. As the JPA version 2.0 > >> API is compatible with version 1.0, the OSGi version for those > >> packages should be 1.1.0, not 2.0.0. > >> > >> What do people think the best solution for this is? We can either > >> raise a JIRA against Geronimo to get this fixed, or we can re-package > >> the API within Aries using the correct OSGi version. > >> > >> Regards, > >> > >> Tim > >> > >> _ > >> Tell us your greatest, weirdest and funniest Hotmail stories > >> http://clk.atdmt.com/UKM/go/195013117/direct/01/ > > > > > >
Re: [VOTE] geronimo 2.2 release (2nd try)
+1 from me. I built the server and then ran the full tck successfully. ~Jason Warner On Thu, Dec 10, 2009 at 5:46 AM, Rick McGuire wrote: > I was sort of waiting for a decision on whether those couple of problems > raised in the discuss thread were blockers or not. I guess they're not, so > here's my +1 too. > > Rick > > Kevan Miller wrote: > >> Here's my +1. >> I reviewed the source and binaries in >> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/ >> >> --kevan >> >> On Dec 8, 2009, at 2:56 AM, David Jencks wrote: >> >> I've managed to come up with a 2nd 2.2 release candidate built using the >>> maven-release-plugin. >>> >>> This includes Kevan;s fixes of source headers and a warning removal. >>> >>> See the jira issues here: >>> >>> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965< >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965 >>> > >>> >>> Staged to >>> >>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/< >>> https://repository.apache.org/content/repositories/orgapachegeronimo-024 >>> > >>> >>> >>> The main artifacts up for vote are the source release archives >>> >>> >>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz< >>> https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz >>> > >>> >>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip< >>> https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip >>> > >>> >>> >>> If you vote you should at least examine these and make sure something >>> plausible builds from them. >>> >>> >>> [ ] +1 about time to push this out the door >>> [ ] 0 no opinion >>> [ ] -1 not this one (please explain why) >>> >>> Many thanks >>> david jencks >>> >> >> >
Re: Help me to build a geronimo server form the source
I just ran into this issue building the server with a clean maven
repository. Could the issue be with the dependency available in the online
repository?
~Jason Warner
On Mon, Nov 9, 2009 at 1:55 PM, Donald Woods wrote:
> Try deleting everything under -
>
>C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\
> and running the build again. Until your first build completes, you may
> have to keep retrying until all of the build dependencies have been
> downloaded
>
>
> -Donald
>
>
> Fei LI wrote:
>
>> Hi Chi Run-up and other developers,
>> I got another build failure for building the server from SVEN branch 2.2.
>> My environment are:
>> "
>> C:\g22>man -version
>> Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
>> Java version: 1.6.0_16
>> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>> "
>> The error is:
>> "
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/maven-monitor/2.0.6/maven-monitor-2.0.6.jar
>> [INFO] [enforcer:enforce {execution: default}]
>> [INFO] [plugin:descriptor {execution: default-descriptor}]
>> [INFO] Using 'UTF-8' encoding to read mojo metadata.
>> [INFO] Applying mojo extractor for language: java
>> [WARNING] org.apache.geronimo.mavenplugins.car.ArchiveCarMojo#jarArchiver:
>> [WARNING] The syntax
>> [WARNING] @parameter expression="${component.#}"
>> [WARNING] is deprecated, please use
>> [WARNING] @component role="" roleHint=""
>> [WARNING] instead.
>> [INFO] Mojo extractor for language: java found 10 mojo descriptors.
>> [INFO] Applying mojo extractor for language: bsh
>> [INFO] Mojo extractor for language: bsh found 0 mojo descriptors.
>> [INFO] [remote-resources:process {execution: default}]
>> [WARNING] Invalid project model for artifact
>> [sxc-runtime:com.envoisolutions.sxc:0.7.2]. It will be ignored by the remote
>> resources Mojo.
>> [INFO] [resources:resources {execution: default-resources}]
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 1 resource
>> [INFO] skip non existing resourceDirectory
>> C:\g22\framework\buildsupport\car-maven-plugin\src\main\filtered-resources
>> [INFO] Copying 3 resources
>> [INFO] [compiler:compile {execution: default-compile}]
>> [INFO] Compiling 20 source files to
>> C:\g22\framework\buildsupport\car-maven-plugin\target\classes
>> [INFO]
>>
>> [ERROR] BUILD FAILURE
>> [INFO]
>>
>> [INFO] Compilation failure
>> error: error reading
>> C:\m2repo\com\envoisolutions\sxc\sxc-runtime\0.7.2\sxc-runtime-0.7.2.jar;
>> error in opening zip file
>> [INFO]
>>
>> [INFO] For more information, run Maven with the -e switch
>> [INFO]
>>
>> [INFO] Total time: 11 minutes 9 seconds
>> [INFO] Finished at: Mon Nov 09 13:10:16 EST 2009
>> [INFO] Final Memory: 202M/387M
>> [INFO]
>>
>> "
>> Thanks
>> Fei Li
>>
>>
>> *From:* chi runhua [mailto:chirun...@gmail.com]
>> *Sent:* Monday, November 09, 2009 12:00 PM
>> *To:* dev@geronimo.apache.org
>> *Subject:* Re: Help me to build a geronimo server form the source
>>
>> I can build branch/2.2 with JDK1.6 on Ubuntu9.04 successfully.
>> You may post your 2.2 build log here so that we can take a look what the
>> problem is.
>> Jeff C
>>
>> On Tue, Nov 10, 2009 at 12:39 AM, Fei LI > f...@mdacorporation.com>> wrote:
>>
>>
>>Hi,
>>
>>I am creaming here for your help.
>>
>>I have been trying to build a Geronimo server from the SVN source
>>for 1.5 weeks and no success.
>>
>>Donald Woods and Forrest Xia helped me to try many ways and all are
>>failed. I tried many combination of the build environment:
>>
>>SVN Tags/2.1.4
>>SVN Trunk
>>Maven 2.0.10
>>Maven 2.2.1
>>Java jsdk 1..5.0_22
>>Java jsdk 1.6.0_16
>>
>>Nothing works.
>>
>>So who can tell me what to try next. I never build software like
>>this. Surprise! Isn't it?
>>
>>Thanks
>>
>>Fei Li
>>
>>
>>
>>
>>
>>
Re: svn commit: r823543 - in /geronimo/server/trunk/plugins/activemq: activemq-webconsole-jetty/src/main/history/dependencies.xml activemq-webconsole-tomcat/src/main/history/dependencies.xml
I went ahead and made the change so we could get the tck tests to build, but the change can be reverted if it turns out to not be something we want to keep. ~Jason Warner On Sun, Oct 11, 2009 at 10:30 PM, Donald Woods wrote: > Was waiting to here if we really needed to pull in this new dependency into > the assemblies or not > > Also, the size of the activemq-webconsole.war is around 30MB, which seems > like a lot to add to our assemblies. > > > -Donald > > > Jason Warner wrote: > >> Donald, >> >> Is there a reason you didn't make the same changes in the branches/2.2 >> dependencies.xml files? If not, I can make that change. >> >> ~Jason Warner >> >> >> On Fri, Oct 9, 2009 at 9:17 AM, > dwo...@apache.org>> wrote: >> >>Author: dwoods >>Date: Fri Oct 9 13:17:20 2009 >>New Revision: 823543 >> >>URL: http://svn.apache.org/viewvc?rev=823543&view=rev >><http://svn.apache.org/viewvc?rev=823543&view=rev> >>Log: >>update activemq-webconsole depends >> >>Modified: >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml >> >>Modified: >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml >>URL: >> >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff >>< >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff >> > >> >> >> == >>--- >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml >>(original) >>+++ >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml >>Fri Oct 9 13:17:20 2009 >>@@ -121,4 +121,9 @@ >>xmlpull >>jar >> >>+ >>+jivesoftware >>+smack >>+jar >>+ >> >> >>Modified: >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml >>URL: >> >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff >>< >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff >> > >> >> >> == >>--- >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml >>(original) >>+++ >> >> >> geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml >>Fri Oct 9 13:17:20 2009 >>@@ -121,4 +121,9 @@ >>xmlpull >>jar >> >>+ >>+jivesoftware >>+smack >>+jar >>+ >> >> >> >> >>
Re: svn commit: r823543 - in /geronimo/server/trunk/plugins/activemq: activemq-webconsole-jetty/src/main/history/dependencies.xml activemq-webconsole-tomcat/src/main/history/dependencies.xml
Donald, Is there a reason you didn't make the same changes in the branches/2.2 dependencies.xml files? If not, I can make that change. ~Jason Warner On Fri, Oct 9, 2009 at 9:17 AM, wrote: > Author: dwoods > Date: Fri Oct 9 13:17:20 2009 > New Revision: 823543 > > URL: http://svn.apache.org/viewvc?rev=823543&view=rev > Log: > update activemq-webconsole depends > > Modified: > > > geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml > > > geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml > > Modified: > geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml > URL: > http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff > > == > --- > geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml > (original) > +++ > geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml > Fri Oct 9 13:17:20 2009 > @@ -121,4 +121,9 @@ > xmlpull > jar > > + > +jivesoftware > +smack > +jar > + > > > Modified: > geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml > URL: > http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml?rev=823543&r1=823542&r2=823543&view=diff > > == > --- > geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml > (original) > +++ > geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml > Fri Oct 9 13:17:20 2009 > @@ -121,4 +121,9 @@ > xmlpull > jar > > + > +jivesoftware > +smack > +jar > + > > > >
Re: Upgrade to activemq-protobuf version 1.0?
Ah, ok. Thanks for catching that. That'll teach me to look at things on a wednesday morning. ~Jason Warner On Wed, Sep 30, 2009 at 9:38 AM, Ivan wrote: > From the stack, it seems that activemq-core 5.3-snapshot depends on > activemq-protobuf 1.0-snapshot, not Geronimo depends on it directly. > One way is to wait the activemq 5.3, or use the exclude in our pom file to > use 1.0 temporarily ? > > 2009/9/30 Jason Warner > >> It looks like all our builds are reliant upon activemq-protobuf version >> 1.0-Snapshot. Activemq released version 1.0 of activemq-protobuf last >> week. Should we be upgrading? That should fix the build failures we've >> been having. >> >> ~Jason Warner >> > > > > -- > Ivan >
Upgrade to activemq-protobuf version 1.0?
It looks like all our builds are reliant upon activemq-protobuf version 1.0-Snapshot. Activemq released version 1.0 of activemq-protobuf last week. Should we be upgrading? That should fix the build failures we've been having. ~Jason Warner
Geronimo branches/2.2 build failure
The automated TCK tests are failing when building the geronimo server from the branches/2.2 source with a missing artifact error[1]. Missing: -- 1) org.apache.geronimo.components:geronimo-connector:jar:tests:2.1.3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.components -DartifactId=geronimo-connector -Dversion=2.1.3-20090910.160808-3 -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.components -DartifactId=geronimo-connector -Dversion=2.1.3-20090910.160808-3 -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.modules:geronimo-connector:jar:2.2-SNAPSHOT 2) org.apache.geronimo.components:geronimo-connector:jar:tests:2.1.3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-connector:jar:2.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots) ~Jason Warner
Re: Welcome "Rex" Lei Wang as a new committer
Congratulations! ~Jason Warner On Mon, Aug 31, 2009 at 6:48 PM, David Jencks wrote: > I would like to welcome Rex, as he recently accepted the Geronimo PMC > invitation to become a committer. We are still waiting for his account to > be created, but hope to get that straightened out shortly and start seeing > commits. > > Congratulations! > david jencks > >
Compilation failures on trunk
I'm seeing some compilation failures on trunk[1]. Does anyone else get the same error? I'm building using java version 1.5.0 update 19 on a mac. The TCK builds are seeing the same failures as well, and they run using the same java version but on linux. [1] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[46,49] cannot find symbol symbol : class SessionCachingAuthenticator location: package org.eclipse.jetty.security.authentication /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[90,23] [deprecation] getHeaderBufferSize() in org.eclipse.jetty.http.HttpBuffers has been deprecated /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java:[93,16] [deprecation] setHeaderBufferSize(int) in org.eclipse.jetty.http.HttpBuffers has been deprecated /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/auth/JAASLoginService.java:[40,7] org.apache.geronimo.jetty7.security.auth.JAASLoginService is not abstract and does not override abstract method validate(org.eclipse.jetty.server.UserIdentity) in org.eclipse.jetty.security.LoginService /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,32] cannot find symbol symbol : class SessionCachingAuthenticator location: class org.apache.geronimo.jetty7.security.JettySecurityHandlerFactory /Users/jason/trunk/plugins/jetty7/geronimo-jetty7/src/main/java/org/apache/geronimo/jetty7/security/JettySecurityHandlerFactory.java:[102,60] cannot find symbol symbol : constructor FormAuthenticator(java.lang.String,java.lang.String) location: class org.eclipse.jetty.security.authentication.FormAuthenticator ~Jason Warner
Re: 2.2 docs index confusion?
How often do you check? It was my understanding that it could sometimes take close to an hour before the wiki page was updated even though the confluence display was updated sooner. Is it still not updated after an hour or two? ~Jason Warner On Sun, Jun 7, 2009 at 10:20 PM, Ying Tang wrote: > Thanks, Donald. > We notice that only URLs such as > http://cwiki.apache.org/confluence/display/GMOxDOC22/Documentation are > updated minutes after editing. URLs like > http://cwiki.apache.org/GMOxDOC22/ are often out of date. > > Best Regards, > > Ying Tang > > 2009/6/5, Donald Woods : > > I just triggered an export. Unfortunately, this can only be done by a > > Confluence Admin Not sure why it's not happening after edits. Have > > you verified that the following location is updated within a couple > > minutes after editing, which is the autoexport stagging location, before > > the files are copied to the normal docs location? > > http://cwiki.apache.org/GMOxDOC22/ > > > > > > -Donald > > > > > > Ying Tang wrote: > >> Hi all, > >> > >> Can someone help trigger the export for Confluence documents > >> periodically? Or do we need a script to build documents every day ? > >> > >> If possible, I may help with this task. > >> > >> Best Regards, > >> > >> Ying Tang > >> > >> 2009/1/5 Ying Tang >> <mailto:yingtang1...@gmail.com>> > >> > >> Thanks, Donald. It worked well after the autoexport. > >> Unfortunately we found that our latest changes did not appear on > >> that index page > >> Maybe we have to manually trigger the autoexport from time to time? > >> > >> > >> > >> > >> 2009/1/1 Donald Woods mailto:dwo...@apache.org > >> > >> > >> I just manually ran the autoexport plugin on GMOxDOC22, so give > >> it 1-2 hours to see if the static webpages reflect the live > >> Confluence content... > >> > >> > >> -Donald > >> > >> > >> Ying Tang wrote: > >> > >> >From this page http://cwiki.apache.org/, we were told > >> that the index page http://cwiki.apache.org/GMOxDOC22/ > >> <http://cwiki.apache.org/GMOxDOC22/> was last modified on > >> Nov 19, 2008. > >> The index page is in fact a link to the documentation page > >> > >> http://cwiki.apache.org/confluence/display/GMOxDOC22/Documentation. > >> All changes to the documentation page after Nov 19 are not > >> available on the index page. > >> > >> We guess this index page cannot be updated by Confluence > >> automatically, as it is a copy on the server. Maybe someone > >> can help trigger the build on the server, so that the > >> latest changes will take effect. > >> > >> > >> 2008/12/31 chi runhua >> <mailto:chirun...@gmail.com> <mailto:chirun...@gmail.com > >> <mailto:chirun...@gmail.com>>> > >> > >> > >> > >>Looks like the wiki server keeps 2 copies of GMOXDOC22, > >> changes of > >>doc structure was not synchronized. > >> > >> > >>Jeff > >> > >> > >>On Wed, Dec 31, 2008 at 7:33 AM, David Jencks > >>mailto:david_jen...@yahoo.com> > >> <mailto:david_jen...@yahoo.com > >> <mailto:david_jen...@yahoo.com>>> wrote: > >> > >>I''m confused. Starting on > >> http://cwiki.apache.org/GMOxDOC22/ > >> > >>I see... > >> > >># > >> > >> * Custom server assemblies > >> o Buidling,installing plugins and extracting > >> a server > >>from an exsiting server > >> o Assembling a server using Maven > >> > >> > >>but the link for the first line shows a sub-index > >> that doesn't > >>include either of the items beneath it, it has 3 > >> unrelated entries. > >> > >>??? > >> > >>More seriously when I try to edit the page > >> > >> > >> > http://cwiki.apache.org/GMOxDOC22/buidlinginstalling-plugins-and-extracting-a-server-from-an-exsiting-server.html > >> to > >>correct the spelling I get to the page > >> > >> > >> http://cwiki.apache.org/confluence/pages/editpage.action?pageId=101843 > >>which is "Assembling a server via command line" > >> > >>??? ??? ??? > >> > >>thanks > >>david jencks > >> > >> > >> > >> > >> > > >
Re: How to build genesis until assembly plugin beta-4 is released
Hi David, Do we have an estimated date for when trunk will be able to build cleanly again? It's difficult to change the AHP builds to build other projects first, and I don't really want to do that unless these requirements are going to be around for a while. Thanks, ~Jason Warner On Sat, May 30, 2009 at 10:55 AM, David Jencks wrote: > I saw some odd behavior with the release candidate for the assembly plugin > beta-4 (source archives are being built twice) so I committed changes in > genesis that rely on this version to make it easier for people to reproduce. > So if you want to build genesis trunk (needed for g. trunk) you need to > make the staging repo available such as by adding it to your nexus repo list > and released group. > > https://repository.apache.org/content/repositories/maven-staging-035 > > thanks > david jencks > >
Re: DEVTOOLS trunk build failed
Why not open a jira for this and then attach a patch? That would make it much easier to apply the change. Thanks for looking into this! On Mon, Apr 20, 2009 at 5:34 AM, Delos wrote: > Hi, > > Devtools trunk build failed in org.apache.geronimo.runtime.v21 plugin. The > reason is some 2.1.4-snapshot package still exist in the Manifest.MF. Since > 2.1.4 has released, all the "snapshot" can be removed. Then, devtools trunk > can be successfully. > > Here is the change of Manifest.mf in org.apache.geronimo.runtime.v21: > > > change > > > "Bundle-ClassPath: lib/geronimo-common-2.1.4-SNAPSHOT.jar, > lib/geronimo-deploy-jsr88-2.1.4-SNAPSHOT.jar, > lib/geronimo-deployment-2.1.4-SNAPSHOT.jar, > lib/geronimo-j2ee-schema-2.1.4-SNAPSHOT.jar, > lib/geronimo-kernel-2.1.4-SNAPSHOT.jar, > lib/geronimo-plugin-2.1.4-SNAPSHOT.jar, > lib/geronimo-system-2.1.4-SNAPSHOT.jar, > lib/geronimo-util-2.1.4-SNAPSHOT.jar, > lib/geronimo-deploy-config-2.1.4-SNAPSHOT.jar, > lib/geronimo-javaee-deployment_1.1MR3_spec-1.0.jar, > lib/plexus-archiver-1.0-alpha-7.jar, > lib/geronimo-crypto-2.1.4-SNAPSHOT.jar, > lib/slf4j-api-1.4.3.jar, > lib/slf4j-simple-1.4.3.jar" > > into > > " > Bundle-ClassPath: lib/geronimo-common-2.1.4.jar, > lib/geronimo-deploy-jsr88-2.1.4.jar, > lib/geronimo-deployment-2.1.4.jar, > lib/geronimo-j2ee-schema-2.1.4.jar, > lib/geronimo-kernel-2.1.4.jar, > lib/geronimo-plugin-2.1.4.jar, > lib/geronimo-system-2.1.4.jar, > lib/geronimo-util-2.1.4.jar, > lib/geronimo-deploy-config-2.1.4.jar, > lib/geronimo-javaee-deployment_1.1MR3_spec-1.0.jar, > lib/plexus-archiver-1.0-alpha-7.jar, > lib/geronimo-crypto-2.1.4.jar, > lib/slf4j-api-1.4.3.jar, > lib/slf4j-simple-1.4.3.jar > " > > Thanks! > > > > -- ~Jason Warner
Re: Adding a repository to the server trunk build
Ah, I see. Thanks for the info. I'll commit that change, then. On Fri, Apr 17, 2009 at 12:13 PM, Donald Woods wrote: > Default repos are provided by Genesis. > > IMO, for now go ahead and add the snapshot repo into the server's root > pom.xml so we can get the builds working again, until someone updates the > Genesis 1.5.x branch to include both the nexus snapshot and release repos > and pushes out a new snapshot build to use with 2.2. > > > -Donald > > > > Jason Warner wrote: > >> It seems that the recent build failures in trunk are caused by the camel >> project switching the location of their snapshot repository. They now >> deploy their snapshots the apache nexus repository found at >> https://repository.apache.org/content/repositories/snapshot. I added >> this to my pom.xml and was able to successfully build the server. I suggest >> adding this repository entry to our list of repositories permanently. I'd >> be happy to do that, but I'm not sure if the root pom.xml is the appropriate >> place. It seems that most of our repositories are picked up from somewhere >> outside of the root pom, though I'm not quite sure where. I'm sure someone >> else more familiar with how we grab our repository list will be able to >> enlighten me on this matter. >> >> Thanks! >> >> -- >> ~Jason Warner >> > -- ~Jason Warner
Adding a repository to the server trunk build
It seems that the recent build failures in trunk are caused by the camel project switching the location of their snapshot repository. They now deploy their snapshots the apache nexus repository found at https://repository.apache.org/content/repositories/snapshot. I added this to my pom.xml and was able to successfully build the server. I suggest adding this repository entry to our list of repositories permanently. I'd be happy to do that, but I'm not sure if the root pom.xml is the appropriate place. It seems that most of our repositories are picked up from somewhere outside of the root pom, though I'm not quite sure where. I'm sure someone else more familiar with how we grab our repository list will be able to enlighten me on this matter. Thanks! -- ~Jason Warner
Re: [VOTE] Release Geronimo Server 2.1.4 RC2
+1 TCK passed. On Fri, Mar 27, 2009 at 8:11 PM, Tim McConnell wrote: > +1 > > > Joe Bohn wrote: > >> All, >> >> I've prepared a second release candidate (RC2) of Geronimo Server 2.1.4 >> for your review and vote. >> >> The only differences from rc1 are: >> - addition of a missing license header in >> plugins/console/console-filter/src/main/resources/XSRF.js >> - removal of an extraneous "(TBD)" in README.txt >> >> >> The source for rc2 is Rev758842 from the following svn branch: >> https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.4/ >> >> When the release vote is approved, I will svn mv the code to: >> https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.4/ >> >> An archive of this source code can be found here: >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.tar.gz<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.tar.gz> >> OR >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-2.1.4-src.zip> >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/>contains >> the 10 server binary distributions to be released (framework, >> tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, >> README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the >> release. These extra txt files were included so that they could be >> leveraged by GEP if necessary (they are also included in the assembly >> images). >> >> For your convenience, here are pointers to the urls for the >> distributions in zip format: >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-javaee5-2.1.4-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-javaee5-2.1.4-bin.zip> >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-minimal-2.1.4-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-jetty6-minimal-2.1.4-bin.zip> >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-javaee5-2.1.4-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-javaee5-2.1.4-bin.zip> >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-minimal-2.1.4-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-tomcat6-minimal-2.1.4-bin.zip> >> >> http://people.apache.org/~jbohn/geronimo-2.1.4-dist-rc2/geronimo-framework-2.1.4-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.4-dist-rc2/geronimo-framework-2.1.4-bin.zip> >> >> >> The maven artifacts for the release can be found here: >> >> http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.4-rc2/<http://people.apache.org/%7Ejbohn/staging-repo/geronimo-2.1.4-rc2/> >> >> When the release vote is approved, these maven artifacts will be moved >> to the m2-ibiblio-rsync-repository at Apache. >> >> >> [ ] +1 Release Geronimo Server 2.1.4 >> [ ] 0 No opinion >> [ ] -1 Do not release Geronimo Server 2.1.4 (please provide rationale) >> >> >> The voting will be open for 72 hours or until sufficient input has been >> received and the tck results have been verified. >> >> Thanks, >> Joe >> >> > -- > Thanks, > Tim McConnell > -- ~Jason Warner
Re: Welcome "ivan" Hai Hong Xu as a new committer
Congratulations! On Fri, Mar 6, 2009 at 12:24 PM, Joe Bohn wrote: > Congrats Ivan! > > Joe > > > > Donald Woods wrote: > >> I would like to welcome Ivan aboard, as he recently accepted the Geronimo >> PMC invitation to become a committer. His account was just created this >> morning (xuhaihong), so you should start seeing some commits from him soon. >> >> >> -Donald >> >> > -- ~Jason Warner
Re: [BUILD] trunk: Failed for Revision: 747769
er.java:430) >>at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> Caused by: org.apache.maven.project.InvalidProjectModelException: Failed >> to validate POM for project >> org.apache.geronimo.configs:plugin-farm-datasource at >> /home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-datasource/pom.xml >>at >> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108) >>at >> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878) >>at >> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) >>at >> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) >>at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) >>at >> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) >>at >> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) >>at >> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) >>at >> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534) >>at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) >>... 11 more >> [INFO] >> >> [INFO] Total time: 33 seconds >> [INFO] Finished at: Wed Feb 25 09:03:28 EST 2009 >> [INFO] Final Memory: 50M/565M >> [INFO] >> >> > > -- ~Jason Warner
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674612#action_12674612
]
Jason Warner commented on GERONIMO-3759:
Your config.xml is missing the module entry for mconsole-ds. I'm not sure why
this is. There could be a number of reasons. I suggest you start with a fresh
server and copy only the changes necessary from any external config.xml. For
example, start with the default config.xml and copy over only the necessary
clustering config from the attached config_ag21.xml. I'm not sure how you lost
the mconsole-ds module since it seems to be present both in the config_ag21.xml
as well as the default config.xml that my server build starts with. For
clarification, I ran this on Geronimo Tomcat Java EE 5 2.1.3. If you have any
further trouble with this, please post questions to the user list with a
reference to this jira. I don't believe the comment section of a long closed
jira is the best place for discussing bugs that aren't really related to the
changes made in relation to that jira.
> Geronimo Tomcat Clustering - No GBeans for adding Static Members
>
>
> Key: GERONIMO-3759
> URL: https://issues.apache.org/jira/browse/GERONIMO-3759
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1, 2.1.1
> Reporter: Shiva Kumar H R
>Assignee: Jason Warner
> Fix For: 2.1.3, 2.2
>
> Attachments: ClusteringStaticMembers_GERONIMO-3759.patch, config.xml,
> config_ag21.xml, tomcat_server.xml
>
>
> Tomcat uses multicasting for discovering cluster members. It also supports
> static memberships using the StaticMembershipInterceptor if you want to
> extend your membership to points beyond multicasting, using configuration as
> below:
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> port="5678"
> securePort="-1"
> host="tomcat01.mydomain.com"
> domain="staging-cluster"
> uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>
>
> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
> http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
> However, to add this configuration in Geronimo's config.xml, we don't have
> the required GBeans for element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release gshell 1.0-alpha2
+1 On Tue, Feb 17, 2009 at 11:45 AM, Joe Bohn wrote: > +1 (assuming the discussion issue I raised is really a non-issue). > > Joe > > > Guillaume Nodet wrote: > >> I've uploaded a release of gshell 1.0-alpha2. >> >> The staging repo is available at: >> >> http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2<http://people.apache.org/%7Egnodet/staging/gshell-1.0-alpha2> >> The svn tag is: >> >> https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/ >> >> Please review and vote ! >> >> [ ] +1 Release gshell-1.0-alpha2 >> [ ] -1 Do not >> >> >> > -- ~Jason Warner
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671994#action_12671994
]
Jason Warner commented on GERONIMO-3759:
If you're still having trouble with this, please post the config.xml that you
are using. I just attempted to start the server using the configuration
provided here and had no issues.
> Geronimo Tomcat Clustering - No GBeans for adding Static Members
>
>
> Key: GERONIMO-3759
> URL: https://issues.apache.org/jira/browse/GERONIMO-3759
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1, 2.1.1
>Reporter: Shiva Kumar H R
>Assignee: Jason Warner
> Fix For: 2.1.3, 2.2
>
> Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
> config_ag21.xml, tomcat_server.xml
>
>
> Tomcat uses multicasting for discovering cluster members. It also supports
> static memberships using the StaticMembershipInterceptor if you want to
> extend your membership to points beyond multicasting, using configuration as
> below:
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> port="5678"
> securePort="-1"
> host="tomcat01.mydomain.com"
> domain="staging-cluster"
> uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>
>
> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
> http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
> However, to add this configuration in Geronimo's config.xml, we don't have
> the required GBeans for element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670895#action_12670895
]
Jason Warner commented on GERONIMO-3759:
I'm not sure what specifically the error you receive has to do with this jira
other than that you're using the config.xml posted here, which also confuses
me. What are you attempting to do?
> Geronimo Tomcat Clustering - No GBeans for adding Static Members
>
>
> Key: GERONIMO-3759
> URL: https://issues.apache.org/jira/browse/GERONIMO-3759
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1, 2.1.1
>Reporter: Shiva Kumar H R
>Assignee: Jason Warner
> Fix For: 2.1.3, 2.2
>
> Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
> config_ag21.xml, tomcat_server.xml
>
>
> Tomcat uses multicasting for discovering cluster members. It also supports
> static memberships using the StaticMembershipInterceptor if you want to
> extend your membership to points beyond multicasting, using configuration as
> below:
> className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
> port="5678"
> securePort="-1"
> host="tomcat01.mydomain.com"
> domain="staging-cluster"
> uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>
>
> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
> http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
> However, to add this configuration in Geronimo's config.xml, we don't have
> the required GBeans for element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Please help me unsubscribe... Tried different things on the Nabble page
Have you tried sending an email to dev-unsubscr...@geronimo.apache.org as described in http://geronimo.apache.org/mailing-lists.html? On Thu, Jan 22, 2009 at 11:42 AM, Jørn Larsen wrote: > > -- > -- > Joern Larsen > CEO > >WHO'S AT JAOO? - http://www.jaoo.dk > --- > Trifork, Margrethepladsen 4, 8000 Århus C, Denmark > Tel: +45 8732 8787 / Fax: +45 8732 8788 / Mob: +45 4072 8483 > -- ~Jason Warner
Re: svn update performance
You're not alone On Tue, Jan 13, 2009 at 3:39 PM, Tim McConnell wrote: > Is anyone other than me experiencing extremely slow svn performance, > especially when updating the Geronimo server trunk ?? Yesterday and today > have been excruciatingly slow. > > -- > Thanks, > Tim McConnell > -- ~Jason Warner
Re: svn commit: r732905 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
Thanks for the tip!
On Thu, Jan 8, 2009 at 8:43 PM, Jason Dillon wrote:
> FYI, you should be able to just use iterModel.name, or if you want
> something like:
>
>def zipName = "${targetDir}/logs/${iterModel.name}.zip"
>
> --jason
>
>
>
> On Jan 9, 2009, at 8:38 AM, jawar...@apache.org wrote:
>
> Author: jawarner
>> Date: Thu Jan 8 17:38:03 2009
>> New Revision: 732905
>>
>> URL: http://svn.apache.org/viewvc?rev=732905&view=rev
>> Log:
>> Fixing typo in zip file name
>>
>> Modified:
>>
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
>>
>> Modified:
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
>> URL:
>> http://svn.apache.org/viewvc/geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy?rev=732905&r1=732904&r2=732905&view=diff
>>
>> ==
>> ---
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
>> (original)
>> +++
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
>> Thu Jan 8 17:38:03 2009
>> @@ -240,7 +240,7 @@
>>}
>>
>>// Zip relevant logs for posting on iteration page for
>> download
>> -def zipName = targetDir + "/logs/" iterModel.getName() +
>> ".zip"
>> +def zipName = targetDir + "/logs/" + iterModel.getName() +
>> ".zip"
>>
>>ant.zip(destfile: zipName) {
>>zipfileset( dir: workDir, includes: 'logs/' )
>>
>>
>>
>
--
~Jason Warner
Re: svn commit: r732011 - in /geronimo/server/trunk/plugins/console/console-base-portlets/src/main: resources/ webapp/WEB-INF/view/configmanager/ webapp/WEB-INF/view/infomanager/
Looks like it was just a typo in the jsp. Think I fixed it... On Tue, Jan 6, 2009 at 1:21 PM, Jason Warner wrote: > I think this change might be causing build problems. A recent build failed > with the following error: > > Trace org.apache.jasper.JasperException: > file:/opt/anthill3/agent/var/jobs/projects/Geronimo_Server_Build/Geronimo_Server_Build_Workflow/project/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysMaximized.jsp(17,0) > file:/opt/anthill3/agent/var/jobs/projects/Geronimo_Server_Build/Geronimo_Server_Build_Workflow/project/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysNormal.jsp(135,70) > No tag "mes" defined in tag library imported with prefix "fmt" > at > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40) > at > org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407) > at > org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:88) > at > org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:345) > at > org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:378) > at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:486) > at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1444) > at org.apache.jasper.compiler.Parser.parse(Parser.java:138) > at > org.apache.jasper.compiler.ParserController.doParse(ParserController.java:216) > at > org.apache.jasper.compiler.ParserController.parse(ParserController.java:103) > at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:154) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:315) > at org.apache.jasper.JspC.processFile(JspC.java:1010) > at org.apache.jasper.JspC.execute(JspC.java:1159) > at > org.codehaus.mojo.jspc.compiler.tomcat6.JspCompilerImpl.compile(JspCompilerImpl.java:111) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86) > at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:912) > at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:756) > at > org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:766) > at > org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:754) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod0(ScriptBytecodeAdapter.java:198) > at > org.codehaus.mojo.jspc.CompilationMojoSupport.execute(CompilationMojoSupport.groovy:333) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > > On Tue, Jan 6, 2009 at 12:30 PM, wrote: > >> Author: dwoods >> Date: Tue Jan 6 09:30:41 2009 >> New Revision: 732011 >&
Re: svn commit: r732011 - in /geronimo/server/trunk/plugins/console/console-base-portlets/src/main: resources/ webapp/WEB-INF/view/configmanager/ webapp/WEB-INF/view/infomanager/
=
> ---
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/configmanager/normal.jsp
> (original)
> +++
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/configmanager/normal.jsp
> Tue Jan 6 09:30:41 2009
> @@ -214,7 +214,7 @@
>
>
>
> -
> +
>
> id="expertMode" onClick="toggleExpertMode();"
> /> key="configmanager.normal.expertMode" />
>
> @@ -222,16 +222,19 @@
>
> id="showDependenciesMode"
> onClick="toggleShowDependenciesMode();" /> for="showDependenciesMode"> key="configmanager.normal.showDependencyMode" />
>
> +
>
> -
> +
>
> - key="configmanager.normal.componentName" />
> -URL
> -
> - key="consolebase.common.commands"/>
> + key="configmanager.normal.componentName" />
> +
> + URL
> +
> + key="consolebase.common.state"/>
> + key="consolebase.common.commands"/>
>
> -key="configmanager.normal.parentComponents" />
> -key="configmanager.normal.childComponents" />
> + key="configmanager.normal.parentComponents" />
> + key="configmanager.normal.childComponents" />
>
>
>
>
> Modified:
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysNormal.jsp
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysNormal.jsp?rev=732011&r1=732010&r2=732011&view=diff
>
> ==
> ---
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysNormal.jsp
> (original)
> +++
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/javaSysNormal.jsp
> Tue Jan 6 09:30:41 2009
> @@ -20,9 +20,11 @@
>
>
>
> -
> +Java:
> +
>
> - align="center">Java
> + align="center">
> + align="center">
>
>
> nowrap>java.awt.graphicsenv
> @@ -125,10 +127,14 @@
> ${javaSysProps['java.version']}
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center"> +sage key="consolebase.common.item"/>
> + align="center">
>
>
> java.vm.info
> @@ -159,10 +165,13 @@
> ${javaSysProps['java.vm.version']}
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
>
> os.arch
> @@ -177,10 +186,13 @@
> ${javaSysProps['os.version']}
>
>
> -
> -
> +
> +
> +Sun:
> +
>
> - align="center">Sun
> + align="center">
> + align="center">
>
>
> sun.arch.data.model
> @@ -188,7 +200,6 @@
>
>
> sun.boot.class.path
> -
>
>
>
> @@ -231,10 +242,13 @@
> ${javaSysProps['sun.os.patch.level']}
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
>
> user.country
> @@ -265,10 +279,13 @@
> ${javaSysProps['user.variant']}
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
> <% String background = "LightBackground"; %>
> <% // Crappy workaround because apparently Jetty's JSTL can't call
> getters on a Map subclass?!?
>
> Modified:
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
> URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp?rev=732011&r1=732010&r2=732011&view=diff
>
> ==
> ---
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
> (original)
> +++
> geronimo/server/trunk/plugins/console/console-base-portlets/src/main/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
> Tue Jan 6 09:30:41 2009
> @@ -24,9 +24,11 @@
>
>
>
> -
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
>
> key="infomanager.svrInfoNormal.version"/>
> @@ -45,12 +47,14 @@
> id="UpTime"> key="infomanager.svrInfoNormal.notAvailable"/>
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
> -
>
> key="infomanager.svrInfoNormal.os.arch"/>
> ${svrProps['os.arch']}
> @@ -72,10 +76,13 @@
> ${svrProps['os.locale']}
>
>
> -
> -
> +
> +
> +:
> +
>
> - align="center">
> + align="center">
> + align="center">
>
>
> key="infomanager.svrInfoNormal.javaVersion"/>
>
>
>
--
~Jason Warner
Re: svn commit: r724818 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
You are correct, sir.
On Tue, Dec 9, 2008 at 11:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Hey, you really should not rely on system environment variables here, as
> that kinda defeats the purpose of using the svn-based controllers for all
> configuration.
>
> I'd recommend you revert this and setup defaults in the controllers.
>
> --jason
>
>
>
> On Dec 10, 2008, at 1:50 AM, [EMAIL PROTECTED] wrote:
>
> Author: jawarner
>> Date: Tue Dec 9 10:50:26 2008
>> New Revision: 724818
>>
>> URL: http://svn.apache.org/viewvc?rev=724818&view=rev
>> Log:
>> Pull maven opts from agent environment
>>
>> Modified:
>>
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>>
>> Modified:
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> URL:
>> http://svn.apache.org/viewvc/geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy?rev=724818&r1=724817&r2=724818&view=diff
>>
>> ==
>> ---
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> (original)
>> +++
>> geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
>> Tue Dec 9 10:50:26 2008
>> @@ -32,7 +32,7 @@
>>
>>def mavenHome = 'tools/maven'
>>
>> -def mavenOpts = null
>> +def mavenOpts = System.getenv('MAVEN_OPTS')
>>
>>def repoDir = 'repository'
>>
>>
>>
>>
>
--
~Jason Warner
[jira] Resolved: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3
[ https://issues.apache.org/jira/browse/GERONIMO-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-4453. Resolution: Fixed revision 724797 in trunk > Upgrade to shitty-maven-plugin 1.0-alpha-3 > -- > > Key: GERONIMO-4453 > URL: https://issues.apache.org/jira/browse/GERONIMO-4453 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner > Fix For: 2.2 > > > There's a bug[1] in version 1.0-alpha-2 of the shitty-maven-plugin that > causes tests to fail when run through anthill pro. This bug seems to have > been fixed in 1.0-alpha-3. > [1] No such property: loh for class: org.codehaus.mojo.shitty.TestBuild -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r724558 - in /geronimo/server/trunk: ./ plugingroups/javaee5-jetty/ plugingroups/javaee5-jetty/src/main/history/ plugingroups/javaee5-tomcat/ plugingroups/javaee5-tomcat/src/main/histo
You are correct. I'm just an eager beaver. It's building fine now so far.
On Tue, Dec 9, 2008 at 10:43 AM, Donald Woods <[EMAIL PROTECTED]> wrote:
> It was working for about 30 mins (Rev724709 thru 724732).
>
> Looks like you caught it in the middle of the activemq5 --> activemq
> renames after I had the old layout working. I think all of the renames are
> in as of Rev724760, but my local build is still running...
>
>
> -Donald
>
>
>
> Jason Warner wrote:
>
>> Donald, you said it build for you? I get the following error when I try
>> to build.
>>
>> org.apache.maven.reactor.MavenExecutionException: Could not find the model
>> file '/Users/jason/trunk/plugins/activemq5'. for project unknown
>>at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
>>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
>>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
>>at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>at java.lang.reflect.Method.invoke(Method.java:585)
>>at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>at
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>>at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> Caused by: org.apache.maven.project.ProjectBuildingException: Could not
>> find the model file '/Users/jason/trunk/plugins/activemq5'. for project
>> unknown
>>at
>> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1557)
>>at
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:504)
>>at
>> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
>>at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
>>at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
>>at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
>>at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
>>at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
>>... 11 more
>> Caused by: java.io.FileNotFoundException:
>> /Users/jason/trunk/plugins/activemq5 (No such file or directory)
>>at java.io.FileInputStream.open(Native Method)
>>at java.io.FileInputStream.(FileInputStream.java:106)
>>at
>> hidden.org.codehaus.plexus.util.xml.XmlReader.(XmlReader.java:123)
>>at
>> hidden.org.codehaus.plexus.util.xml.XmlStreamReader.(XmlStreamReader.java:67)
>>at
>> hidden.org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:113)
>>at
>> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1552)
>>... 18 more
>>
>> Any thoughts? Is it an error on my part? It's been that kind of day so
>> far. :-P
>>
>> Thanks!
>>
>> On Tue, Dec 9, 2008 at 9:59 AM, Donald Woods <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote:
>>
>>Cool. I have trunk building again with my latest commits (using the
>>activemq5-* named modules), so now I'll go remove the old AMQ4
>>modules and rename the AMQ5 ones back to the old names, so we don't
>>break Samples and user apps. (And I'll also update the TCK porting
>>files.)
>>
>>
>>-Donald
>>
>>
>>
>>Joe Bohn wrote:
>>
>>Donald Woods wrote:
>>
>>One of 2 good questions...
>>
>>The ${activemqString} was put in there by Jencks, so I just
>>kept using it, but it should probably be removed.
>>
>>Also, I don't like the renaming to activemq5-* for our
>>modules/cars, as now both our Samples and user apps will
>>have to be updated to use the new CAR names
>>
>>If there are no objections, I'll delete the old activemq
>>plugins and rename the activemq5 plugins, so we don't break
>>everyone.
>>
>>
>>Sounds good to me.
>>
>>Joe
>>
Re: svn commit: r724558 - in /geronimo/server/trunk: ./ plugingroups/javaee5-jetty/ plugingroups/javaee5-jetty/src/main/history/ plugingroups/javaee5-tomcat/ plugingroups/javaee5-tomcat/src/main/histo
server/trunk/plugingroups/javaee5-jetty/src/main/history/dependencies.xml >>>>> >>>>> geronimo/server/trunk/plugingroups/javaee5-tomcat/pom.xml >>>>> >>>>> geronimo/server/trunk/plugingroups/javaee5-tomcat/src/main/history/dependencies.xml >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-broker/src/main/history/dependencies.xml >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-broker/src/main/plan/plan.xml >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/helper/AmqJMSMessageHelper.java >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/server/BaseJMSPortlet.java >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/java/org/apache/geronimo/console/jmsmanager/server/JMSConnectorPortlet.java >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/resources/jms-resource-providers.properties >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/webapp/WEB-INF/view/jmsmanager/server/connector/normal.jsp >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/main/webapp/WEB-INF/view/jmsmanager/server/normal.jsp >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/activemq5-server/pom.xml >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/geronimo-activemq5/src/main/java/org/apache/geronimo/activemq/BrokerServiceGBeanImpl.java >>>>> >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/geronimo-activemq5/src/main/java/org/apache/geronimo/activemq/management/ActiveMQManagerGBean.java >>>>> >>>>> geronimo/server/trunk/plugins/activemq5/pom.xml >>>>> geronimo/server/trunk/pom.xml >>>>> >>>>> geronimo/server/trunk/testsuite/commands-testsuite/gshell/src/test/java/org/apache/geronimo/testsuite/gshell/deploy/DeployTest.java >>>>> >>>>> >>>>> geronimo/server/trunk/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/JMSServerTest.java >>>>> >>>>> >>>>> geronimo/server/trunk/testsuite/enterprise-testsuite/jms-tests/jms-ear/src/main/resources/META-INF/geronimo-application.xml >>>>> >>>>> >>>>> geronimo/server/trunk/testsuite/web-testsuite/test-web-references/web-references-ear/src/main/resources/META-INF/geronimo-application.xml >>>>> >>>>> >>>>> >>>> >>> >> >> -- ~Jason Warner
[jira] Created: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3
Upgrade to shitty-maven-plugin 1.0-alpha-3 -- Key: GERONIMO-4453 URL: https://issues.apache.org/jira/browse/GERONIMO-4453 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: dependencies Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 There's a bug[1] in version 1.0-alpha-2 of the shitty-maven-plugin that causes tests to fail when run through anthill pro. This bug seems to have been fixed in 1.0-alpha-3. [1] No such property: loh for class: org.codehaus.mojo.shitty.TestBuild -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r723242 - /geronimo/server/trunk/plugins/monitoring/agent/src/main/plan/plan.xml
t;> - >>> - >>> - >>> >>> org.apache.geronimo.security.credentialstore.PasswordCallbackHandler >>> -manager >>> + admin >>> >>> >>> >>> >>> >>> + >>> +monitoring-runas-realm >>> + >>> + >>> +monitoring-runas-realm >>> + >>> >>> + >>> +>> +class="org.apache.geronimo.security.realm.GenericSecurityRealm"> >>> +monitoring-runas-realm >>> +false >>> + >>> +http://geronimo.apache.org/xml/ns/loginconfig-1.2";> >>> + >>> + >>> monitoring-runas-domain >>> + >>> >>> org.apache.geronimo.security.credentialstore.RunAsLoginModule >>> +>> name="principalClass">org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal >>> +admin >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> + >>> >>> >>> >>> >>> >> > -- ~Jason Warner
Re: Subscribe mail list dev@geronimo.apache.org
haha. Yeah. I just realized that. That'll teach me to answer emails so early in the morning. On Thu, Dec 4, 2008 at 7:40 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>wrote: > > > On Thu, Dec 4, 2008 at 6:02 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > >> I'm not sure if we should have a "Post a message" option. It was my >> understanding that our mailing list is setup such that your message won't go >> through unless you are subscribed to the list. > > If this was the case, we would not have seen the mail that initiated this > thread :) > > >> I think putting a "Post a message" option will result in a lot of people >> attempting to send a message to the list without subscribing first, and >> being frustrated that their message is never answered. Of course, if I'm >> wrong about how the list works and you don't need to subscribe first then >> I'm completely fine with this. Can anyone verify? >> >> Thanks! >> >> >> On Thu, Dec 4, 2008 at 1:46 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>wrote: >> >>> I removed the hyperlinks on user@, dev@ and [EMAIL PROTECTED] I >>> have also added a "Post a message" link to user@ and >>> [EMAIL PROTECTED] >>> >>> ++Vamsi >>> >>> >>> On Thu, Dec 4, 2008 at 11:25 AM, Vamsavardhana Reddy < >>> [EMAIL PROTECTED]> wrote: >>> >>>> I think the wiki automatically puts a hyperlink on e-mail addresses. We >>>> should remove the hyperlinks on the e-mail address and also provide an >>>> additional link "Send message to [EMAIL PROTECTED]" etc., so >>>> that users are not confused. If no one has any objections, I will go ahead >>>> and update the page. >>>> >>>> ++Vamsi >>>> >>>> >>>> On Thu, Dec 4, 2008 at 11:02 AM, Jack Cai <[EMAIL PROTECTED]> wrote: >>>> >>>>> This actually reveals a problem in the instruction page: >>>>> http://geronimo.apache.org/mailing-lists.html. I was a little confused >>>>> too when I made the subscription. I'd suggest to remove the hyperlinks of >>>>> [EMAIL PROTECTED], dev@geronimo.apache.org and >>>>> [EMAIL PROTECTED], so that users will only click the >>>>> "subscirbe"/"unsubscribe" links. Makes sense? >>>>> >>>>> -Jack >>>>> >>>>> 2008/12/3 Vamsavardhana Reddy <[EMAIL PROTECTED]> >>>>> >>>>> Send mail to [EMAIL PROTECTED] . >>>>>> >>>>>> ++Vamsi >>>>>> >>>>>> >>>>>> On Wed, Dec 3, 2008 at 11:23 AM, han hongfang <[EMAIL PROTECTED]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm interested with Geronimo development and already had Apache CLA >>>>>>> signed. I want to subscribe mail list [EMAIL PROTECTED] >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Best regard, >>>>>>> >>>>>>> Han Hong Fang >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Vamsi >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vamsi >>>> >>> >>> >>> >>> -- >>> Vamsi >>> >> >> >> >> -- >> ~Jason Warner >> > > > > -- > Vamsi > -- ~Jason Warner
Re: Subscribe mail list dev@geronimo.apache.org
I'm not sure if we should have a "Post a message" option. It was my understanding that our mailing list is setup such that your message won't go through unless you are subscribed to the list. I think putting a "Post a message" option will result in a lot of people attempting to send a message to the list without subscribing first, and being frustrated that their message is never answered. Of course, if I'm wrong about how the list works and you don't need to subscribe first then I'm completely fine with this. Can anyone verify? Thanks! On Thu, Dec 4, 2008 at 1:46 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>wrote: > I removed the hyperlinks on user@, dev@ and [EMAIL PROTECTED] I > have also added a "Post a message" link to user@ and > [EMAIL PROTECTED] > > ++Vamsi > > > On Thu, Dec 4, 2008 at 11:25 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>wrote: > >> I think the wiki automatically puts a hyperlink on e-mail addresses. We >> should remove the hyperlinks on the e-mail address and also provide an >> additional link "Send message to [EMAIL PROTECTED]" etc., so that >> users are not confused. If no one has any objections, I will go ahead and >> update the page. >> >> ++Vamsi >> >> >> On Thu, Dec 4, 2008 at 11:02 AM, Jack Cai <[EMAIL PROTECTED]> wrote: >> >>> This actually reveals a problem in the instruction page: >>> http://geronimo.apache.org/mailing-lists.html. I was a little confused >>> too when I made the subscription. I'd suggest to remove the hyperlinks of >>> [EMAIL PROTECTED], dev@geronimo.apache.org and >>> [EMAIL PROTECTED], so that users will only click the >>> "subscirbe"/"unsubscribe" links. Makes sense? >>> >>> -Jack >>> >>> 2008/12/3 Vamsavardhana Reddy <[EMAIL PROTECTED]> >>> >>> Send mail to [EMAIL PROTECTED] . >>>> >>>> ++Vamsi >>>> >>>> >>>> On Wed, Dec 3, 2008 at 11:23 AM, han hongfang <[EMAIL PROTECTED]>wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm interested with Geronimo development and already had Apache CLA >>>>> signed. I want to subscribe mail list [EMAIL PROTECTED] >>>>> >>>>> Thanks! >>>>> >>>>> Best regard, >>>>> >>>>> Han Hong Fang >>>>> >>>> >>>> >>>> >>>> -- >>>> Vamsi >>>> >>> >>> >> >> >> -- >> Vamsi >> > > > > -- > Vamsi > -- ~Jason Warner
Re: Status of server/trunk wrt any release?
There's a release map for 2.2 here http://cwiki.apache.org/GMOxPMGT/geronimo-22-release-status.html. It looks like we have a code freeze on Dec. 12 with a proposed release candidate on Jan. 9. I think that gives us enough time to work out any kinks that might be introduced with a new GShell. Hopefully... On Fri, Nov 28, 2008 at 4:59 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Is there any release planned for server/trunk soonerish? I ask because I'm > about ready to release GShell 1.0-alpha-2, and I'd like to update > server/trunk to use its awesome goodness. Anyone see any problems with > that? > > --jason > -- ~Jason Warner
Re: error starting trunk javaee5 assemblies
flect.GeneratedMethodAccessor50.invoke(Unknown Source) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at > org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) >at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:815) >at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) >at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) >at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) >at > org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$f64bdb45.loadConfiguration() >at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:158) >at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) >at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) >at > org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) >at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error > starting configuration gbean > org.apache.geronimo.plugins/mconsole-ds/2.2-SNAPSHOT/car > -- ~Jason Warner
Re: [BUILD] branches/2.0: Failed for Revision: 719139
geronimo/geronimo/2.0/modules/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java:[369,69] >> cannot find symbol >> symbol : variable GBEAN_REF_MANAGER_RETRIEVER >> location: class org.apache.geronimo.tomcat.TomcatWebAppContext >> >> >> [INFO] >> >> [INFO] Trace >> org.apache.maven.BuildFailureException: Compilation failure >> /home/geronimo/geronimo/2.0/modules/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java:[369,69] >> cannot find symbol >> symbol : variable GBEAN_REF_MANAGER_RETRIEVER >> location: class org.apache.geronimo.tomcat.TomcatWebAppContext >> >> >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) >>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) >>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) >>at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) >>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>at java.lang.reflect.Method.invoke(Method.java:585) >>at >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >>at >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >>at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> Caused by: org.apache.maven.plugin.CompilationFailureException: >> Compilation failure >> /home/geronimo/geronimo/2.0/modules/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java:[369,69] >> cannot find symbol >> symbol : variable GBEAN_REF_MANAGER_RETRIEVER >> location: class org.apache.geronimo.tomcat.TomcatWebAppContext >> >> >>at >> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516) >>at >> org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) >>at >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) >>... 16 more >> [INFO] >> >> [INFO] Total time: 12 minutes 3 seconds >> [INFO] Finished at: Wed Nov 19 20:17:01 EST 2008 >> [INFO] Final Memory: 155M/535M >> [INFO] >> >> > > > > -- > Ivan > -- ~Jason Warner
Re: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2
Have we come to a consensus on this yet? Perhaps we should put it to a vote? The discussion has died down, but there doesn't seem to be a clear "winner." On Sat, Nov 8, 2008 at 7:53 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > I'm not proposing that we put any checks or hard stops in the server to > prevent starting on Java SE 5, but I would like to remove JAXB/JAXWS 2.1 as > it comes in Java SE 6 and use the wsgen in the JDKs instead of shipping some > CXF code for Axis2 users. > > Free Java SE 5 support/updates end next year, so I don't see why you'd want > to continue supporting it in a 2.2 release that is targeted as a main > release stream for 2009. > > > -Donald > > > > Kevan Miller wrote: > >> >> On Nov 7, 2008, at 12:04 AM, Donald Woods wrote: >> >> The time has come to make the hard decision - >>> >>> Do we only build and certify Geronimo 2.2 on the Sun 1.6.0 JDK and drop >>> support for running on Java SE 5? >>> >> >> Um. What do you mean "drop support"? We've only announced "certification" >> on a particular Java SE level, in the past. We've documented minimum SE >> platform (e.g. Java EE 5 is hard to do on 1.4). >> >> I would be against some sort of explicit Java SE 5 runtime check that >> would fail server startup. If a user shows up with a Java SE 5 issue, I'd >> expect that we'd be trying to fix their problem, regardless of our "support >> statement" >> >> I have no issue with performing certification testing, only, on Java Se 6 >> (but would also be happy to see some Java SE 5 runs...). >> >> However, I don't see any reason to discourage users from using Java SE 5, >> if that's what they want... >> >> >>> >>> Pros: >>> - Reduce testing effort to one version of Java >>> >> >> Fine, but w/ testing hardware, may not be a big issue to test on both... >> >> >>> - Allows us to use the JAXB 2.1, JAX-WS 2.1 and wsgen tools in the JDK, >>> instead of shipping those jars in our assemblies (and removes some more Sun >>> RI from our assemblies) :-) >>> >> >> I thought we were going to be picking up tools from CXF -- >> https://issues.apache.org/jira/browse/GERONIMO-4351 Would that resolve >> your issues with Java SE 5? >> >> --kevan >> >> -- ~Jason Warner
Re: svn commit: r713680 - in /geronimo/server/trunk/framework/modules: geronimo-service-builder/src/main/java/org/apache/geronimo/deployment/service/ geronimo-service-builder/src/main/xsd/ geronimo-se
Gianny, I think you are correct. The most recent snapshot of OpenEJB still exhibits the same errors that were mentioned previously. Thanks, On Thu, Nov 13, 2008 at 3:10 PM, Gianny Damour < [EMAIL PROTECTED]> wrote: > Hi, > > The feature is still available. However we do not provide a XML > configuration style for it. We only provide a script configuration style. > For instance, by dropping a file named: > > DependenciesPrivateClass.groovy > > in the folder of the plugin to update and with a content looking like > > Set privateClasses = ['hide.this', 'hide.that'] > > configurationData.environment.classLoadingRules.privateRule.addClassPrefixes(privateClasses) > > You can achieve the same effect. > > Let me know if you think that we should also provide a XML configuration > style. > > Regarding the TCK problem, I do not think that this change is related. I > believe that the TCK problem is due to the new OpenEJB snapshot. Jason, > could you please confirm? > > Thanks, > Gianny > > > On 14/11/2008, at 5:19 AM, Joe Bohn wrote: > > I think I was one of the people asking for this to be reverted. >> >> Just to clarify my position: I'm very much in favor of keeping the >> functionality. I think it will help with some of the more obscure >> classloader issues we've been hitting. >> >> My suggestion to revert the change was more pragmatic to resolve two >> issues: >> 1) new TCK failures reported by Jason >> 2) The implicit dependency on a new OpenEJB 3.1.x release >> >> If we can resolve these 2 issues without reverting the change (or for #2 >> if it seems we need a new OpenEJB 3.1.x release for other reasons ... like >> other TCK failures) then I'm very much in favor of keeping this change. >> >> >> Joe >> >> >> David Jencks wrote: >> >>> Um, -1. I thought this was a great idea for 2.2. What's the problem >>> that leads you to revert it? >>> thanks >>> david jencks >>> On Nov 13, 2008, at 12:35 AM, [EMAIL PROTECTED] wrote: >>> >>>> Author: gdamour >>>> Date: Thu Nov 13 00:35:05 2008 >>>> New Revision: 713680 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=713680&view=rev >>>> Log: >>>> Revert addition of private-classes element. Private classes can be >>>> configured via scripts. >>>> >>>> (GERONIMO-4403) Provide a mechanism to hide specific classes of a >>>> configuration to all its children >>>> >>>> >>> >> > -- ~Jason Warner
Re: Is there a bp project for Geronimo like petstore?
We have an application called Daytrader that's aimed at being a benchmarking application for geronimo. I'm not sure what features it covers but it's the most complicated sample we have. You can take a look at the source code here if you'd like: http://svn.apache.org/viewvc/geronimo/daytrader/. On Thu, Nov 13, 2008 at 6:33 AM, haidescs <[EMAIL PROTECTED]> wrote: > > HI guys > > Is there a bp project for Geronimo like petstore which is implemented based > on all the basic feature of Geronimo such as OpenEJB, OpenJPA, Activemq, > Derby DB, Webservice, potlets, and so on, and some high level features like > ajax? > > If not, maybe I could make it when I have some leisure time. > -- > View this message in context: > http://www.nabble.com/Is-there-a-bp-project-for-Geronimo-like-petstore--tp20479079s134p20479079.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > > -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
There's no need to check in what you have if you don't feel it's quite done
yet. I was just wondering where you were at. I was eager to have a
solution for the original issue find its way into the 2.2 release, and it
seems that would be the case. I think that improving the classloading
isolation would be the best approach to solve the issue you raised. I'm not
too familiar with the classloader as is, though, so I'm not sure what impact
that would have. From a purely user point of view, it seems like the
correct way to go. Let me know if you need any help testing or coding any
of this. As I said, I'm not too familiar with the classloader, but if I
flop around in the code enough I might be able to make a few small waves ;)
Thanks!
On Tue, Oct 28, 2008 at 4:53 PM, Gianny Damour <
[EMAIL PROTECTED]> wrote:
> Hi Jason,
>
> It is implemented and I will check-in over the week-end.
>
> Here is the design:
> 1. When a ConfigurationData is loaded from a ConfigurationStore, its
> dependencies can be altered based on scripts matching the pattern
> dependencies-(.*).groovy. Here is the script I have been using to perform my
> integration test:
>
> configurationDataBuilder.configure {
>addDependency(groupId: "org.springframework", artifactId: "spring-core",
> version: "2.0.5", type: "jar")
> }
>
> 2. When the GBeans of a configuration are loaded, i.e. when a Configuration
> instance is created, GBeans can be updated based on scripts matching the
> pattern gbeans-(,*).groovy. Here is my integration test script:
>
> import org.springframework.core.SpringVersion
>
> gbeanDataBuilder.configure {
>addGBean(name: 'name', gbean: SpringVersion) {
>}
> }
>
> Scripts are searched in the configuration directory, i.e. in the same
> folder of the META-INF folder of a configuration. This can be easily changed
> by implementing a ScriptLocater strategy.
>
> I had to add a groovy dependency to the j2ee-system config which is not
> ideal as all the configurations will now see the Groovy classes. Ideally, I
> would like to add another configuration where ConfigurationDataTransformers
> can be declared and the out-of-the-box GroovyTransformer can be specified.
> This is problematic as such a configuration needs to be started after
> j2ee-system and before any other configurations. I could add a dependency to
> this configuration on the innermost configuration after j2ee-system.
>
> Another approach would be to improve the isolation of configuration
> classloaders, which should also address classloading problems reported by
> users and the need to fiddle with hidden-classes declarations. Assuming that
> I stick to the current configuration approach where I declare a
> GroovyTransformer in j2ee-system, the improvement I am thinking about is:
> 1) add a new classloading declaration element, maybe hidden-for-children,
> where users can specify a pattern a la hidden-classes.
> 2) The above declarations are used to build a classloader which simply
> delegates to the configuration classloader and filter out classes matching
> the hidden-for-children declarations.
> 3) Children configurations are provided with the above classloader instead
> of the configuration classloader.
>
> With this thing in place, I will be able to add a groovy dependency to
> j2ee-system w/o having to thing about the impacts to children configurations
> as I can hide the groovy classes.
>
> If you want me to check-in "as-is" this scripting stuff and revisit the
> implementation as soon as I figure out which of the two approaches, i.e. add
> another config or improve classloading isolation, is the best, then let me
> know.
>
> Thanks,
> Gianny
>
>
>
> On 29/10/2008, at 2:21 AM, Jason Warner wrote:
>
> Hi Gianny,
>>
>> Have you made any progress with this? Are you targeting this for the 2.2
>> release (whenever that happens to be)?
>>
>> Thanks!
>>
>> On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour <
>> [EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am proposing the following implementation to start with:
>>
>> 1. In the META-INF folder of a config, we scan for files matching the
>> patterns "dependencies-(.*).groovy" and "extentions-(.*).groovy".
>>
>> 2. We execute the scripts "dependencies-(.*).groovy" which modify
>> dependencies. For instance, such scripts may look like:
>>
>> configurationData + dependency(groupId: 'group', artifactId: 'artifact',
>> version: '1.1', type: 'jar', importType: importType) -- add the declared
>> dependency
>> configu
Re: An idea for defining custom valves in config.xml
Hi Gianny,
Have you made any progress with this? Are you targeting this for the 2.2
release (whenever that happens to be)?
Thanks!
On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am proposing the following implementation to start with:
>
> 1. In the META-INF folder of a config, we scan for files matching the
> patterns "dependencies-(.*).groovy" and "extentions-(.*).groovy".
>
> 2. We execute the scripts "dependencies-(.*).groovy" which modify
> dependencies. For instance, such scripts may look like:
>
> configurationData + dependency(groupId: 'group', artifactId: 'artifact',
> version: '1.1', type: 'jar', importType: importType) -- add the declared
> dependency
> configurationData - dependency(groupId: 'group', artifactId: 'artifact',
> version: '1.0', type: 'jar') -- remove the declared dependency
>
> This gives us the final classloader of the config.
>
> 3. We execute the scripts "extentions-(.*).groovy" which update the GBeans,
> For instance, such scripts may look like:
>
> gBeanBuilder.configure {
>addGBean(BasicNodeInfo) { -- add a GBean
>attribute(name: 'node1')
>attribute(extendedJMXConnectorInfo: new
> BasicExtendedJMXConnectorInfo(...))
>reference(referenceName) {
>pattern('aPattern')
>pattern('aSecondPattern')
>}
>}
>removeGBeansMatching('aPattern')
> }
>
> gBeanBuilder.updatedConfigurationData
>
> The implementation of such scripts should be as simple as the modification
> of config.xml.
>
> The fact that they are collocated with the configuration they modify
> increases cohesion. It would be neat to have such scripts instead of the
> native or XStream serializations of config.ser.
>
> Let me know your thoughts?
>
> Thanks,
> Gianny
>
>
>
> On 16/10/2008, at 11:17 PM, Jason Warner wrote:
>
> While David is more interested in the philosophy, I'd prefer to know a
>> little bit more about your thoughts on implementation. Specifically what do
>> you imagine would be involved in defining this configuration? Would it be
>> as simple as a definition in config.xml?
>>
>> On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour <
>> [EMAIL PROTECTED]> wrote:
>> Hi David,
>>
>> You are correct: the underpinning philosophy of these approaches is to
>> make it easier to modify pre-canned plugins through extension points.
>>
>> This may be a good approach to improve further the packaging model of
>> dependencies and services. Let's say that an end-user wants to add a
>> connector to the tomcat6 plugin. Instead of using the admin console or
>> updating his config.xml, he can simply deploy a cumulative plan. This notion
>> of cumulative plan is the key differentiator as users can share their
>> cumulative plans "as-is" - i.e. w/o knowing what the plugin to be modified
>> looks like. To some extent, providing a plan ready to be deployed instead
>> of deployment instructions is better for novices.
>>
>> I will work on the Groovy builder approach and post back more details as I
>> go.
>>
>> Thanks,
>> Gianny
>>
>>
>> On 16/10/2008, at 10:59 AM, David Jencks wrote:
>>
>> Hi Gianny,
>>
>> First, I'd like to make sure I understand the philosophy behind your
>> proposals. IIUC they both involve the idea of making it easy to modify an
>> existing plugin rather than making it easy to replace an existing plugin
>> with a similar one.
>>
>> Why is this a good idea? My idea has been that we should make it easier
>> to replace a plugin with a similar one than modify an existing one, and then
>> we will have the best of all worlds.
>>
>> All this being said, I think your ideas are both quite interesting. I'm
>> especially interested in the groovy builder approach.
>>
>> I'll be fairly unavailable until next week but might keep thinking about
>> this anyway.
>>
>> thanks!
>> david jencks
>> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote:
>>
>> On 15/10/2008, at 4:16 AM, David Jencks wrote:
>>
>> That's one of the main missing bits of functionality. Right now the only
>> way to get the g-p.xml is to use c-m-p or to export the plugin from a server
>> it's been deployed into, or to do something by hand with jar packing and
>> unpacking.
>>
>> The biggest problem here, in my mind, is that jsr88 only wa
Re: Continuous TCK Testing
Hi Jason, Now that I've got my hands on anthill to play with, I'm diving into setting up things. I was hoping you'd be able to clarify for me a little bit how the build-support stuff was integrated with the anthill stuff. Specifically, I'm working on setting up a project in anthill to build the geronimo server from the trunk in the repository. This seems like a good first step to me. From what you specified in your explanation, it seems that every step of this automated testing had an anthill project and a corresponding groovy-based controller. So for the geronimo build, I would have an anthill project devoted to building the server which would help with shuffling artifacts around, cleaning working directories, and other such pre/post build things, but the actual build would be handled by the controller? So the anthill project would actually be launching the controller rather than the build? Thanks! On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: > > Is the GBuild stuff in svn the same as the anthill-based code or is that >> something different? GBuild seems to have scripts for running tck and that >> leads me to think they're the same thing, but I see no mention of anthill in >> the code. >> > > The Anthill stuff is completely different than the GBuild stuff. I started > out trying to get the TCK automated using GBuild, but decided that the > system lacked too many features to perform as I desired, and went ahead with > Anthill as it did pretty much everything, though had some stability > problems. > > One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was > its build agent and code repository systems. This allowed me to ensure that > each build used exactly the desired artifacts. Another was the configurable > workflow, which allowed me to create a custom chain of events to handle > running builds on remote agents and control what data gets set to them, what > it will collect and what logic to execute once all distributed work has been > completed for a particular build. And the kicker which help facilitate > bringing it all together was its concept of a build life. > > At the time I could find *no other* build tool which could meet all of > these needs, and so I went with AHP instead of spending months > building/testing features in GBuild. > > While AHP supports configuring a lot of stuff via its web-interface, I > found that it was very cumbersome, so I opted to write some glue, which was > stored in svn here: > > > https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 > > Its been a while, so I have to refresh my memory on how this stuff actually > worked. First let me explain about the code repository (what it calls > codestation) and why it was critical to the TCK testing IMO. When we use > Maven normally, it pulls data from a set of external repositories, picks up > more repositories from the stuff it downloads and quickly we loose control > where stuff comes from. After it pulls down all that stuff, it churns > though a build and spits out the stuff we care about, normally stuffing them > (via mvn install) into the local repository. > > AHP supports by default tasks to publish artifacts (really just a set of > files controlled by an Ant-like include/exclude path) from a build agent > into Codestation, as well as tasks to resolve artifacts (ie. download them > from Codestation to the local working directory on the build agents system). > Each top-level build in AHP gets assigned a new (empty) build life. > Artifacts are always published to/resolved from a build life, either that > of the current build, or of a dependency build. > > So what I did was I setup builds for Geronimo Server (the normal > server/trunk stuff), which did the normal mvn install thingy, but I always > gave it a custom -Dmaven.local.repository which resolved to something inside > the working directory for the running build. The build was still online, so > it pulled down a bunch of stuff into an empty local repository (so it was a > clean build wrt the repository, as well as the source code, which was always > fetched for each new build). Once the build had finished, I used the > artifact publisher task to push *all* of the stuff in the local repository > into Codestation, labled as something like "Maven repository artifacts" for > the current build life. > > Then I setup another build for Apache Geronimo CTS Server (the > porting/branches/* stuff). This build was dependent upon the "Maven > repository artifacts" of the Geronimo Server build, and I configured those > artifacts to get installed on the build agents system in the sa
Re: svn commit: r706725 - /geronimo/sandbox/build-support/
>From what I saw, this was the latest revision before build-support was deleted. I thought that would be a good place to start. On Wed, Oct 22, 2008 at 11:06 AM, Jason Dillon <[EMAIL PROTECTED]>wrote: > How did you decide on this revision? > > --jason > > > > On Oct 22, 2008, at 2:15 AM, [EMAIL PROTECTED] wrote: > > Author: jawarner >> Date: Tue Oct 21 12:15:31 2008 >> New Revision: 706725 >> >> URL: http://svn.apache.org/viewvc?rev=706725&view=rev >> Log: >> Resurrecting the build-support stuff in an attempt to get some automated >> TCK tests going >> >> Added: >> geronimo/sandbox/build-support/ >> - copied from r632245, geronimo/sandbox/build-support/ >> >> > -- ~Jason Warner
Re: Have we run 2.1.4-SNAPSHOT through a TCK yet?
Actually, yes. I just finished running some yesterday but hadn't taken a look at it yet. Just took a peak. It looks like we have some issues. I'll look at them and post on the TCK list about what I come across. On Fri, Oct 17, 2008 at 10:28 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > Jason W., was wondering if you have had a chance to run branches/2.1 > (2.1.4-SNAPSHOT) through the TCK yet? There have been some changes that > have gone into 2.1 and trunk (like OpenJPA 1.2.0 and several WS JIRAs) that > it would be useful to see if everything still passes before we start running > any 2.2 builds through the TCK. > > > -Donald > -- ~Jason Warner
Re: restart of tck08 on selene
Thanks for looking into that, Kevan. Was there any indicator of what caused the crash? Thanks On Thu, Oct 16, 2008 at 5:26 PM, Kevan Miller <[EMAIL PROTECTED]>wrote: > FYI, > The Xen domain tck08 on selene.apache.org crashed yesterday. > > 'xm log' showed that the domain had indeed crashed and that the subsequent > attempt to restart the domain had failed because the domain already existed. > > When I looked, 'xm list' did not show tck08 as a domain that could be > controlled (start, shutdown, etc). > > I finally ended up running 'xm create /etc/xen/tck08.cfg'. This seems to > have restarted the domain. I'm able to log in to tck08, and everything looks > ok. So, hopefully it's back in service. > > --kevan > -- ~Jason Warner
Re: Continuous TCK Testing
Whoops... just realized that this was actually removed and I was looking at a stickied revision of viewVC. Nevermind. On Thu, Oct 16, 2008 at 11:15 AM, Jason Warner <[EMAIL PROTECTED]> wrote: > While we wait to hear back in regards to the license, I'm going to update > the maven used in build-support. The server now requires 2.0.9 and the > version currently used by build support is 2.0.5. I suppose we'll need to > update ant, as well. What version of ant should we be using? 1.7.1? > > > On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > >> >> On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: >> >> >> On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: >> >> We had some suggestions earlier for some alternate means of implementing >> this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide >> an overview of what we had in place before, does anyone have thoughts on >> what we should go with? I'm thinking we should stick with the AHP based >> solution. It will need to be updated most likely, but it's been tried and >> tested and shown to meet our needs. I'm wondering, though, why we stopped >> using it before. Was there a specific issue we're going to have to deal >> with again? >> >> >> IIRC, the overwhelming reason we stopped using it before was because of >> hosting issues -- spotty networking, hardware failures, poor colo support, >> etc. We shouldn't have any of these problems, now. If we do run into >> problems, they should now be fixable. I have no reason to favor >> Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for >> it. There's only one potential issue, that I'm aware of. >> >> We previously had an Open Source License issued for our use of Anthill. >> Here's some of the old discussion -- >> http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902<http://www.nabble.com/Geronimo-build-automation-status-%28longish%29-tt7649902.html#a7649902> >> >> Although the board was aware of our usage of AntHill, since we weren't >> running AntHill on ASF hardware, I'm not sure the license was fully vetted >> by Infra. I don't see any issues, but I'll want to run this by Infra. >> >> Jason D, will the existing license cover the version of AntHill that we'll >> want to use? I'll run the license by Infra and will also describe the issue >> for review by the Board, in our quarterly report. >> >> IMO, I'd proceed with the assumption that we'll be using AHP. Just don't >> install it on Apache hardware, yet. >> >> >> I've requested a new license from Anthill. Will let you know when I get >> it. >> >> --kevan >> >> > > > -- > ~Jason Warner > -- ~Jason Warner
Re: Continuous TCK Testing
While we wait to hear back in regards to the license, I'm going to update the maven used in build-support. The server now requires 2.0.9 and the version currently used by build support is 2.0.5. I suppose we'll need to update ant, as well. What version of ant should we be using? 1.7.1? On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller <[EMAIL PROTECTED]>wrote: > > On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: > > > On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: > > We had some suggestions earlier for some alternate means of implementing > this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide > an overview of what we had in place before, does anyone have thoughts on > what we should go with? I'm thinking we should stick with the AHP based > solution. It will need to be updated most likely, but it's been tried and > tested and shown to meet our needs. I'm wondering, though, why we stopped > using it before. Was there a specific issue we're going to have to deal > with again? > > > IIRC, the overwhelming reason we stopped using it before was because of > hosting issues -- spotty networking, hardware failures, poor colo support, > etc. We shouldn't have any of these problems, now. If we do run into > problems, they should now be fixable. I have no reason to favor > Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for > it. There's only one potential issue, that I'm aware of. > > We previously had an Open Source License issued for our use of Anthill. > Here's some of the old discussion -- > http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902<http://www.nabble.com/Geronimo-build-automation-status-%28longish%29-tt7649902.html#a7649902> > > Although the board was aware of our usage of AntHill, since we weren't > running AntHill on ASF hardware, I'm not sure the license was fully vetted > by Infra. I don't see any issues, but I'll want to run this by Infra. > > Jason D, will the existing license cover the version of AntHill that we'll > want to use? I'll run the license by Infra and will also describe the issue > for review by the Board, in our quarterly report. > > IMO, I'd proceed with the assumption that we'll be using AHP. Just don't > install it on Apache hardware, yet. > > > I've requested a new license from Anthill. Will let you know when I get it. > > --kevan > > -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
On Wed, Oct 15, 2008 at 7:59 PM, David Jencks <[EMAIL PROTECTED]>wrote: > Hi Gianny, > > First, I'd like to make sure I understand the philosophy behind your > proposals. IIUC they both involve the idea of making it easy to modify an > existing plugin rather than making it easy to replace an existing plugin > with a similar one. > > Why is this a good idea? My idea has been that we should make it easier to > replace a plugin with a similar one than modify an existing one, and then we > will have the best of all worlds. > I think, from a user perspective, the best of all possible worlds is to have both options available. Thinking in the context of the original custom valve scenario, since we seem to have expanded the scope a little, it shouldn't be necessary for a straight user to delve into the world of plugins to deploy a valve. Regardless of how simple we make deploying a plugin, that's still an added level of complexity that we shouldn't require of a user who is working solely in the realm of a webapp. I realize I made this argument earlier, but after tinkering with your proposed approach and thinking about it some more, I've come back around to my original line of thinking, though hopefully better informed this time. I understand the objections to the original proposal of using an attribute, but if sufficiently simple to define, Gianny's approach might be the right way to accomplish the same goal. At the same time, I'm still all for improving and simplifying the method in which we deploy plugins. > > All this being said, I think your ideas are both quite interesting. I'm > especially interested in the groovy builder approach. > > I'll be fairly unavailable until next week but might keep thinking about > this anyway. > > thanks! > david jencks > > On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: > > On 15/10/2008, at 4:16 AM, David Jencks wrote: >> >> That's one of the main missing bits of functionality. Right now the only >>> way to get the g-p.xml is to use c-m-p or to export the plugin from a server >>> it's been deployed into, or to do something by hand with jar packing and >>> unpacking. >>> >>> The biggest problem here, in my mind, is that jsr88 only wants you to >>> have one "plan": to deploy something you get to specify the artifact and one >>> "plan". Our deployment system is built around jsr88 so we either have to >>> condense the g-p.xml and plan into one "plan" or abandon jsr88. >>> >>> At the moment I'm thinking that one satisfactory solution might be to >>> more or less embed the plan into g-p.xml. Perhaps we could avoid >>> duplicating most of the dependency info by adding the element to >>> the dependencies in g-p.xml. I guess we'd expect a more or less empty >>> element in the plan and fill in the dependencies from the >>> g-p.xml when deploying. >>> >>> I guess another possibility might be to include the info from g-p.xml in >>> the environment element of the plan. >>> >>> I've been thinking about this on and off for a long time and don't have >>> any solution I'm entirely happy with so discussion and more ideas are more >>> than welcome :-) >>> >> >> Hi, >> >> Another possible solution would be to allow the extension of a given >> configuration by other configurations. This could work like the web.xml >> fragment mechanism of the upcoming servlet specs which allows framework >> libraries to transparently install Web components to the baseline components >> defined by the web.xml DD. >> >> When a configuration starts it looks for complementing configurations >> whose responsibility is to alter the baseline configuration. The >> identification of complementing configurations could be based on a simple >> naming convention scheme, e.g. if the base configuration is org/tomcat6//car >> then all the configurations matching the pattern >> org/tomcat6-transform-DiscriminatorName//car are identified as complementing >> configurations. >> >> If there are complementing configurations, then the baseline >> ConfigurationData could be passed to them for arbitrary transformation, e.g. >> add, update or remove dependencies. An updated ConfigurationData is passed >> back and actually loaded by the kernel. >> >> The main drawback of this approach is the added configuration complexity. >> The main benefits is that it provides application server configuration >> traceability and a mean to perform very simple changes to a baseline >> configuration w/o having to redefine in its entirety the configuration to be >> slightly changed. >> >> In another thread about scripting language integration, I suggested an >> even simpler approach whereby a script is executed to perform >> ConfigurationData transformations. >> >> If any of these two options are plausible solutions, then I am happy to >> move forward with an implementation. >> >> Thanks, >> Gianny >> >> >>> thanks >>> david jencks >>> >>> > -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
he baseline >>> ConfigurationData could be passed to them for arbitrary transformation, e.g. >>> add, update or remove dependencies. An updated ConfigurationData is passed >>> back and actually loaded by the kernel. >>> >>> The main drawback of this approach is the added configuration complexity. >>> The main benefits is that it provides application server configuration >>> traceability and a mean to perform very simple changes to a baseline >>> configuration w/o having to redefine in its entirety the configuration to be >>> slightly changed. >>> >>> In another thread about scripting language integration, I suggested an >>> even simpler approach whereby a script is executed to perform >>> ConfigurationData transformations. >>> >>> If any of these two options are plausible solutions, then I am happy to >>> move forward with an implementation. >>> >>> Thanks, >>> Gianny >>> >>> >>>> thanks >>>> david jencks >>>> >>>> >> > -- ~Jason Warner
Re: Where will ee6 development take place?
see inline On Wed, Oct 15, 2008 at 7:50 PM, David Jencks <[EMAIL PROTECTED]>wrote: > I realize I've been assuming that we'll just develop ee6 features in trunk > and release 2.2 with a bunch or all of ee6 implemented. I have some > connector 1.6 stuff I'm about to commit > That was my assumption as well. > > This attitude might cause tck problems especially with signature tests. On > the other hand maybe we can get signature updates. > I think a trunk build is the perfect place to introduce tck problems, so long as they can be resolved before a release. I think this could be discussed further and in more detail, but would prefer to do that on the tck list. > > What do other people think we should do? > > thanks > david jencks > > -- ~Jason Warner
[jira] Commented: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639554#action_12639554 ] Jason Warner commented on GERONIMO-4335: Discussion on this change can be found here: http://www.nabble.com/An-idea-for-defining-custom-valves-in-config.xml-td19804490s134.html > Implement the ability to define a custom valve in config.xml > > > Key: GERONIMO-4335 > URL: https://issues.apache.org/jira/browse/GERONIMO-4335 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.3, 2.2 >Reporter: Jason Warner >Assignee: Jason Warner > > There currently is no good way to define a custom valve in config.xml. There > are a couple of work arounds [1][2] that will result in the desired > functionality, but i believe there should be a simpler and more intuitive way > to accomplish this goal. > [1] https://issues.apache.org/jira/browse/GERONIMO-4113 > [2] > http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: An idea for defining custom valves in config.xml
David, I've been trying to follow your steps and seem to be having issues accomplishing the goal. Please see questions inline. On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote: > > Jason Warner wrote: >> >>> Thanks for the explanation, David. I don't disagree with anything you've >>> explained, but I'm not sure you've addressed my concern about the disparity >>> in the effort required to deploy a custom valve on tomcat and on geronimo. >>> Even with the a streamlined process involving a tomcat server portlet and >>> using the tomcat6 plugin as a base, the user still has to become a plugin >>> developer to deploy their valve on geronimo. If that's how it has to be, >>> then I suppose that's how it has to be. I'm just concerned that it could >>> turn off users that might have otherwise lived happily with geronimo. I'm >>> not really sure how widespread the use of custom valves are, though, so >>> maybe it's just a small minority this would even effect. I'd be curious to >>> get some feedback from some other developers and see if they have any >>> thoughts on the matter. Anyone else out there keeping an eye on this >>> thread? >>> >> >> I've been keeping an eye on it and I agree with you Jason that there is a >> disparity in the work required to add a valve to tomcat versus that required >> to add a valve to tomcat embedded in Geronimo. I also agree with David that >> the current Tomcat process does not lend itself to a reproducible >> configuration. >> >> In cases like this I tend to think like a politician and advocate a >> both/and rather than an either/or. I suspect that some users will want >> things in Geronimo to be as similar to Tomcat as possible ... and so will >> want a simple configuration solution. Doing so might convince them to move >> over to Geronimo and over time they may gain a greater appreciation for a >> more Geronimo like solution. Others might be coming in with more knowledge >> of Geronimo and expect something that is more consistent with Geronimo and >> can be reproduced. Can we give them both what they want? >> >> It seems like we could help the Tomcat centric folks with a simple >> configuration attribute that we can use to extend the classpath. For the >> more sophisticated Geronimo user we can direct them to rebuild/redeploy the >> Tomcat module with the additional dependency on the valve jar ... perhaps >> using c-m-p and then their own custom assembly. Even while providing the >> first approach we can highly recommend the second approach. >> >> It seems to me that the attribute/classpath extension is a simple thing to >> implement and will provide a high level of value to users that are >> accustomed to Tomcat. The Tomcat module rebuild/redeploy is just a matter >> of documentation ... correct? >> > > I guess I'm trying to argue that we should be making doing the "right > thing" as easy as modifying tomcat to have a custom valve. > > I'm not convinced we're all that far off: > > tomcat -stop server > geronimo - server restart may be needed later. > > tomcat - add jar to server/lib (?) > geronimo - add jar to repository > > tomcat - edit server.xml > geronmo -edit tomcat6 plam.xml > > geronimo - add artifact-alias (this could probably be automated into part > of the next step). Basically this should be editing the > geronimo-plugin.xml. Which geronimo-plugin.xml am I editing here? I tried editing the original tomcat6 plugin but that didn't seem to work. > > geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin. > > tomcat - restart > geronimo - restart tomcat-dependent plugins/apps > Was your intention to have this new plugin run in parallel with the original tomcat6 plugin? I'm not sure it would be necessary to have them both run. > > > There's basically only one more step in geronimo. I'm not sure how well > the "obsoletes" functionality works at the moment but ideally we could have > the new plugin obsolete the original and so installing it would shut down > the old one, shut down the plugins depending on it, and restart the > dependencies after install. This is the same number of steps. > > One missing bit here is that there is no good way to deploy an app with an > external geronimo-plugin.xml to end up immediately with a plugin. > I'm confused. One of your steps said to deploy the plan.xml and that would result in a
Re: An idea for defining custom valves in config.xml
On Wed, Oct 8, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 8, 2008, at 1:55 PM, Joe Bohn wrote: > > Jason Warner wrote: >> >>> Thanks for the explanation, David. I don't disagree with anything you've >>> explained, but I'm not sure you've addressed my concern about the disparity >>> in the effort required to deploy a custom valve on tomcat and on geronimo. >>> Even with the a streamlined process involving a tomcat server portlet and >>> using the tomcat6 plugin as a base, the user still has to become a plugin >>> developer to deploy their valve on geronimo. If that's how it has to be, >>> then I suppose that's how it has to be. I'm just concerned that it could >>> turn off users that might have otherwise lived happily with geronimo. I'm >>> not really sure how widespread the use of custom valves are, though, so >>> maybe it's just a small minority this would even effect. I'd be curious to >>> get some feedback from some other developers and see if they have any >>> thoughts on the matter. Anyone else out there keeping an eye on this >>> thread? >>> >> >> I've been keeping an eye on it and I agree with you Jason that there is a >> disparity in the work required to add a valve to tomcat versus that required >> to add a valve to tomcat embedded in Geronimo. I also agree with David that >> the current Tomcat process does not lend itself to a reproducible >> configuration. >> >> In cases like this I tend to think like a politician and advocate a >> both/and rather than an either/or. I suspect that some users will want >> things in Geronimo to be as similar to Tomcat as possible ... and so will >> want a simple configuration solution. Doing so might convince them to move >> over to Geronimo and over time they may gain a greater appreciation for a >> more Geronimo like solution. Others might be coming in with more knowledge >> of Geronimo and expect something that is more consistent with Geronimo and >> can be reproduced. Can we give them both what they want? >> >> It seems like we could help the Tomcat centric folks with a simple >> configuration attribute that we can use to extend the classpath. For the >> more sophisticated Geronimo user we can direct them to rebuild/redeploy the >> Tomcat module with the additional dependency on the valve jar ... perhaps >> using c-m-p and then their own custom assembly. Even while providing the >> first approach we can highly recommend the second approach. >> >> It seems to me that the attribute/classpath extension is a simple thing to >> implement and will provide a high level of value to users that are >> accustomed to Tomcat. The Tomcat module rebuild/redeploy is just a matter >> of documentation ... correct? >> > > I guess I'm trying to argue that we should be making doing the "right > thing" as easy as modifying tomcat to have a custom valve. > > I'm not convinced we're all that far off: > > tomcat -stop server > geronimo - server restart may be needed later. > > tomcat - add jar to server/lib (?) > geronimo - add jar to repository > > tomcat - edit server.xml > geronmo -edit tomcat6 plam.xml > > geronimo - add artifact-alias (this could probably be automated into part > of the next step). Basically this should be editing the > geronimo-plugin.xml. > geronimo - deploy modified tomcat6 plan.xml, resulting in a new plugin. I seem to be having issues with this step. It's probably something I'm doing, though. Is there a good example of the artifact-alias element in action? My issue seems to be that I can't disable the tomcat6 plugin because modules that are dependent upon it restart it automatically when the server is started. At least, this is what I believe is happening. This results in port conflicts and such when my custom tomcat6 module is started. Shouldn't the artifact-alias be pointing the dependent modules to the custom module instead of the default tomcat6 plugin? If not, perhaps that's functionality we should add. It's possible I'm specifying the artifact-alias incorrectly or in the wrong place, which is why I'm asking for an example where this is done. I see it mentioned a few times in the documentation, but it's usually either out of context or not detailed enough. Thanks! > > tomcat - restart > geronimo - restart tomcat-dependent plugins/apps > > > There's basically only one more step in geronimo. I'm not sure how well > the "obsoletes" functionality works at the moment b
Re: Continuous TCK Testing
My apologies. I didn't phrase my question properly. Most of the software necessary was pulled down via svn, but I saw no such behaviour for AHP. After looking at it some more, I imagine the software was just manually installed on the machine. It was kind of a silly question to begin with, I suppose. On Thu, Oct 9, 2008 at 4:16 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Oct 8, 2008, at 11:05 PM, Jason Warner wrote: > > Here's a quick question. Where does AHP come from? > > > http://www.anthillpro.com > > (ever heard of google :-P) > > --jason > > > > On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: > >> Sure np, took me a while to get around to writing it too ;-) >> --jason >> >> >> On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: >> >> Just got around to reading this. Thanks for the brain dump, Jason. No >> questions as of yet, but I'm sure I'll need a few more reads before I >> understand it all. >> >> On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: >> >>> On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: >>> >>> Is the GBuild stuff in svn the same as the anthill-based code or is that >>>> something different? GBuild seems to have scripts for running tck and that >>>> leads me to think they're the same thing, but I see no mention of anthill >>>> in >>>> the code. >>>> >>> >>> The Anthill stuff is completely different than the GBuild stuff. I >>> started out trying to get the TCK automated using GBuild, but decided that >>> the system lacked too many features to perform as I desired, and went ahead >>> with Anthill as it did pretty much everything, though had some stability >>> problems. >>> >>> One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) >>> was its build agent and code repository systems. This allowed me to ensure >>> that each build used exactly the desired artifacts. Another was the >>> configurable workflow, which allowed me to create a custom chain of events >>> to handle running builds on remote agents and control what data gets set to >>> them, what it will collect and what logic to execute once all distributed >>> work has been completed for a particular build. And the kicker which help >>> facilitate bringing it all together was its concept of a build life. >>> >>> At the time I could find *no other* build tool which could meet all of >>> these needs, and so I went with AHP instead of spending months >>> building/testing features in GBuild. >>> >>> While AHP supports configuring a lot of stuff via its web-interface, I >>> found that it was very cumbersome, so I opted to write some glue, which was >>> stored in svn here: >>> >>> >>> https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 >>> >>> Its been a while, so I have to refresh my memory on how this stuff >>> actually worked. First let me explain about the code repository (what it >>> calls codestation) and why it was critical to the TCK testing IMO. When we >>> use Maven normally, it pulls data from a set of external repositories, picks >>> up more repositories from the stuff it downloads and quickly we loose >>> control where stuff comes from. After it pulls down all that stuff, it >>> churns though a build and spits out the stuff we care about, normally >>> stuffing them (via mvn install) into the local repository. >>> >>> AHP supports by default tasks to publish artifacts (really just a set of >>> files controlled by an Ant-like include/exclude path) from a build agent >>> into Codestation, as well as tasks to resolve artifacts (ie. download them >>> from Codestation to the local working directory on the build agents system). >>> Each top-level build in AHP gets assigned a new (empty) build life. >>> Artifacts are always published to/resolved from a build life, either that >>> of the current build, or of a dependency build. >>> >>> So what I did was I setup builds for Geronimo Server (the normal >>> server/trunk stuff), which did the normal mvn install thingy, but I always >>> gave it a custom -Dmaven.local.repository which resolved to something inside >>> the working directory for the running build. The build was still online, so >>> it pulled down a bunch of stuff into an empty local repository (so it was a >>> clean build w
Re: Continuous TCK Testing
We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? Thanks, On Wed, Oct 8, 2008 at 12:05 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > Here's a quick question. Where does AHP come from? > > On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: > >> Sure np, took me a while to get around to writing it too ;-) >> --jason >> >> >> On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: >> >> Just got around to reading this. Thanks for the brain dump, Jason. No >> questions as of yet, but I'm sure I'll need a few more reads before I >> understand it all. >> >> On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: >> >>> On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: >>> >>> Is the GBuild stuff in svn the same as the anthill-based code or is that >>>> something different? GBuild seems to have scripts for running tck and that >>>> leads me to think they're the same thing, but I see no mention of anthill >>>> in >>>> the code. >>>> >>> >>> The Anthill stuff is completely different than the GBuild stuff. I >>> started out trying to get the TCK automated using GBuild, but decided that >>> the system lacked too many features to perform as I desired, and went ahead >>> with Anthill as it did pretty much everything, though had some stability >>> problems. >>> >>> One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) >>> was its build agent and code repository systems. This allowed me to ensure >>> that each build used exactly the desired artifacts. Another was the >>> configurable workflow, which allowed me to create a custom chain of events >>> to handle running builds on remote agents and control what data gets set to >>> them, what it will collect and what logic to execute once all distributed >>> work has been completed for a particular build. And the kicker which help >>> facilitate bringing it all together was its concept of a build life. >>> >>> At the time I could find *no other* build tool which could meet all of >>> these needs, and so I went with AHP instead of spending months >>> building/testing features in GBuild. >>> >>> While AHP supports configuring a lot of stuff via its web-interface, I >>> found that it was very cumbersome, so I opted to write some glue, which was >>> stored in svn here: >>> >>> >>> https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 >>> >>> Its been a while, so I have to refresh my memory on how this stuff >>> actually worked. First let me explain about the code repository (what it >>> calls codestation) and why it was critical to the TCK testing IMO. When we >>> use Maven normally, it pulls data from a set of external repositories, picks >>> up more repositories from the stuff it downloads and quickly we loose >>> control where stuff comes from. After it pulls down all that stuff, it >>> churns though a build and spits out the stuff we care about, normally >>> stuffing them (via mvn install) into the local repository. >>> >>> AHP supports by default tasks to publish artifacts (really just a set of >>> files controlled by an Ant-like include/exclude path) from a build agent >>> into Codestation, as well as tasks to resolve artifacts (ie. download them >>> from Codestation to the local working directory on the build agents system). >>> Each top-level build in AHP gets assigned a new (empty) build life. >>> Artifacts are always published to/resolved from a build life, either that >>> of the current build, or of a dependency build. >>> >>> So what I did was I setup builds for Geronimo Server (the normal >>> server/trunk stuff), which did the normal mvn install thingy, but I always >>> gave it a custom -Dmaven.local.repository which resolved to something inside >>> the working directory for the running build. The build was still online, so >>> it pulled down a
Re: An idea for defining custom valves in config.xml
Thanks for the explanation, David. I don't disagree with anything you've explained, but I'm not sure you've addressed my concern about the disparity in the effort required to deploy a custom valve on tomcat and on geronimo. Even with the a streamlined process involving a tomcat server portlet and using the tomcat6 plugin as a base, the user still has to become a plugin developer to deploy their valve on geronimo. If that's how it has to be, then I suppose that's how it has to be. I'm just concerned that it could turn off users that might have otherwise lived happily with geronimo. I'm not really sure how widespread the use of custom valves are, though, so maybe it's just a small minority this would even effect. I'd be curious to get some feedback from some other developers and see if they have any thoughts on the matter. Anyone else out there keeping an eye on this thread? On Wed, Oct 8, 2008 at 2:25 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 8, 2008, at 11:04 AM, Jason Warner wrote: > > I'm not sure if these steps are reasonable from a purely user perspective. > When using plain old tomcat, you can download a binary, add your custom > valve jar, make a config change and then use your server with its custom > valve. To accomplish the same task in geronimo, we are asking the user to > download and install maven as well as grab source code for the tomcat > plugin. I'd really like to have a way we can accomplish the same goal while > allowing the users to maintain a user level of interaction with geronimo. > > > I think (1) is really a more realistic approach philosophically so I'll > only discuss it more. > > Lets consider the results of the modifications on tomcat and geronimo. > > In tomcat, the user has modified their server installation and has no > built-in record of what they did. If they install another server somewhere > else they have to look in their notes or try to remember what they did or > ??? to get the same result. > > In geronimo + maven they have a reproducible and automated way to generate > the customization that is suitable for storing in scm, auditing, running > through qa, etc etc. > > Its also possible to fish the plan out of the tomcat6 plugin, modify it a > bit, and deploy it using gshell or (if you didn't start it) using the > console. I think you could add the geronimo-plugin.xml using the admin > console and add the artifact-aias. This on export would result in a > reusable plugin. I'm not sure if you could turn around and install the > plugin on the server it was generated on to install the artifact alias so on > the next startup you'd get the new tomcat plugin. > > My philosophical objection to adding valves to the existing tomcat config > is that you've changed it in a fundamental way so you should have a new, > replacement, plugin instead. By this point you can add the extra jar(s) > anyway as dependencies. > > Maybe we could have a tomcat server portlet that would help with > generating tomcat server plans with custom valves and connectors and such > stuff. I think that right now that is still the hardest part. > > thanks > david jencks > > > > On Wed, Oct 8, 2008 at 1:22 PM, David Jencks <[EMAIL PROTECTED]>wrote: > >> >> On Oct 8, 2008, at 7:45 AM, Jason Warner wrote: >> >> David, >> >> Could you describe to me in a little more detail what you were thinking in >> regards to defining a new tomcat server in a child classloader? I'm still >> working on creating an example, but I found some documentation confirming >> tomcat's use of a TCCL in loading components and would like to continue the >> discussion. It seems you are proposing that a user create a plugin that >> defines a new tomcat instance that includes their custom valve. Am I >> understanding correctly? I've taken a look at the app-per-port sample you >> described and this does not seem like a trivial task. >> >> >> app-per-port is complicated by the additional features there of: >> - only one artifact (an ear) instead of 2 or 3 plugins >> - starting the connectors after the web app has started >> >> If neither of these features is needed you can just build a plugin with >> the tomcat server + custom valve. There are two strategies: >> 1. replace the tomcat6 plugin >> 2. use the (stopped) tomcat6 plugin as a parent for the new plugin. >> >> In either case I'd build the new plugin with maven and start by copying >> the tomcat6 plugin and renaming it appropriately. Then modify the plan to >> include the custom valve. >> >> for (1), you'd
Re: An idea for defining custom valves in config.xml
I'm not sure if these steps are reasonable from a purely user perspective. When using plain old tomcat, you can download a binary, add your custom valve jar, make a config change and then use your server with its custom valve. To accomplish the same task in geronimo, we are asking the user to download and install maven as well as grab source code for the tomcat plugin. I'd really like to have a way we can accomplish the same goal while allowing the users to maintain a user level of interaction with geronimo. On Wed, Oct 8, 2008 at 1:22 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 8, 2008, at 7:45 AM, Jason Warner wrote: > > David, > > Could you describe to me in a little more detail what you were thinking in > regards to defining a new tomcat server in a child classloader? I'm still > working on creating an example, but I found some documentation confirming > tomcat's use of a TCCL in loading components and would like to continue the > discussion. It seems you are proposing that a user create a plugin that > defines a new tomcat instance that includes their custom valve. Am I > understanding correctly? I've taken a look at the app-per-port sample you > described and this does not seem like a trivial task. > > > app-per-port is complicated by the additional features there of: > - only one artifact (an ear) instead of 2 or 3 plugins > - starting the connectors after the web app has started > > If neither of these features is needed you can just build a plugin with the > tomcat server + custom valve. There are two strategies: > 1. replace the tomcat6 plugin > 2. use the (stopped) tomcat6 plugin as a parent for the new plugin. > > In either case I'd build the new plugin with maven and start by copying the > tomcat6 plugin and renaming it appropriately. Then modify the plan to > include the custom valve. > > for (1), you'd just add the jar with the custom valve as a pom dependency. > Use an artifact-alias so your tomcat plugin will replace the usual tomcat6 > plugin. > for (2), you'd replace the pom dependencies with a dependency on the > tomcat6 plugin, and add the custom valve jar dependency. In the c-m-p > configuration you'll want to specify the import on the tomcat^ plugin as > "classes" so it wont get started. An artifact alias won't work here so > don't deploy things that depend on tomcat6 as that will result in the > tomcat6 plugin starting and having port conflicts with your plugin. > > Building a custom server including your plugin or installing it on a > framework server via gshell is likely to work better than trying to replace > the tomcat6 plugin while it's running through the admin console. > > hope this helps > david jencks > > > > > > > Thanks, > > On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > >> >> >> On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]>wrote: >> >>> >>> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: >>> >>> >>> >>> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote: >>> >>>> >>>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: >>>> >>>> >>>> >>>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote: >>>> >>>>> >>>>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: >>>>> >>>>> Hey all. I'm working on an idea for allowing custom valves to be >>>>> defined in config.xml. Currently this isn't possible since the tomcat >>>>> classloader would not contain the custom classes for the valve. I've >>>>> create >>>>> a jira for tracking this issue [1] and it contains a few links to >>>>> workarounds. IMHO, The solution we should be looking for is a way to add >>>>> classes to a module without having to undeploy, modify the module config, >>>>> and redeploying. >>>>> >>>>> >>>>> People have suggested stuff like this before. IMO it pretty much goes >>>>> against the fundamental idea of geronimo of having fairly fixed plugins >>>>> with >>>>> only a few knobs to turn to adjust things in config.xml and >>>>> config-substitutions.properties. >>>>> >>>>> Why is changing the classloader contents in config.xml a good idea? >>>>> What is so hard about redeploying the app if you want to change its >>>>> classloader signif
Re: Continuous TCK Testing
Here's a quick question. Where does AHP come from? On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Sure np, took me a while to get around to writing it too ;-) > --jason > > > On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: > > Just got around to reading this. Thanks for the brain dump, Jason. No > questions as of yet, but I'm sure I'll need a few more reads before I > understand it all. > > On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: > >> On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: >> >> Is the GBuild stuff in svn the same as the anthill-based code or is that >>> something different? GBuild seems to have scripts for running tck and that >>> leads me to think they're the same thing, but I see no mention of anthill in >>> the code. >>> >> >> The Anthill stuff is completely different than the GBuild stuff. I >> started out trying to get the TCK automated using GBuild, but decided that >> the system lacked too many features to perform as I desired, and went ahead >> with Anthill as it did pretty much everything, though had some stability >> problems. >> >> One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) >> was its build agent and code repository systems. This allowed me to ensure >> that each build used exactly the desired artifacts. Another was the >> configurable workflow, which allowed me to create a custom chain of events >> to handle running builds on remote agents and control what data gets set to >> them, what it will collect and what logic to execute once all distributed >> work has been completed for a particular build. And the kicker which help >> facilitate bringing it all together was its concept of a build life. >> >> At the time I could find *no other* build tool which could meet all of >> these needs, and so I went with AHP instead of spending months >> building/testing features in GBuild. >> >> While AHP supports configuring a lot of stuff via its web-interface, I >> found that it was very cumbersome, so I opted to write some glue, which was >> stored in svn here: >> >> >> https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 >> >> Its been a while, so I have to refresh my memory on how this stuff >> actually worked. First let me explain about the code repository (what it >> calls codestation) and why it was critical to the TCK testing IMO. When we >> use Maven normally, it pulls data from a set of external repositories, picks >> up more repositories from the stuff it downloads and quickly we loose >> control where stuff comes from. After it pulls down all that stuff, it >> churns though a build and spits out the stuff we care about, normally >> stuffing them (via mvn install) into the local repository. >> >> AHP supports by default tasks to publish artifacts (really just a set of >> files controlled by an Ant-like include/exclude path) from a build agent >> into Codestation, as well as tasks to resolve artifacts (ie. download them >> from Codestation to the local working directory on the build agents system). >> Each top-level build in AHP gets assigned a new (empty) build life. >> Artifacts are always published to/resolved from a build life, either that >> of the current build, or of a dependency build. >> >> So what I did was I setup builds for Geronimo Server (the normal >> server/trunk stuff), which did the normal mvn install thingy, but I always >> gave it a custom -Dmaven.local.repository which resolved to something inside >> the working directory for the running build. The build was still online, so >> it pulled down a bunch of stuff into an empty local repository (so it was a >> clean build wrt the repository, as well as the source code, which was always >> fetched for each new build). Once the build had finished, I used the >> artifact publisher task to push *all* of the stuff in the local repository >> into Codestation, labled as something like "Maven repository artifacts" for >> the current build life. >> >> Then I setup another build for Apache Geronimo CTS Server (the >> porting/branches/* stuff). This build was dependent upon the "Maven >> repository artifacts" of the Geronimo Server build, and I configured those >> artifacts to get installed on the build agents system in the same directory >> that I configured the CTS Server build to use for its local maven >> repository. So again the repo started out empty, then got populated with >> all of the ou
Re: An idea for defining custom valves in config.xml
David, Could you describe to me in a little more detail what you were thinking in regards to defining a new tomcat server in a child classloader? I'm still working on creating an example, but I found some documentation confirming tomcat's use of a TCCL in loading components and would like to continue the discussion. It seems you are proposing that a user create a plugin that defines a new tomcat instance that includes their custom valve. Am I understanding correctly? I've taken a look at the app-per-port sample you described and this does not seem like a trivial task. Thanks, On Mon, Oct 6, 2008 at 3:08 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > > > On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]>wrote: > >> >> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: >> >> >> >> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote: >> >>> >>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: >>> >>> >>> >>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote: >>> >>>> >>>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: >>>> >>>> Hey all. I'm working on an idea for allowing custom valves to be >>>> defined in config.xml. Currently this isn't possible since the tomcat >>>> classloader would not contain the custom classes for the valve. I've >>>> create >>>> a jira for tracking this issue [1] and it contains a few links to >>>> workarounds. IMHO, The solution we should be looking for is a way to add >>>> classes to a module without having to undeploy, modify the module config, >>>> and redeploying. >>>> >>>> >>>> People have suggested stuff like this before. IMO it pretty much goes >>>> against the fundamental idea of geronimo of having fairly fixed plugins >>>> with >>>> only a few knobs to turn to adjust things in config.xml and >>>> config-substitutions.properties. >>>> >>>> Why is changing the classloader contents in config.xml a good idea? >>>> What is so hard about redeploying the app if you want to change its >>>> classloader significantly? If you want to change a class in the app you >>>> have to redeploy it why is this situation different? >>>> >>> >>> The specific instance I have in mind for this change is using a custom >>> valve for tomcat, so I think the scope really should be limited to just the >>> tomcat module. I can't think of another instance where this would be >>> useful, so it's probably not necessary or desirable to expand it further. I >>> believe this situation is different because the structure of geronimo is >>> causing a disconnect between the functionality of tomcat and the >>> functionality of tomcat as it is embedded in geronimo. As Don just said in >>> the middle of my typing this, I don't believe we should expect the average >>> user to have to rebuild one of our modules to add something that can be >>> added in a much simpler way within tomcat itself. >>> >>> >>> Could you explain more about the circumstances for this custom valve? Is >>> it intended to be for every app deployed on this tomcat server instance >>> rather than for one particular app? Will it work if it is in a child >>> classloader of the tomcat plugin classloader? >>> >> >> When a valve is added to the tomcat valve chain, it becomes part of >> the request processing pipeline. Every request that is made to that tomcat >> server instance passes through this valve chain as it's processed regardless >> of whether the valve will act upon it or not. It's possible that a single >> web app will be the only app to use the valve, and for that instance it is >> already possible to define the valve in the context of the web app rather >> than the tomcat server. We need to be able to define a valve as part of >> tomcat server instance as well, though, to be consistent with tomcat. >> Currently we can only define the valves on the per web app basis. >> I don't think this would work in a child classloader of the tomcat >> plugin classloader. When we start up the tomcat module now, the currently >> defined valves are processed and added to the engine. The custom valves >> would need to be added to the valves already in the tomcat engine to be >> available in the way described previously. Once the valves were ad
Re: An idea for defining custom valves in config.xml
On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 6, 2008, at 10:35 AM, Jason Warner wrote: > > > > On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote: > >> >> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: >> >> >> >> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote: >> >>> >>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: >>> >>> Hey all. I'm working on an idea for allowing custom valves to be >>> defined in config.xml. Currently this isn't possible since the tomcat >>> classloader would not contain the custom classes for the valve. I've create >>> a jira for tracking this issue [1] and it contains a few links to >>> workarounds. IMHO, The solution we should be looking for is a way to add >>> classes to a module without having to undeploy, modify the module config, >>> and redeploying. >>> >>> >>> People have suggested stuff like this before. IMO it pretty much goes >>> against the fundamental idea of geronimo of having fairly fixed plugins with >>> only a few knobs to turn to adjust things in config.xml and >>> config-substitutions.properties. >>> >>> Why is changing the classloader contents in config.xml a good idea? What >>> is so hard about redeploying the app if you want to change its classloader >>> significantly? If you want to change a class in the app you have to >>> redeploy it why is this situation different? >>> >> >> The specific instance I have in mind for this change is using a custom >> valve for tomcat, so I think the scope really should be limited to just the >> tomcat module. I can't think of another instance where this would be >> useful, so it's probably not necessary or desirable to expand it further. I >> believe this situation is different because the structure of geronimo is >> causing a disconnect between the functionality of tomcat and the >> functionality of tomcat as it is embedded in geronimo. As Don just said in >> the middle of my typing this, I don't believe we should expect the average >> user to have to rebuild one of our modules to add something that can be >> added in a much simpler way within tomcat itself. >> >> >> Could you explain more about the circumstances for this custom valve? Is >> it intended to be for every app deployed on this tomcat server instance >> rather than for one particular app? Will it work if it is in a child >> classloader of the tomcat plugin classloader? >> > > When a valve is added to the tomcat valve chain, it becomes part of the > request processing pipeline. Every request that is made to that tomcat > server instance passes through this valve chain as it's processed regardless > of whether the valve will act upon it or not. It's possible that a single > web app will be the only app to use the valve, and for that instance it is > already possible to define the valve in the context of the web app rather > than the tomcat server. We need to be able to define a valve as part of > tomcat server instance as well, though, to be consistent with tomcat. > Currently we can only define the valves on the per web app basis. > I don't think this would work in a child classloader of the tomcat > plugin classloader. When we start up the tomcat module now, the currently > defined valves are processed and added to the engine. The custom valves > would need to be added to the valves already in the tomcat engine to be > available in the way described previously. Once the valves were added to > the engine (which would be using the tomcat classloader, I believe) the > class def not found issues we currently see would pop back up. For this to > work, the custom valve classes and the tomcat engine would need to share the > same classloader. > > > Could you try this to be sure? I would hope that tomcat would use a TCCL > or supplied classloader for loading components rather than something like > TomcatEngine.class.getClassLoader() which I believe is what you are > suggesting it does. > > One example of an inconvenient tomcat configuration is the app-per-port > sample where we set up a whole additional tomcat server in a child > configuration. I think all the server components in that example are also > in a standard tomcat server but its a similar situation to what I'm thinking > of here in terms of configuring a tomcat server in a child classloader. > > Sure. It'll take me a bit as I don't actually have any
Re: An idea for defining custom valves in config.xml
On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote: > > On Oct 6, 2008, at 7:22 AM, Jason Warner wrote: > > > > On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote: > >> >> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: >> >> Hey all. I'm working on an idea for allowing custom valves to be >> defined in config.xml. Currently this isn't possible since the tomcat >> classloader would not contain the custom classes for the valve. I've create >> a jira for tracking this issue [1] and it contains a few links to >> workarounds. IMHO, The solution we should be looking for is a way to add >> classes to a module without having to undeploy, modify the module config, >> and redeploying. >> >> >> People have suggested stuff like this before. IMO it pretty much goes >> against the fundamental idea of geronimo of having fairly fixed plugins with >> only a few knobs to turn to adjust things in config.xml and >> config-substitutions.properties. >> >> Why is changing the classloader contents in config.xml a good idea? What >> is so hard about redeploying the app if you want to change its classloader >> significantly? If you want to change a class in the app you have to >> redeploy it why is this situation different? >> > > The specific instance I have in mind for this change is using a custom > valve for tomcat, so I think the scope really should be limited to just the > tomcat module. I can't think of another instance where this would be > useful, so it's probably not necessary or desirable to expand it further. I > believe this situation is different because the structure of geronimo is > causing a disconnect between the functionality of tomcat and the > functionality of tomcat as it is embedded in geronimo. As Don just said in > the middle of my typing this, I don't believe we should expect the average > user to have to rebuild one of our modules to add something that can be > added in a much simpler way within tomcat itself. > > > Could you explain more about the circumstances for this custom valve? Is > it intended to be for every app deployed on this tomcat server instance > rather than for one particular app? Will it work if it is in a child > classloader of the tomcat plugin classloader? > When a valve is added to the tomcat valve chain, it becomes part of the request processing pipeline. Every request that is made to that tomcat server instance passes through this valve chain as it's processed regardless of whether the valve will act upon it or not. It's possible that a single web app will be the only app to use the valve, and for that instance it is already possible to define the valve in the context of the web app rather than the tomcat server. We need to be able to define a valve as part of tomcat server instance as well, though, to be consistent with tomcat. Currently we can only define the valves on the per web app basis. I don't think this would work in a child classloader of the tomcat plugin classloader. When we start up the tomcat module now, the currently defined valves are processed and added to the engine. The custom valves would need to be added to the valves already in the tomcat engine to be available in the way described previously. Once the valves were added to the engine (which would be using the tomcat classloader, I believe) the class def not found issues we currently see would pop back up. For this to work, the custom valve classes and the tomcat engine would need to share the same classloader. > > At the moment I would MUCH rather see us make it easier for users to deploy > new/different/modified tomcat servers (and other plugins) than introduce a > hack to modify classloaders of existing plugins. Our customization story is > already too complicated, IMO we don't need to glue on more bits that don't > actually fit well. > > IMO the best end result for users is to have a new tomcat plugin with the > needed extra jars and valve configuration. Lets look for a way to make it > really easy for our users to get there. > I agree that a whole new plugin with all desired functionality included would be best for users. Any ideas how to make this easier than it currently is? Perhaps the attribute idea mentioned by Joe could serve as a temporary solution until we can come up with something better. > > How would you deal with this in an osgi or spring environment? > > thanks > david jencks > > > > Thanks! > >> >> thanks >> david jencks >> >> >> I think this can be done by allowing a user to indicate jars that should >> be loaded by a module wit
Re: Continuous TCK Testing
Just got around to reading this. Thanks for the brain dump, Jason. No questions as of yet, but I'm sure I'll need a few more reads before I understand it all. On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: > > Is the GBuild stuff in svn the same as the anthill-based code or is that >> something different? GBuild seems to have scripts for running tck and that >> leads me to think they're the same thing, but I see no mention of anthill in >> the code. >> > > The Anthill stuff is completely different than the GBuild stuff. I started > out trying to get the TCK automated using GBuild, but decided that the > system lacked too many features to perform as I desired, and went ahead with > Anthill as it did pretty much everything, though had some stability > problems. > > One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was > its build agent and code repository systems. This allowed me to ensure that > each build used exactly the desired artifacts. Another was the configurable > workflow, which allowed me to create a custom chain of events to handle > running builds on remote agents and control what data gets set to them, what > it will collect and what logic to execute once all distributed work has been > completed for a particular build. And the kicker which help facilitate > bringing it all together was its concept of a build life. > > At the time I could find *no other* build tool which could meet all of > these needs, and so I went with AHP instead of spending months > building/testing features in GBuild. > > While AHP supports configuring a lot of stuff via its web-interface, I > found that it was very cumbersome, so I opted to write some glue, which was > stored in svn here: > > > https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 > > Its been a while, so I have to refresh my memory on how this stuff actually > worked. First let me explain about the code repository (what it calls > codestation) and why it was critical to the TCK testing IMO. When we use > Maven normally, it pulls data from a set of external repositories, picks up > more repositories from the stuff it downloads and quickly we loose control > where stuff comes from. After it pulls down all that stuff, it churns > though a build and spits out the stuff we care about, normally stuffing them > (via mvn install) into the local repository. > > AHP supports by default tasks to publish artifacts (really just a set of > files controlled by an Ant-like include/exclude path) from a build agent > into Codestation, as well as tasks to resolve artifacts (ie. download them > from Codestation to the local working directory on the build agents system). > Each top-level build in AHP gets assigned a new (empty) build life. > Artifacts are always published to/resolved from a build life, either that > of the current build, or of a dependency build. > > So what I did was I setup builds for Geronimo Server (the normal > server/trunk stuff), which did the normal mvn install thingy, but I always > gave it a custom -Dmaven.local.repository which resolved to something inside > the working directory for the running build. The build was still online, so > it pulled down a bunch of stuff into an empty local repository (so it was a > clean build wrt the repository, as well as the source code, which was always > fetched for each new build). Once the build had finished, I used the > artifact publisher task to push *all* of the stuff in the local repository > into Codestation, labled as something like "Maven repository artifacts" for > the current build life. > > Then I setup another build for Apache Geronimo CTS Server (the > porting/branches/* stuff). This build was dependent upon the "Maven > repository artifacts" of the Geronimo Server build, and I configured those > artifacts to get installed on the build agents system in the same directory > that I configured the CTS Server build to use for its local maven > repository. So again the repo started out empty, then got populated with > all of the outputs from the normal G build, and then the cts-server build > was started. The build of the components and assemblies is normally fairly > quick and aside from some stuff in the private tck repo won't download muck > more stuff, because it already had most of its dependencies installed via > the Codestation dependency resolution. Once the build finished, I > published to cts-server assembly artifacts back to Codestation under like > "CTS Server Assemblies" or something. > > Up until this point its normal builds, but now we have built the
Re: An idea for defining custom valves in config.xml
On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 3, 2008, at 12:51 PM, Jason Warner wrote: > > Hey all. I'm working on an idea for allowing custom valves to be defined > in config.xml. Currently this isn't possible since the tomcat classloader > would not contain the custom classes for the valve. I've create a jira for > tracking this issue [1] and it contains a few links to workarounds. IMHO, > The solution we should be looking for is a way to add classes to a module > without having to undeploy, modify the module config, and redeploying. > > > People have suggested stuff like this before. IMO it pretty much goes > against the fundamental idea of geronimo of having fairly fixed plugins with > only a few knobs to turn to adjust things in config.xml and > config-substitutions.properties. > > Why is changing the classloader contents in config.xml a good idea? What > is so hard about redeploying the app if you want to change its classloader > significantly? If you want to change a class in the app you have to > redeploy it why is this situation different? > The specific instance I have in mind for this change is using a custom valve for tomcat, so I think the scope really should be limited to just the tomcat module. I can't think of another instance where this would be useful, so it's probably not necessary or desirable to expand it further. I believe this situation is different because the structure of geronimo is causing a disconnect between the functionality of tomcat and the functionality of tomcat as it is embedded in geronimo. As Don just said in the middle of my typing this, I don't believe we should expect the average user to have to rebuild one of our modules to add something that can be added in a much simpler way within tomcat itself. Thanks! > > thanks > david jencks > > > I think this can be done by allowing a user to indicate jars that should be > loaded by a module within the config.xml. These jars can then be added to > the module's classloader for use by the module. I'm not extremely familiar > with how our classloader works, but I've taken a look through the code and I > think the ability to add to the classloader can be implemented without too > much difficulty. I'm not quite sure what type of scope to give this change, > though. Should I leave it as a change aimed solely at tomcat valves or > should it be expanded to encompass any configuration? I realize this is > only a rough idea of what i plan to do, but I'm still working out the > details of how to proceed. I'm hoping for some feedback on what I intend to > do and possibly some alternate ideas if anyone has some. > > Thanks! > > > [1] https://issues.apache.org/jira/browse/GERONIMO-4335 > > -- > ~Jason Warner > > > -- ~Jason Warner
An idea for defining custom valves in config.xml
Hey all. I'm working on an idea for allowing custom valves to be defined in config.xml. Currently this isn't possible since the tomcat classloader would not contain the custom classes for the valve. I've create a jira for tracking this issue [1] and it contains a few links to workarounds. IMHO, The solution we should be looking for is a way to add classes to a module without having to undeploy, modify the module config, and redeploying. I think this can be done by allowing a user to indicate jars that should be loaded by a module within the config.xml. These jars can then be added to the module's classloader for use by the module. I'm not extremely familiar with how our classloader works, but I've taken a look through the code and I think the ability to add to the classloader can be implemented without too much difficulty. I'm not quite sure what type of scope to give this change, though. Should I leave it as a change aimed solely at tomcat valves or should it be expanded to encompass any configuration? I realize this is only a rough idea of what i plan to do, but I'm still working out the details of how to proceed. I'm hoping for some feedback on what I intend to do and possibly some alternate ideas if anyone has some. Thanks! [1] https://issues.apache.org/jira/browse/GERONIMO-4335 -- ~Jason Warner
[jira] Updated: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4335: --- Description: There currently is no good way to define a custom valve in config.xml. There are a couple of work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 was: There currently is no good way to define a custom valve in config.xml. There a couple work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 > Implement the ability to define a custom valve in config.xml > > > Key: GERONIMO-4335 > URL: https://issues.apache.org/jira/browse/GERONIMO-4335 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.3, 2.2 > Reporter: Jason Warner >Assignee: Jason Warner > > There currently is no good way to define a custom valve in config.xml. There > are a couple of work arounds [1][2] that will result in the desired > functionality, but i believe there should be a simpler and more intuitive way > to accomplish this goal. > [1] https://issues.apache.org/jira/browse/GERONIMO-4113 > [2] > http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
Implement the ability to define a custom valve in config.xml Key: GERONIMO-4335 URL: https://issues.apache.org/jira/browse/GERONIMO-4335 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner There currently is no good way to define a custom valve in config.xml. There a couple work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Packaging error when building trunk
I'm seeing an error pop up when the server assemblies are being packaged during a trunk build. The error is "[ERROR] Installed 'org.apache.geronimo.configs/axis-deployer/2.2-SNAPSHOT/car' configuration into repository but cannot locate file to copy schema/schemaorg_apache_xmlbeans/src/" This doesn't seem to really effect the server running as far as I've seen but when I attempt to build the daytrader trunk I get a stacktrace [1] that seems like it might be related. Anybody have any thoughts on what's causing this error? Thanks! [1] [ERROR] Deployment failed due to java.lang.NullPointerException org.apache.xmlbeans.impl.schema.SchemaPropertyImpl.getType(SchemaPropertyImpl.java:92) org.apache.xmlbeans.impl.schema.SchemaTypeImpl.createElementType(SchemaTypeImpl.java:965) org.apache.xmlbeans.impl.values.XmlObjectBase.create_element_user(XmlObjectBase.java:893) org.apache.xmlbeans.impl.store.Xobj.getUser(Xobj.java:1657) org.apache.xmlbeans.impl.store.Xobj.find_element_user(Xobj.java:2062) org.apache.geronimo.xbeans.geronimo.client.impl.GerResourceTypeImpl.getConnector(Unknown Source) org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:371) org.apache.geronimo.client.builder.AppClientModuleBuilder.createModule(AppClientModuleBuilder.java:235) org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:807) org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:402) org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:295) org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:227) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850) org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483) org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309) org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:209) org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) org.apache.maven.cli.MavenCli.main(MavenCli.java:287) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) org.codehaus.classworlds.Launcher.launch(Launcher.java:255) org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- ~Jason Warner
Re: Continuous TCK Testing
Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. On Wed, Oct 1, 2008 at 9:56 AM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > Not seeing too much progress here. Has anyone dug up the Anthill-based > code? I'll have a look. > > --kevan > -- ~Jason Warner
Re: [VOTE] Release Geronimo Samples 2.1.2
+1 Installed all sample apps on Tomcat and clicked through On Wed, Oct 1, 2008 at 10:54 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Friendly reminder to cast your vote. We're halfway through the vote now. > > Joe > > > > Joe Bohn wrote: > >> All, >> >> I've prepared a release candidate of Geronimo Samples 2.1.2 for your >> review and vote. >> >> This is the first independent release of samples for Geronimo. All >> together, there are 86 deliverables included in the staging repository. >> There are many documentation updates necessary which can continue >> concurrent with (and subsequent to) the vote. The sample wiki documentation >> is located here: >> http://cwiki.apache.org/GMOxDOC21/sample-applications.html >> >> I'll say up-front that the samples are still far from perfect. However, I >> think they are all functional with a few warts. IMO we need to get these >> released. >> >> The samples can be installed on either a Geronimo 2.1.2 or Geronimo 2.1.3 >> server image. They should also work on 2.1.4-SNAPSHOT but I personally have >> not verified using the latest snapshot and that is not a target server. All >> of the samples are available for installation as plugins and I have created >> a temporary plugin catalog for your convenience (see directions below). >> >> Staging repo: >> http://people.apache.org/~jbohn/staging-repo/geronimo-samples/<http://people.apache.org/%7Ejbohn/staging-repo/geronimo-samples/> >> >> Staging site: >> http://people.apache.org/~jbohn/staging-site/geronimo-samples/2.1.2/<http://people.apache.org/%7Ejbohn/staging-site/geronimo-samples/2.1.2/> >> >> The svn location is here: >> >> https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1.2 >> >> Repository for plugin install (same as staging repo): >> http://people.apache.org/~jbohn/staging-repo/geronimo-samples/<http://people.apache.org/%7Ejbohn/staging-repo/geronimo-samples/> >> - From the console navigation to Plugins >> - select Add Repository >> - paste in my staging repo listed above: >> - click Add >> - Select the newly added repository from the drop down list >> - click "Show Plugins in selected repository" >> - You should see the samples plugins listed. >> >> >> When the release vote is approved, the maven artifacts will be moved >> to the m2-ibiblio-rsync-repository at Apache and the maven site will be >> published. >> >> The vote is open for 72 hours and will conclude on 10/02/2008 at 11:00 PM >> ET. >> >> [ ] +1 Release Geronimo Samples 2.1.2 >> [ ] 0 No opinion >> [ ] -1 Do not release Geronimo Samples 2.1.2 (please provide rationale) >> >> Joe >> >> > -- ~Jason Warner
[jira] Closed: (GERONIMO-3468) Links broken through Ajp13.
[ https://issues.apache.org/jira/browse/GERONIMO-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-3468. -- Resolution: Fixed Fix Version/s: 2.0.2 Assignee: Jason Warner (was: Joseph Leong) This seems to have been fixed in 2.0.2 > Links broken through Ajp13. > --- > > Key: GERONIMO-3468 > URL: https://issues.apache.org/jira/browse/GERONIMO-3468 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.0.1 > Environment: Linux 2.6.21-gentoo-r4 #1 SMP Wed Jul 25 22:03:40 EDT > 2007 i686 Pentium III (Katmai) GenuineIntel GNU/Linux > apache-2.2.6 > mod_jk-1.2.23 > sun-jdk-1.5.0.12 >Reporter: Aleksandr Tarutin >Assignee: Jason Warner > Fix For: 2.0.2 > > > When running behind apache through the Ajp13 connector the 'edit' and 'usage' > links on the 'Database Pools' page in the console don't work and just return > to the 'Database Pools' page. This happens in Geronimo with Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager
[ https://issues.apache.org/jira/browse/GSHELL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GSHELL-54. -- Resolution: Won't Fix Layout has been removed. This jira no longer seems applicable > Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve > as expected in the layout manager > - > > Key: GSHELL-54 > URL: https://issues.apache.org/jira/browse/GSHELL-54 > Project: GShell > Issue Type: Bug > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.0-alpha-1 >Reporter: Jason Dillon >Assignee: Jason Warner > Fix For: 1.0-alpha-2 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-58) Layout command aliases should be allowed to reference relative command paths for targets
[
https://issues.apache.org/jira/browse/GSHELL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner closed GSHELL-58.
--
Resolution: Won't Fix
Layout has been removed. This issue is no longer applicable
> Layout command aliases should be allowed to reference relative command paths
> for targets
>
>
> Key: GSHELL-58
> URL: https://issues.apache.org/jira/browse/GSHELL-58
> Project: GShell
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.0-alpha-1
>Reporter: Jason Dillon
>Assignee: Jason Warner
> Fix For: 1.0-alpha-2
>
>
> For example:
> {code}
> ...
>
> remote
>
>
> rsh
> gshell-remote:rsh
>
>
> rsh-server
> gshell-remote:rsh-server
>
>
> rshd
> rsh-server
>
>
>
>
>
> {code}
> In this example, the {{remote/rshd}} command alias really wants to point to
> {{remote/rsh-server}} but current alias target resolve works from the layout
> root.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
I am all for this idea. I don't really know about anthill but I did look into hudson a little bit a while ago. It seems like it would meet our requirements but I haven't actually used the technology so I'm not sure how well it works. If we already have a solution, I'm not sure why we wouldn't go with that, though. Is there any reason we wouldn't want to use a setup similar to what we had before using anthill? I'd be happy to get involved, especially if it makes it easier to verify tck when release time comes around. I'm kind of curious about how this would work, though. I assume someone would commit some code and this would trigger a tck test with the new code. How would errors be reported? Would we have to have all committers sign the NDA so we can report details of failures to whoever committed the changes? On Thu, Sep 18, 2008 at 1:50 PM, Kevan Miller <[EMAIL PROTECTED]>wrote: > As many of you know, we have two apache.org machines for TCK testing of > Geronimo (phoebe and selene). We used the machines for certification of our > 2.1.3 release. However, this testing was run manually. It's time to get > continuous, automatic TCK testing running on these machines. > > We had the basic setup running on GBuild machines. IIRC, this was built > around AntHill -- Jason Dillon knows it best. There are other testing > systems available (e.g. Hudson) which could be used for this task. > > What do others think? What underlying technology should we use? Who wants > to get involved? > > I think this discussion should be on our dev@ mailing list. TCK should be > for test specific discussions. > > --kevan > > -- ~Jason Warner
Re: [DISCUSS] Release Geronimo Server 2.1.3 RC1
The TCK tests are running. I'll let you know when they pass. On Thu, Sep 11, 2008 at 11:59 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > Joe pointed out one of the distribution links in the email was wrong > (included Tomcat minimal instead of the JEE5 zip url) so here are the > updated links - > > For your convenience, here are pointers to the JEE5 distributions: > > http://people.apache.org/~dwoods/releases/geronimo-2.1.3-RC1/geronimo-jetty6-javaee5-2.1.3-bin.tar.gz<http://people.apache.org/%7Edwoods/releases/geronimo-2.1.3-RC1/geronimo-jetty6-javaee5-2.1.3-bin.tar.gz> > > http://people.apache.org/~dwoods/releases/geronimo-2.1.3-RC1/geronimo-jetty6-javaee5-2.1.3-bin.zip<http://people.apache.org/%7Edwoods/releases/geronimo-2.1.3-RC1/geronimo-jetty6-javaee5-2.1.3-bin.zip> > > http://people.apache.org/~dwoods/releases/geronimo-2.1.3-RC1/geronimo-tomcat6-javaee5-2.1.3-bin.tar.gz<http://people.apache.org/%7Edwoods/releases/geronimo-2.1.3-RC1/geronimo-tomcat6-javaee5-2.1.3-bin.tar.gz> > > http://people.apache.org/~dwoods/releases/geronimo-2.1.3-RC1/geronimo-tomcat6-javaee5-2.1.3-bin.zip<http://people.apache.org/%7Edwoods/releases/geronimo-2.1.3-RC1/geronimo-tomcat6-javaee5-2.1.3-bin.zip> > > > No need to respin the vote, as nothing was changed on the staging site. > > > -Donald > > > > Donald Woods wrote: > >> Discussion thread for Geronimo Server 2.1.3 RC1 release thread - >> http://www.nabble.com/-DISCUSS--Geronimo-2.1.3-release-tt19186703s134.html >> >> >> >> -Donald >> >> -- ~Jason Warner
Re: [DISCUSS] Geronimo 2.1.3 release
Hi Donald, Looks like all the big ones that popped up have been dealt with. I'll run the RC through whenever it's ready. Thanks! On Tue, Sep 9, 2008 at 10:38 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > We rolled back to OpenJPA 1.0.3 yesterday, due to TCK failures with the > newer 1.2.0 release. As soon as Jason W. verifies that most of the problems > he was seeing are gone, I'll publish a RC1 for everyone to start looking at. > > > -Donald > > > > Donald Woods wrote: > >> Time to start the discussion on winding down changes and preparing for a >> Geronimo 2.1.3 release. >> >> Server fixes/enhancements are listed on the Release Status page - >> http://cwiki.apache.org/GMOxPMGT/geronimo-213-release-status.html >> >> Details on included security fixes in dependent components are listed on >> the Security page - >> http://geronimo.apache.org/21x-security-report.html >> >> >> The only additional changes that I know of right now for 2.1.3 are Joe's >> "compatibility plugins/artifact alias" changes. >> >> >> Does anyone have additional fixes they would like to include in 2.1.3 >> before we cut the branch and start the release process? >> >> >> >> -Donald >> > -- ~Jason Warner
Re: [ANNOUNCE] Welcome BJ Reed as a new Geronimo Committer
Congrats! On Tue, Sep 9, 2008 at 1:56 AM, Ashish Jain <[EMAIL PROTECTED]> wrote: > Congrats BJ!! > > > On Tue, Sep 9, 2008 at 11:14 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote: > >> Congrats! >> >> Jarek >> >> On Mon, Sep 8, 2008 at 5:11 PM, Tim McConnell <[EMAIL PROTECTED]> >> wrote: >> > Hi Everyone, The Geronimo PMC is pleased to announce that BJ Reed has >> > recently accepted our invitation to become an Apache Geronimo committer. >> BJ >> > has contributed a number of significant enhancements and fixes to our >> > Eclipse Plugin. >> > >> > BJ, keep up all the great work on the GEP and welcome aboard !! >> > >> > -- >> > Thanks, >> > Tim McConnell >> > >> > >> > > -- ~Jason Warner
Re: [jira] Closed: (GERONIMO-4278) Upgrade to OpenJPA 1.2.0
This change may be causing an issue with the 2.1.3 tck. I'm currently working on verifying the issue. On Wed, Sep 3, 2008 at 2:21 PM, Donald Woods (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/GERONIMO-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Donald Woods closed GERONIMO-4278. > -- > > Resolution: Fixed >Fix Version/s: 2.1.3 > > changes applied and build/testsuite passed on 2.1.4-SNAPSHOT > > > Upgrade to OpenJPA 1.2.0 > > > > > > Key: GERONIMO-4278 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4278 > > Project: Geronimo > > Issue Type: Improvement > > Security Level: public(Regular issues) > > Components: dependencies > >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, > 2.1.4, 2.2 > >Reporter: Donald Woods > >Assignee: Donald Woods > > Fix For: 2.0.3, 2.1.3, 2.1.4, 2.2 > > > > > > Upgrade to OpenJPA 1.2.0 release on 20080815 to resolve reported issue in > GERONIMO-4275. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- ~Jason Warner
Re: Fwd: Geronimo 2.1&2.2 Documentation
Hi Rhoda, Will you be moving the content into the new structure as well? Thanks! On Thu, Sep 4, 2008 at 9:28 PM, Rhoda Zheng <[EMAIL PROTECTED]> wrote: > Hi Joe, > > Yes, it works now. The new structure for 2.2 is successfully updated in the > space. Thank you. > > Rhoda > > > 2008/9/4 Joe Bohn <[EMAIL PROTECTED]> > > You should have all of the authorization you need with >> geronimo-contributors. It contains everything from geronimo-users plus >> some. If you haven't already done so, you should signoff and back on again >> to pick up the new authorization. >> >> I think we need to remove the geronimo-users group - Does anybody know the >> purpose of this group anyway? >> >> Joe >> >> >> Rhoda Zheng wrote: >> >>> Hi Joe, >>> >>> Please help grant "geronimo-users" to "Rhoda Zheng" as well. It seems >>> that I can't edit ***Apache Geronimo v2.2* < >>> http://cwiki.apache.org/GMOxDOC22/documentation.html>** docs. Thanks a >>> lot. >>> >>> Rhoda >>> >>> >>> 2008/9/3 Joe Bohn <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >>> >> >>> >>> >>>After finally finding your userid I did add you to the >>>geronimo-contributors group. >>> >>>Thanks for helping out with the doc. >>>Joe >>> >>>Rhoda Zheng wrote: >>> >>>Hi Joe, >>> >>>My ICLA is on file now. You can find "Wenjing Zheng" in the list >>>of ASF Committers. Could you please grant me contributor access >>>to the wiki? Thank you very much. >>> >>>Rhoda >>> >>> >>>-- Forwarded message -- >>>From: *Rhoda Zheng* <[EMAIL PROTECTED] >>><mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >>><mailto:[EMAIL PROTECTED]>>> >>>Date: 2008/8/29 >>>Subject: Re: Geronimo 2.1&2.2 Documentation >>>To: dev@geronimo.apache.org <mailto:dev@geronimo.apache.org> >>><mailto:dev@geronimo.apache.org <mailto:dev@geronimo.apache.org>> >>> >>> >>>Hi Bill, hi Joe, >>> >>>My ICLA is on file now. Thank you very much. >>> >>>Rhoda >>> >>> >>>2008/8/29 bill stoddard <[EMAIL PROTECTED] >>><mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] >>> >>><mailto:[EMAIL PROTECTED]>>> >>> >>> >>> Joe Bohn wrote: >>> >>> Hi Rhonda, >>> >>> We're glad that you would like to help with the >>>documentation. >>> Before you can be given contributor access you must first >>>file >>> an ICLA (Individual Contributor License Agreement) with the >>> Apache Software Foundation. I just checked and I don't see >>> a >>> record of an ICLA on file for you yet. Please let us >>>know when >>> it is filed and once verified we can grant you contributor >>> access to the wiki. >>> >>> You can find the form and information on how to submit it >>> at >>> this URL: >>> http://www.apache.org/licenses/ >>> >>> Hi Rhoda, >>> Here is the link to the ICLA pdf: >>> http://www.apache.org/licenses/icla.pdf >>> >>> You can submit the form electronically by printing, filling >>> out, >>> signing, then scanning it. Send the scanned and signed form >>> to: >>> >>> secretary at apache dot org >>> legal-archive at apache dot org >>> >>> It will probably take about a week (maybe a bit more due to the >>> upcoming labor day holiday) for the ICLA to be recorded by the >>> secretary. >>> >>> Bill >>> >>> >>> >>> >>> >>> >> > -- ~Jason Warner
Re: [VOTE] Release javamail spec (1.5) and javamail provider (1.6)
+1 Tck looks alright. On Fri, Aug 29, 2008 at 9:17 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > +1 > > > -Donald > > > Joe Bohn wrote: > >> This is a vote for a combined release of javamail spec and the javamail >> provider (+ the uber jar). The provider changes have depedencies on the >> spec changes, so these need to be released at the same time. Geronimo will >> need the updated uber jar for the 2.1.3 release. >> >> The components up for release are >> >> geronimo-javamail_1.4_spec-1.5 >> geronimo-javamail_1.4-1.6 >> geronimo-javamail_1.4_provider-1.6 >> geronimo-javamail_1.4_mail-1.6(uber jar containing spec+providers) >> >> >> Staging repos: >> >> http://people.apache.org/~jbohn/staging-repo/specs/geronimo-javamail_1.4_spec/<http://people.apache.org/%7Ejbohn/staging-repo/specs/geronimo-javamail_1.4_spec/> >> http://people.apache.org/~jbohn/staging-repo/javamail/<http://people.apache.org/%7Ejbohn/staging-repo/javamail/> >> >> The svn locations are here: >> >> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.4_spec-1.5 >> >> https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.4-1.6 >> >> >> The vote is open for 72 hours and will conclude on Sunday (8/31) at 11:00 >> PM ET. >> >> [ ] +1 Release the javamail spec and provider >> [ ] +0 No opinion >> [ ] -1 Don't release the javamail spec and provider >> >> >> Joe >> >> -- ~Jason Warner
[jira] Closed: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4264. -- > Enable static configuration of a wadi cluster > - > > Key: GERONIMO-4264 > URL: https://issues.apache.org/jira/browse/GERONIMO-4264 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner > Fix For: 2.2 > > > Wadi has the capability to be statically configured, and this feature needs > to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-4264. Resolution: Fixed Fix Version/s: 2.2 committed in revision 689137 > Enable static configuration of a wadi cluster > - > > Key: GERONIMO-4264 > URL: https://issues.apache.org/jira/browse/GERONIMO-4264 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner > Fix For: 2.2 > > > Wadi has the capability to be statically configured, and this feature needs > to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4264) Enable static configuration of a wadi cluster
Enable static configuration of a wadi cluster - Key: GERONIMO-4264 URL: https://issues.apache.org/jira/browse/GERONIMO-4264 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Wadi has the capability to be statically configured, and this feature needs to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4264: --- Fix Version/s: (was: 2.2) > Enable static configuration of a wadi cluster > - > > Key: GERONIMO-4264 > URL: https://issues.apache.org/jira/browse/GERONIMO-4264 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner > > Wadi has the capability to be statically configured, and this feature needs > to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: apache httpd and geronimo -- newbie
Hello, This is very much possible. I'm not sure what version you're using, so here's some instructions to get you started with 2.1 ( http://cwiki.apache.org/GMOxDOC21/configuring-a-remote-apache-http-server.html). I'd suggest using mod_proxy for a simple solution. It's simpler to setup and use, but doesn't provide the fine-tuning ability you get when using mod_jk. Please let us know if you have any questions or issues. Thanks! On Mon, Aug 18, 2008 at 10:58 AM, whitewaterbug <[EMAIL PROTECTED]> wrote: > > Is it possible to have apache HTTPd run as the web server and geronimo run > as > the application server? > -- > View this message in context: > http://www.nabble.com/apache-httpd-and-geronimonewbie-tp19033486s134p19033486.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > > -- ~Jason Warner
[jira] Updated: (GERONIMO-4244) Update to latest wadi 2.1-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4244: --- Summary: Update to latest wadi 2.1-SNAPSHOT (was: Update to latest wadi 2.0-SNAPSHOT) updating to correct snapshot, committed in revision 686113 > Update to latest wadi 2.1-SNAPSHOT > -- > > Key: GERONIMO-4244 > URL: https://issues.apache.org/jira/browse/GERONIMO-4244 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner >Priority: Minor > Fix For: 2.2 > > > Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r686040 - /geronimo/server/trunk/pom.xml
I'll make the necessary change then. Thanks On Thu, Aug 14, 2008 at 7:40 PM, Gianny Damour < [EMAIL PROTECTED]> wrote: > My bad, I was so used to release milestone releases that when I published > 2.0 I simply forgot to move the snapshot version of WADI to 2.1. > > I am publishing 2.1-SNAPSHOT right now. > > Thanks, > Gianny > > > On 15/08/2008, at 7:34 AM, Jacek Laskowski wrote: > > On Thu, Aug 14, 2008 at 10:54 PM, <[EMAIL PROTECTED]> wrote: >> >>> Author: jawarner >>> Date: Thu Aug 14 13:54:03 2008 >>> New Revision: 686040 >>> >>> URL: http://svn.apache.org/viewvc?rev=686040&view=rev >>> Log: >>> GERONIMO-4244: Update to new wadi snapshot >>> >>> Modified: >>> geronimo/server/trunk/pom.xml >>> >>> Modified: geronimo/server/trunk/pom.xml >>> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml >>> ?rev=686040&r1=686039&r2=686040&view=diff >>> >>> == >>> --- geronimo/server/trunk/pom.xml (original) >>> +++ geronimo/server/trunk/pom.xml Thu Aug 14 13:54:03 2008 >>> @@ -82,7 +82,7 @@ >>>1.1.6-G643117 >>> 1.0.2 >>>3.4.1 >>> -2.0 >>> +2.0-SNAPSHOT >>> >> >> How can 2.0-SNAPSHOT be newer than 2.0? I'm a bit confused. >> >> Jacek >> >> -- >> Jacek Laskowski >> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl >> > > -- ~Jason Warner
[jira] Closed: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4244. -- Resolution: Fixed Fix Version/s: 2.2 committed in revision 686040 > Update to latest wadi 2.0-SNAPSHOT > -- > > Key: GERONIMO-4244 > URL: https://issues.apache.org/jira/browse/GERONIMO-4244 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.2 > Reporter: Jason Warner >Assignee: Jason Warner >Priority: Minor > Fix For: 2.2 > > > Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT
Update to latest wadi 2.0-SNAPSHOT -- Key: GERONIMO-4244 URL: https://issues.apache.org/jira/browse/GERONIMO-4244 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation of new 2.2 features in current wiki?
g for disaster. > >>>> > >>>> I'd like to suggest that feature documentation should generally start > >>>> with a > >>>> "starting with version xxx" comment. So, I'd put the openid/jaspi > >>>> documentation in the current (2.1) wiki with a "starting with 2.2" > >>>> notice. > >>>> Obviously there's the problem that the wiki has the 2.1 version in > its > >>>> name. I don't know if a wiki can have its name changed but don't > regard > >>>> this > >>>> as critical. > >>>> > >>>> I'm going to start doing this pending comments and better ideas. At > the > >>>> rate I write I don't think I'll be causing significant damage before > we > >>>> have > >>>> time for a full discussion :-) > >>>> > >>>> thanks > >>>> david jencks > >>>> > >>>> > >>> > > > > > -- ~Jason Warner
Re: Reducing the dojo footprint in Geronimo
is that the AJAX library can't be upgraded or otherwise managed >>independently from the web applications that contain it. For >>example, a web application deployed across a cluster might need to >>serve up the static Dojo files from a central location. Hosting the >>Dojo files in a separate webapp can help work around these problems." >> >>So asking users to package the Dojo level and features they need >>within their own apps would imply the downsides mentioned above. >>Providing an installable dojo plugin that's equivalent to the /dojo >>support we currently provide as suggested by Kevan seems to be an >>excellent alternative. >> >>-Donald >> >> >> >>Kevan Miller wrote: >> >> >>On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote: >> >> >>As for the including the rest of DojoX, since it a >>significant part of the reducing effort. Would it make >>sense to build a custom js for monitoring, remove the >>rest of DojoX and if the development starts shifting to >>a real need for DojoX to make a decision to bring it >>back in the future? >> >>I think that makes perfect sense- not only will this do >>the part in reducing the dojo footprint, it'll also be >>useful as an example to how dojo should be used >>optimally in deployment. Another desirable side-effect >>would be reduced load times in the monitoring >>application, although currently that is not an issue. >> >> >>I'm starting to think that our server should deliver dojo >>support that is targeted to the requirements of the admin >>console. >> >>For general dojo support, we could provide an installable >>dojo plugin that's equivalent to the /dojo support we >>currently provide... >> >>--kevan >> >> >> >> >>--Thanks, >>Shiva >> >> -- ~Jason Warner
[jira] Closed: (GERONIMO-4220) Tomcat Cluster Sender gbean should allow Transport element
[ https://issues.apache.org/jira/browse/GERONIMO-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4220. -- Resolution: Fixed Fix Version/s: 2.2 committed in trunk (rev. 682729) > Tomcat Cluster Sender gbean should allow Transport element > -- > > Key: GERONIMO-4220 > URL: https://issues.apache.org/jira/browse/GERONIMO-4220 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.1.3, 2.2 > Reporter: Jason Warner >Assignee: Jason Warner >Priority: Minor > Fix For: 2.2 > > > In tomcat, the sender element can have a transport subelement that allows for > more configuration options. The geronimo implementation of this clustering > should be expanded to allow for the same options. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Geronimo Server 2.1.2 Release
Joe's set me straight. Everything is still valid. Thanks, On Mon, Aug 4, 2008 at 3:05 PM, Jason Warner <[EMAIL PROTECTED]> wrote: > There might have been an issue with the tck tests I ran. I'll need to > discuss with Joe, but I suggest not closing the vote until the tests are > verified as valid. > > > On Mon, Aug 4, 2008 at 2:57 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: > >> +1 >> >> Ted Kirby >> >> On Wed, Jul 30, 2008 at 10:52 PM, Joe Bohn <[EMAIL PROTECTED]> >> wrote: >> > All, >> > >> > I've prepared a release candidate of Geronimo Server 2.1.2 for your >> > review and vote. >> > >> > The source for the Geronimo Server 2.1.2 release currently resides here: >> > https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 >> > >> > When the release vote is approved, I will svn mv the code to >> > https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2 >> > >> > An archive of this source code can be found here: >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz> >> > OR >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip> >> > >> > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/>contains >> > the 10 Java >> > EE, Minimal, and Framework server binary distributions to be >> > released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as >> > the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code >> > archives for the release. These extra txt files were included so that >> they >> > could be leveraged by GEP if necessary (they are also included in the >> > assembly images). >> > >> > For your convenience, here are pointers to the urls for the >> > distributions in zip format: >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip> >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip> >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip> >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip> >> > >> http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip> >> > >> > The maven artifacts for the release can be found here: >> > http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.2/<http://people.apache.org/%7Ejbohn/staging-repo/geronimo-2.1.2/> >> > >> > When the release vote is approved, these maven artifacts will be moved >> > to the m2-ibiblio-rsync-repository at Apache. >> > >> > >> > [ ] +1 Release Geronimo 2.1.2 >> > [ ] 0 No opinion >> > [ ] -1 Do not release Geronimo 2.1.2 (please provide rationale) >> > >> > 72 hours would expire at 11:00PM ET on Saturday evening, 8/2. However, >> the >> > vote may go longer while the tck results are verified. >> > >> > >> > Joe Bohn >> > >> > >> > > > > -- > ~Jason Warner > -- ~Jason Warner
Re: [VOTE] Geronimo Server 2.1.2 Release
There might have been an issue with the tck tests I ran. I'll need to discuss with Joe, but I suggest not closing the vote until the tests are verified as valid. On Mon, Aug 4, 2008 at 2:57 PM, Ted Kirby <[EMAIL PROTECTED]> wrote: > +1 > > Ted Kirby > > On Wed, Jul 30, 2008 at 10:52 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > > All, > > > > I've prepared a release candidate of Geronimo Server 2.1.2 for your > > review and vote. > > > > The source for the Geronimo Server 2.1.2 release currently resides here: > > https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 > > > > When the release vote is approved, I will svn mv the code to > > https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2 > > > > An archive of this source code can be found here: > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz> > > OR > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip> > > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/>contains > > the 10 Java > > EE, Minimal, and Framework server binary distributions to be > > released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as > > the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code > > archives for the release. These extra txt files were included so that > they > > could be leveraged by GEP if necessary (they are also included in the > > assembly images). > > > > For your convenience, here are pointers to the urls for the > > distributions in zip format: > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip> > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip> > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip> > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip> > > > http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip<http://people.apache.org/%7Ejbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip> > > > > The maven artifacts for the release can be found here: > > http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.2/<http://people.apache.org/%7Ejbohn/staging-repo/geronimo-2.1.2/> > > > > When the release vote is approved, these maven artifacts will be moved > > to the m2-ibiblio-rsync-repository at Apache. > > > > > > [ ] +1 Release Geronimo 2.1.2 > > [ ] 0 No opinion > > [ ] -1 Do not release Geronimo 2.1.2 (please provide rationale) > > > > 72 hours would expire at 11:00PM ET on Saturday evening, 8/2. However, > the > > vote may go longer while the tck results are verified. > > > > > > Joe Bohn > > > > > -- ~Jason Warner
