Re: Discuss: Move Geronimo to Attic

[Jason Warner]

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 

Re: Welcome Chi Run Hua as a new Geronimo committer

[Jason Warner]

Congrats!

~Jason Warner



On Fri, May 20, 2011 at 10:25 PM, Shawn Jiang genspr...@gmail.com wrote:
 Congrats, Chi Run Hua !

 On Fri, May 20, 2011 at 11:32 PM, Ivan xhh...@gmail.com 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

[Jason Warner]

Congrats indeed.

~Jason Warner


On Sun, May 2, 2010 at 9:28 AM, Kevan Miller kevan.mil...@gmail.com 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

[Jason Warner]

Congrats, Ashish!

~Jason Warner


On Sun, Mar 14, 2010 at 4:44 PM, Joe Bohn joe.b...@earthlink.net 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

[Jason Warner]

Congrats!

~Jason Warner


On Thu, Mar 11, 2010 at 3:04 PM, Jay D. McHugh jaydmch...@gmail.com 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

[Jason Warner]

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 dwo...@apache.org 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 ianr...@googlemail.com
 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)

[Jason Warner]

+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 rick...@gmail.com 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=10220styleName=Htmlversion=12312965
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220styleName=Htmlversion=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

[Jason Warner]

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 dwo...@apache.org 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:\g22man -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.role#roleHint}
 [WARNING]   is deprecated, please use
 [WARNING] @component role=role roleHint=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 mailto:
 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

[Jason Warner]

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 dwo...@apache.org 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 mailto:
 dwo...@apache.org wrote:

Author: dwoods
Date: Fri Oct  9 13:17:20 2009
New Revision: 823543

URL: http://svn.apache.org/viewvc?rev=823543view=rev
http://svn.apache.org/viewvc?rev=823543view=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=823543r1=823542r2=823543view=diff

 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-jetty/src/main/history/dependencies.xml?rev=823543r1=823542r2=823543view=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 @@
artifactIdxmlpull/artifactId
typejar/type
/dependency
+dependency
+groupIdjivesoftware/groupId
+artifactIdsmack/artifactId
+typejar/type
+/dependency
 /plugin-artifact

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=823543r1=823542r2=823543view=diff

 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/activemq-webconsole-tomcat/src/main/history/dependencies.xml?rev=823543r1=823542r2=823543view=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 @@
artifactIdxmlpull/artifactId
typejar/type
/dependency
+dependency
+groupIdjivesoftware/groupId
+artifactIdsmack/artifactId
+typejar/type
+/dependency
 /plugin-artifact

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

[Jason Warner]

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=823543view=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=823543r1=823542r2=823543view=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 @@
 artifactIdxmlpull/artifactId
 typejar/type
 /dependency
 +dependency
 +groupIdjivesoftware/groupId
 +artifactIdsmack/artifactId
 +typejar/type
 +/dependency
  /plugin-artifact

 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=823543r1=823542r2=823543view=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 @@
 artifactIdxmlpull/artifactId
 typejar/type
 /dependency
 +dependency
 +groupIdjivesoftware/groupId
 +artifactIdsmack/artifactId
 +typejar/type
 +/dependency
  /plugin-artifact

Upgrade to activemq-protobuf version 1.0?

[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

Re: Upgrade to activemq-protobuf version 1.0?

[Jason Warner]

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 xhh...@gmail.com 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 jaw...@gmail.com

 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

Geronimo branches/2.2 build failure

[Jason Warner]

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

[Jason Warner]

Congratulations!

~Jason Warner


On Mon, Aug 31, 2009 at 6:48 PM, David Jencks david_jen...@yahoo.comwrote:

 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

[Jason Warner]

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?

[Jason Warner]

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 yingtang1...@gmail.com 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 dwo...@apache.org:
  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 yingtang1...@gmail.com
  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 dwo...@apache.org 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 chirun...@gmail.com
  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
 david_jen...@yahoo.com 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

[Jason Warner]

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 david_jen...@yahoo.comwrote:

 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

[Jason Warner]

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 dait...@gmail.com 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

Adding a repository to the server trunk build

[Jason Warner]

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: Adding a repository to the server trunk build

[Jason Warner]

Ah, I see.  Thanks for the info.  I'll commit that change, then.

On Fri, Apr 17, 2009 at 12:13 PM, Donald Woods dwo...@apache.org 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

Re: [VOTE] Release Geronimo Server 2.1.4 RC2

[Jason Warner]

+1  TCK passed.

On Fri, Mar 27, 2009 at 8:11 PM, Tim McConnell tim.mcco...@gmail.comwrote:

 +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.gzhttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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

[Jason Warner]

Congratulations!

On Fri, Mar 6, 2009 at 12:24 PM, Joe Bohn joe.b...@earthlink.net 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

[Jason Warner]

)
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

[Jason Warner (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
  Interceptor 
 className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
   port=5678
   securePort=-1
   host=tomcat01.mydomain.com
   domain=staging-cluster
   uniqueId={0,1,2,3,4,5,6,7,8,9}/
  /Interceptor
 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 Member 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

[Jason Warner]

+1

On Tue, Feb 17, 2009 at 11:45 AM, Joe Bohn joe.b...@earthlink.net 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-alpha2http://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

[Jason Warner (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
  Interceptor 
 className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
   port=5678
   securePort=-1
   host=tomcat01.mydomain.com
   domain=staging-cluster
   uniqueId={0,1,2,3,4,5,6,7,8,9}/
  /Interceptor
 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 Member 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

[Jason Warner (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
  Interceptor 
 className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
   port=5678
   securePort=-1
   host=tomcat01.mydomain.com
   domain=staging-cluster
   uniqueId={0,1,2,3,4,5,6,7,8,9}/
  /Interceptor
 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 Member 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

[Jason Warner]

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 j...@trifork.com 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

[Jason Warner]

You're not alone

On Tue, Jan 13, 2009 at 3:39 PM, Tim McConnell tim.mcco...@gmail.comwrote:

 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

[Jason Warner]

Thanks for the tip!

On Thu, Jan 8, 2009 at 8:43 PM, Jason Dillon ja...@planet57.com 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=732905view=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=732905r1=732904r2=732905view=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/

[Jason Warner]

 -table width=100%
 +br/
 +
 +bfmt:message key=consolebase.common.user/:/b
 +table width=100% class=TableLine summary=User
   tr
 -td class=DarkBackground width=100% colspan=2
 align=centerfmt:message key=apache.javaSysNormal.usr//td
 +th scope=col class=DarkBackground width=20%
 align=centerfmt:message key=consolebase.common.item//th
 +th scope=col class=DarkBackground width=80%
 align=centerfmt:message key=consolebase.common.value//th
   /tr
   tr
 td class=LightBackground width=20% nowrapuser.country/td
 @@ -265,10 +279,13 @@
 td class=LightBackground${javaSysProps['user.variant']}/td
   /tr
  /table
 -br
 -table width=100%
 +br/
 +
 +bfmt:message key=consolebase.common.etc/:/b
 +table width=100% class=TableLine summary=Etc
   tr
 -td class=DarkBackground width=100% colspan=2
 align=centerfmt:message key=apache.javaSysNormal.etc//td
 +th scope=col class=DarkBackground width=20%
 align=centerfmt:message key=consolebase.common.item//th
 +th scope=col class=DarkBackground width=80%
 align=centerfmt:message key=consolebase.common.value//th
   /tr
  % 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=732011r1=732010r2=732011view=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 @@
  script type='text/javascript' src='/console/dwr/engine.js'/script
  script type='text/javascript' src='/console/dwr/util.js'/script

 -table width=100%
 +bfmt:message key=infomanager.svrInfoNormal.server/:/b
 +table width=100% class=TableLine summary=Server
   tr
 -td class=DarkBackground width=100% colspan=2
 align=centerfmt:message key=infomanager.svrInfoNormal.server//td
 +th scope=col class=DarkBackground width=20%
 align=centerfmt:message key=consolebase.common.item//th
 +th scope=col class=DarkBackground width=80%
 align=centerfmt:message key=consolebase.common.value//th
   /tr
   tr
 td class=LightBackground width=20% nowrapfmt:message
 key=infomanager.svrInfoNormal.version//td
 @@ -45,12 +47,14 @@
 td class=LightBackgrounddiv
 id=portlet:namespace/UpTimefmt:message
 key=infomanager.svrInfoNormal.notAvailable//div/td
   /tr
  /table
 -br
 -table width=100%
 +br/
 +
 +bfmt:message key=infomanager.svrInfoNormal.os/:/b
 +table width=100% class=TableLine summary=OS
   tr
 -td class=DarkBackground width=100% colspan=2
 align=centerfmt:message key=infomanager.svrInfoNormal.os//td
 +th scope=col class=DarkBackground width=20%
 align=centerfmt:message key=consolebase.common.item//th
 +th scope=col class=DarkBackground width=80%
 align=centerfmt:message key=consolebase.common.value//th
   /tr
 -
   tr
 td class=LightBackground width=20% nowrapfmt:message
 key=infomanager.svrInfoNormal.os.arch//td
 td class=LightBackground width=80%${svrProps['os.arch']}/td
 @@ -72,10 +76,13 @@
 td class=LightBackground width=80%${svrProps['os.locale']}/td
   /tr
  /table
 -br
 -table width=100%
 +br/
 +
 +bfmt:message key=infomanager.svrInfoNormal.jvm/:/b
 +table width=100% class=TableLine summary=JVM
   tr
 -td class=DarkBackground width=100% colspan=2
 align=centerfmt:message key=infomanager.svrInfoNormal.jvm//td
 +th scope=col class=DarkBackground width=20%
 align=centerfmt:message key=consolebase.common.item//th
 +th scope=col class=DarkBackground width=80%
 align=centerfmt:message key=consolebase.common.value//th
   /tr
   tr
 td class=LightBackground width=20% nowrapfmt:message
 key=infomanager.svrInfoNormal.javaVersion//td





-- 
~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/

[Jason Warner]

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 jaw...@gmail.com 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, dwo...@apache.org wrote:

 Author: dwoods
 Date: Tue Jan  6 09:30:41 2009
 New Revision: 732011

 URL: http://svn.apache.org/viewvc?rev=732011view=rev
 Log:
 GERONIMO-4025 applied GERONIMO-4025-configmanager-and-infomanager.patch
 from Rex Wang.

 Modified:

  
 geronimo/server/trunk/plugins/console/console-base-portlets/src/main/resources/consolebase.properties

  
 geronimo/server/trunk/plugins/console/console-base-portlets/src/main/resources

Re: svn commit: r724818 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy

[Jason Warner]

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=724818view=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=724818r1=724817r2=724818view=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] Created: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3

[Jason Warner (JIRA)]

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

[Jason Warner]

 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

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

[Jason Warner]

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.init(FileInputStream.java:106)
at
 hidden.org.codehaus.plexus.util.xml.XmlReader.init(XmlReader.java:123)
at
 hidden.org.codehaus.plexus.util.xml.XmlStreamReader.init(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] mailto:
 [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




-Donald


Jarek Gawor wrote:

If we are switching to activemq5 why do we need this
${activemqString}
substitution?

Jarek

On Mon, Dec 8, 2008 at 6:59 PM,  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Author: djencks
Date: Mon Dec  8 15:59:58 2008
New Revision: 724558

URL:
http://svn.apache.org/viewvc?rev=724558view=rev
http://svn.apache.org/viewvc?rev=724558view=rev
Log:
GERONIMO-4337 upgrade to activemq 5.2.  Reduced
console functionality

Added:

  
 geronimo/server/trunk/plugins/activemq5/geronimo

[jira] Resolved: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3

[Jason Warner (JIRA)]

 [ 
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: r723242 - /geronimo/server/trunk/plugins/monitoring/agent/src/main/plan/plan.xml

[Jason Warner]

-runas-realm/attribute
 +attribute name=publishfalse/attribute
 +xml-reference name=LoginModuleConfiguration
 +lc:login-config xmlns:lc=
 http://geronimo.apache.org/xml/ns/loginconfig-1.2;
 +lc:login-module control-flag=REQUIRED
 +
  lc:login-domain-namemonitoring-runas-domain/lc:login-domain-name
 +
  
 lc:login-module-classorg.apache.geronimo.security.credentialstore.RunAsLoginModule/lc:login-module-class
 +lc:option
 name=principalClassorg.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal/lc:option
 +lc:option name=principalNamesadmin/lc:option
 +/lc:login-module
 +/lc:login-config
 +/xml-reference
 +!--reference name=ServerInfo--
 +!--nameServerInfo/name--
 +!--/reference--
 +/gbean
 +
 +
  /openejb-jar








-- 
~Jason Warner

Re: Subscribe mail list dev@geronimo.apache.org

[Jason Warner]

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: Subscribe mail list dev@geronimo.apache.org

[Jason Warner]

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: Status of server/trunk wrt any release?

[Jason Warner]

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: [BUILD] branches/2.0: Failed for Revision: 719139

[Jason Warner]

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: error starting trunk javaee5 assemblies

[Jason Warner]

)
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(generated)
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: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2

[Jason Warner]

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: Is there a bp project for Geronimo like petstore?

[Jason Warner]

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: 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

[Jason Warner]

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=713680view=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
 snip






-- 
~Jason Warner

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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
 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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 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 import element to the
 dependencies in g-p.xml.  I guess we'd expect a more or less empty
 environment 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

Re: svn commit: r706725 - /geronimo/sandbox/build-support/

[Jason Warner]

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=706725view=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?

[Jason Warner]

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: An idea for defining custom valves in config.xml

[Jason Warner]

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 import element to
 the dependencies in g-p.xml.  I guess we'd expect a more or less empty
 environment 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

[Jason Warner]

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 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 import element to
 the dependencies in g-p.xml.  I guess we'd expect a more or less empty
 environment 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: Where will ee6 development take place?

[Jason Warner]

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

Re: Continuous TCK Testing

[Jason Warner]

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#a7649902http://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: Continuous TCK Testing

[Jason Warner]

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#a7649902http://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: restart of tck08 on selene

[Jason Warner]

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: An idea for defining custom valves in config.xml

[Jason Warner]

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 new plugin.  Here you are saying that there's good way to do
this.  When I deployed the plan.xml, the resultant directory in the
repository was missing a geronimo-plugin.xml.


 thanks
 david jencks






 Joe

  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks [EMAIL PROTECTED]mailto:
 [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

[jira] Commented: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml

[Jason Warner (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[Jason Warner]

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 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.

 thanks
 david jencks






 Joe

  On Wed, Oct 8, 2008 at 2:25 PM, David Jencks [EMAIL PROTECTED]mailto:
 [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

Re: Continuous TCK Testing

[Jason Warner]

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 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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 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 examples prepared
 yet.



 At the moment I

Re: Continuous TCK Testing

[Jason Warner]

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 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 G server,
 then built the CTS server (using the *exact* artifacts from the G server
 build, even though each might have happened

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 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

Re: Continuous TCK Testing

[Jason Warner]

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 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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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

Re: Continuous TCK Testing

[Jason Warner]

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 G server,
 then built the CTS server (using the *exact* artifacts from the G server
 build, even though each might have happened on a different build agent).
  And now we need to go and run a bunch of tests, using the *exact* CTS
 server assemblies, produce some output, collect it, and once all of the
 tests are done render some nice reports, etc.

 AHP supports setting up builds which

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 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

Re: An idea for defining custom valves in config.xml

[Jason Warner]

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 examples prepared
yet.



 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

[jira] Created: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml

[Jason Warner (JIRA)]

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.

[jira] Updated: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml

[Jason Warner (JIRA)]

 [ 
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.

An idea for defining custom valves in config.xml

[Jason Warner]

  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

Re: [VOTE] Release Geronimo Samples 2.1.2

[Jason Warner]

+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

Re: Continuous TCK Testing

[Jason Warner]

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

Packaging error when building trunk

[Jason Warner]

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

[jira] Closed: (GERONIMO-3468) Links broken through Ajp13.

[Jason Warner (JIRA)]

 [ 
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-58) Layout command aliases should be allowed to reference relative command paths for targets

[Jason Warner (JIRA)]

 [ 
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}
 ...
 group
 nameremote/name
 nodes
 command
 namersh/name
 idgshell-remote:rsh/id
 /command
 command
 namersh-server/name
 idgshell-remote:rsh-server/id
 /command
 alias
 namershd/name
 commandrsh-server/command
 /alias
 /nodes
 /group
 /nodes
 /layout
 {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.

[jira] Closed: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager

[Jason Warner (JIRA)]

 [ 
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.

Re: Continuous TCK Testing

[Jason Warner]

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

[Jason Warner]

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.gzhttp://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.ziphttp://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.gzhttp://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.ziphttp://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: [ANNOUNCE] Welcome BJ Reed as a new Geronimo Committer

[Jason Warner]

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: [DISCUSS] Geronimo 2.1.3 release

[Jason Warner]

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: [jira] Closed: (GERONIMO-4278) Upgrade to OpenJPA 1.2.0

[Jason Warner]

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.12.2 Documentation

[Jason Warner]

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.12.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)

[Jason Warner]

+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] Updated: (GERONIMO-4264) Enable static configuration of a wadi cluster

[Jason Warner (JIRA)]

 [ 
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.

[jira] Created: (GERONIMO-4264) Enable static configuration of a wadi cluster

[Jason Warner (JIRA)]

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

[Jason Warner (JIRA)]

 [ 
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] Closed: (GERONIMO-4264) Enable static configuration of a wadi cluster

[Jason Warner (JIRA)]

 [ 
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.

Re: apache httpd and geronimo -- newbie

[Jason Warner]

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] Created: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT

[Jason Warner (JIRA)]

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.

[jira] Closed: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT

[Jason Warner (JIRA)]

 [ 
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.

Re: svn commit: r686040 - /geronimo/server/trunk/pom.xml

[Jason Warner]

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=686040view=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=686040r1=686039r2=686040view=diff

 ==
 --- geronimo/server/trunk/pom.xml (original)
 +++ geronimo/server/trunk/pom.xml Thu Aug 14 13:54:03 2008
 @@ -82,7 +82,7 @@
plutoVersion1.1.6-G643117/plutoVersion
openjpaVersion1.0.2/openjpaVersion
xbeanVersion3.4.1/xbeanVersion
 -wadiVersion2.0/wadiVersion
 +wadiVersion2.0-SNAPSHOT/wadiVersion


 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] Updated: (GERONIMO-4244) Update to latest wadi 2.1-SNAPSHOT

[Jason Warner (JIRA)]

 [ 
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: Reducing the dojo footprint in Geronimo

[Jason Warner]

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

Re: Documentation of new 2.2 features in current wiki?

[Jason Warner]

If our goal is to have developers create documentation for new features when
the feature is integrate, then I don't see why we shouldn't just create the
2.2 space now and seed it with 2.1 right away.  If no new features are added
yet, then the old documentation applies just as much to 2.2 as it does to
2.1, and if new features are added and documented appropriately, then people
can just use the appropriate documentation space for the appropriate
version.  Basically, I'm saying I think we should seed the 2.2 documentation
space now and update it as we go along.

On Thu, Aug 7, 2008 at 11:43 AM, Jarek Gawor [EMAIL PROTECTED] wrote:

 IMHO, the 2.2 space must be seeded from the 2.1 space. The question is
 just when to do it. That's why I suggested creating 2.2 content under
 some temporary space. Once we have the actual 2.2 space setup (from
 2.1 content) then we can move these new pages into 2.2 space. It will
 be a lot easier to move just a few pages of the new content then merge
 lots of pages of 2.1 content into 2.2 space.

 Jarek

 On Thu, Aug 7, 2008 at 11:02 AM, Joe Bohn [EMAIL PROTECTED] wrote:
 
  I agree in principle with creating a new location for 2.2 features to be
  documented.  My only concern was that we are consistent so that the
  documentation will be easy for users to find and easy to integrate when
 we
  eventually do a mass merge from 2.1 to 2.2.
 
  So, I created a new space for 2.2 documentation to provide a consistent
  structure and to capture the enthusiasm to document 2.2 changes.  I
 seeded
  it with a top level structure that matches our 2.1 doc but no actual
  content.  You can find it here:
  http://cwiki.apache.org/GMOxDOC22/documentation.html
 
  I suggest that we create new content for 2.2 under this page for now:
  http://cwiki.apache.org/GMOxDOC22/what-changed-in-22.html
    I chose the current name to match what we had in 2.1.
 
  If a particular change has broad implications for documentation that is
  already available in 2.1, we can copy current 2.1 content into 2.2 and
  modify it accordingly.
 
  As David pointed out earlier, we do not have the ability to automatically
  merge the 2.1 content into the 2.2 content at a later time using this
  approach.  Any merge will be a manual effort.  The only alternative I am
  aware of would be to seed the new 2.2 space with the complete current 2.1
  content.  However, that brings about some maintenance issues of keeping
  things in sync and doesn't encourage 2.2 updates.  When we last discussed
  this for 2.1 we decided to start with the empty space and so I took the
 same
  approach for this release.
 
  I hope this provides something that will serve as a good place for the
 2.2
  content for now.  If we decide later that we should have started with a
  complete copy of 2.1 we can always create a copy and merge the new 2.2
  documents back into the 2.1 copy.  However, for now this at least
 provides a
  place we can use and it is obvious to our users where they can find 2.2
  documentation.
 
  Joe
 
 
  Donald Woods wrote:
 
  Agree.  We could just create a New Features in 2.2 page and people can
  create child pages to it for their new features as they are integrated
 into
  trunk
 
 
  -Donald
 
 
  Jarek Gawor wrote:
 
  I think it would be nicer to create pages with 2.2 specific content
  somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now.
  Once we have 2.2 documentation space setup we can move the pages
  around. Or at least I don't think we should mix 2.2 content with 2.1
  content.
 
  Jarek
 
  On Tue, Jul 29, 2008 at 1:52 PM, David Jencks [EMAIL PROTECTED]
  wrote:
 
  I've been playing around with openid and jaspi and would like to write
  up
  some documentation before I forget how it all works :-)
 
  I don't think we have enough people interested in documentation to
  pursue
  anything but the easiest-to-write path in documentation.  In
 particular
  I
  think more than one active copy of the docs is asking 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

[jira] Closed: (GERONIMO-4220) Tomcat Cluster Sender gbean should allow Transport element

[Jason Warner (JIRA)]

 [ 
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

[Jason Warner]

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.gzhttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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

Re: [VOTE] Geronimo Server 2.1.2 Release

[Jason Warner]

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.gzhttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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

[Jason Warner]

+1.  All tck tests have passed.

On Sat, Aug 2, 2008 at 6:55 AM, YunFeng Ma [EMAIL PROTECTED] wrote:

 +1

 -- Yun Feng


 Joe Bohn 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.gzhttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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.ziphttp://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