date:20080513

Geronimo Revision: 656071 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/build-2100.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 31 minutes 41 seconds
[INFO] Finished at: Tue May 13 21:35:38 EDT 2008
[INFO] Final Memory: 338M/1000M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/logs-2100-tomcat/test.log
 
 
[INFO] [site:attach-descriptor]
[INFO] [selenium:start-server {execution: start}]
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Including display properties from: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/display.properties
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:39.214
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 27 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   FAILURE (0:01:21.420) Java 
returned: 1
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:39.596) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:45.428) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:51.732) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:41.457) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.902) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:28.132) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:29.559) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:35.725) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:44.064) 
[INFO] enterprise-testsuite/jpa-tests

Re: Questions about monitoring app/plugins

2008-05-13 Thread Viet Nguyen

Hi David,

You are right about not needing to wrap the ejb app inside an EAR. I
think your patch attached with geronimo-4014 looks great.

Regarding the JNDI look up in the jmx-jar, I resorted to using
something like 
"jca:/org.apache.geronimo.plugins/agent-ds/JCAManagedConnectionFactory/jdbc/ActiveDS"
because of the discussion taken place here:
http://www.nabble.com/how-to-get-Datasource-from-a-non-j2ee-module-td15081831s134.html

It also looks be to consistent with the format given on the wiki.
Which JNDI string do you see a problem with?

Thanks,
Viet

[jira] Created: (GERONIMO-4015) Protecting EJB based Web services but excluding wsdl from the protection

2008-05-13 Thread Rafael Thomas Goz Coutinho (JIRA)

Protecting EJB based Web services but excluding wsdl from the protection


 Key: GERONIMO-4015
 URL: https://issues.apache.org/jira/browse/GERONIMO-4015
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: OpenEJB
Reporter: Rafael Thomas Goz Coutinho
Priority: Minor


When we protect a Web service using HTTP Basic authentication we protect all 
access to that Webservice endpoint URL even to the generated WSDL. 

When exposing a POJO based webservices using a Web project the usual work 
around is to set the http-method to only protect POST requests. So the GET to 
the wsdl will not be protected.

However when exposing an EJB based Webservice we can not configure that, so the 
wsdl is always protected for POST or GET requests.

It would be nice if we could change that...

here is a example of the EJB WS security deployment plan:


Test


WSTest


NONE
BASIC




No place for defining the HTTP method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4014) simplify monitorying plugin structure

2008-05-13 Thread Viet Hung Nguyen (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596595#action_12596595
 ] 

Viet Hung Nguyen commented on GERONIMO-4014:


Thanks David, I never thought about organizing the agent like that. If no one 
else has any objections, can you commit it?

> simplify monitorying plugin structure
> -
>
> Key: GERONIMO-4014
> URL: https://issues.apache.org/jira/browse/GERONIMO-4014
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4014.diff
>
>
> Suggestion on how to eliminate one of the apparently superfluous ears, move 
> plan to more appropriate location.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need some advice on how to include repository/* bits in the boilerplate

Attached patch includes other changes, like moving to jaxb 2.1, some 
security changes, 


Other comments attached to GERONIMO-4013.


-Donald


David Jencks wrote:
I've attached a patch to GERONIMO-4013 that reverses the changes from 
4012 and change the car-maven-plugin to optionally follow transitive 
dependencies.  I think if you apply my patch you won't be using the 
gshell-* plugins.  I had to make a couple other minor build changes to 
get the build to complete.  The server builds and shows signs of 
starting -- on my copy it runs into some problems with unrelated changes 
to the security system I'm working on.


Jason, can you check the generated dependencies in the gshell-* plugins 
to see if they look remotely plausible or can be nudged closer to 
plausible?


thanks
david jencks

On May 13, 2008, at 11:55 AM, David Jencks wrote:

I talked with jason a bit on irc and we're doing an experiment with 
optionally including transitive dependencies using the 
car-maven-plugin.  Hopefully this will work and avoid the duplication 
jason is leery of.  Please don't commit duplication until we find out 
if this works or not.


AFAICT this isn't a bug fix but rather new development so I'm unclear 
about why you are thinking of including this in 2.1.2?


thanks
david jencks

On May 13, 2008, at 11:32 AM, Donald Woods wrote:

I started with your new framework/configs/gshell-* code, updated 
gshell-framework to include all the individual depends so we don't 
need gshell-embeddable, updated server/pom.xml with the new depends 
and updated boilerplate with the new gshell-geronimo car depend and 
it looks promising.  I'm still exercising some of the gsh commands, 
but so far help, geronimo/start-server, deploy/connect and 
geronimo/stop-server are working


If all looks well after a few more tests, I'll commit the changes 
into trunk for everyone to review before we spend the time pulling it 
into 2.1.2.



-Donald


Jason Dillon wrote:

On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the 
boilerplate's pom would get them into the geronimo repo.  As I said 
transitive dependencies don't result in inclusion at the moment for 
rather good reasons.  I don't know what the  tag would do 
but it's probably worth investigating.

What  tag are you talking about?
I guess I'm gonna try to make plugins for the gshell dependencies, 
these 3:

  gshell-framework - just the core bits required to make gshell work
  gshell-geronimo - our additional commands to work with the server 
+ their deps

  gshell-remote - the remote/whisper commands
I must say I'm really quite frustrated at the lack of transitive 
dependency support here.  As this means that alot of the 
dependencyManagement configuration which is already in the GShell 
poms need to be duplicated into the Geronimo poms, making version 
management even more of a nightmare.

:-(
Well, I started to add these cars to framework/configs, but I must 
admit I really am clueless for how this stuff works now.

:-(
--jason







smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


[ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596594#action_12596594
 ] 

Donald Woods commented on GERONIMO-4013:


How will the last 2 changes in the patch to car-maven-plugin work for the 
custom assembly creation from cmdline and admin console?  The depends need to 
be included in boilerplate (which the current code in trunk does using standard 
CAR depends) so exported assemblies will include them.
What if someone includes a newer version of a server depend in our repo?  Will 
the transitiveDepnds correctly pull in the version that the original server was 
built with, or will it pull in the newer one which might not work as expected?


> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


[ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596591#action_12596591
 ] 

Donald Woods commented on GERONIMO-4013:


Patch lso includes some other security work - 
+


> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


[ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596592#action_12596592
 ] 

Donald Woods commented on GERONIMO-4013:


Patch also includes unrelated jaxb change to 2.1.6 -
 com.sun.xml.bind
 jaxb-impl
-2.0.5
+2.1.6



> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


[ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596589#action_12596589
 ] 

Donald Woods commented on GERONIMO-4013:


Can you rework the patch to not put gshell-embeddable back in, as it includes 
jline and a couple other plexus jars that are at different levels than the 
server and is hiding the fact that we are shipping additional plexus and gshell 
depends

> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


[ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596585#action_12596585
 ] 

Donald Woods commented on GERONIMO-4013:


The attached patch includes the proposed changes for G4014.

> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need some advice on how to include repository/* bits in the boilerplate

I've attached a patch to GERONIMO-4013 that reverses the changes from  
4012 and change the car-maven-plugin to optionally follow transitive  
dependencies.  I think if you apply my patch you won't be using the  
gshell-* plugins.  I had to make a couple other minor build changes to  
get the build to complete.  The server builds and shows signs of  
starting -- on my copy it runs into some problems with unrelated  
changes to the security system I'm working on.


Jason, can you check the generated dependencies in the gshell-*  
plugins to see if they look remotely plausible or can be nudged closer  
to plausible?


thanks
david jencks

On May 13, 2008, at 11:55 AM, David Jencks wrote:

I talked with jason a bit on irc and we're doing an experiment with  
optionally including transitive dependencies using the car-maven- 
plugin.  Hopefully this will work and avoid the duplication jason is  
leery of.  Please don't commit duplication until we find out if this  
works or not.


AFAICT this isn't a bug fix but rather new development so I'm  
unclear about why you are thinking of including this in 2.1.2?


thanks
david jencks

On May 13, 2008, at 11:32 AM, Donald Woods wrote:

I started with your new framework/configs/gshell-* code, updated  
gshell-framework to include all the individual depends so we don't  
need gshell-embeddable, updated server/pom.xml with the new depends  
and updated boilerplate with the new gshell-geronimo car depend and  
it looks promising.  I'm still exercising some of the gsh commands,  
but so far help, geronimo/start-server, deploy/connect and geronimo/ 
stop-server are working


If all looks well after a few more tests, I'll commit the changes  
into trunk for everyone to review before we spend the time pulling  
it into 2.1.2.



-Donald


Jason Dillon wrote:

On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the  
boilerplate's pom would get them into the geronimo repo.  As I  
said transitive dependencies don't result in inclusion at the  
moment for rather good reasons.  I don't know what the   
tag would do but it's probably worth investigating.

What  tag are you talking about?
I guess I'm gonna try to make plugins for the gshell dependencies,  
these 3:

  gshell-framework - just the core bits required to make gshell work
  gshell-geronimo - our additional commands to work with the  
server + their deps

  gshell-remote - the remote/whisper commands
I must say I'm really quite frustrated at the lack of transitive  
dependency support here.  As this means that alot of the  
dependencyManagement configuration which is already in the GShell  
poms need to be duplicated into the Geronimo poms, making version  
management even more of a nightmare.

:-(
Well, I started to add these cars to framework/configs, but I must  
admit I really am clueless for how this stuff works now.

:-(
--jason

[jira] Updated: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks updated GERONIMO-4013:
---

Attachment: GERONIMO-4013.diff

This patch reverses the changes from GERONIMO-4012 which prevent working on 
this issue, changes the car-maven-plugin, uses the new flag in the gshell-* 
configs, and fixes things up so the build works for me.  I think the gshell-* 
plugins are not getting used in this build but we can look at the dependencies 
added to the plans/geronimo-plugin.xml and see if those are reasonable.

> Make our dependency usage the same as maven dependency usage via 
> car-maven-plugin
> -
>
> Key: GERONIMO-4013
> URL: https://issues.apache.org/jira/browse/GERONIMO-4013
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4013.diff
>
>
> Right now the car-maven-plugin ignores maven transitive dependencies.  One 
> reason for this is that our build is not using our plugins as the 
> "classloader source" of the maven dependencies that are in the plugin poms.  
> If we restructured our build so that the pom dependency graph matched the 
> geronimo classloader graph then perhaps we could let the car-maven-plugin 
> follow transitive dependencies, thus making our view of dependencies pretty 
> much the same as maven's.
> This may show up many other problems, such as too many badly scoped 
> dependencies in all sorts of projects we use.
> One first step is to try out the car-maven-plugin with a flag for following 
> transitive dependencies.  As long as it is false we ought to get pretty much 
> the previous behavior.
> A first use could be for the new gshell plugins so they don't have to restate 
> all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Jay D. McHugh


Thanks, that would be great.

Jay

Kevan Miller wrote:


On May 13, 2008, at 1:07 PM, Jay D. McHugh wrote:


I'll volunteer to help out on supporting the machines.

I haven't been able to to much useful TCK work since my most powerful 
available system is a laptop that gets restarted twice a day.


Heh. That sounds less than ideal. Jay, I'm pretty sure we can get you 
access to the same machines that Joe has used for his testing. Let me 
know, if you're interested.


--kevan

Re: Questions about monitoring app/plugins

I opened GERONIMO-4014 and attached a suggestion about how to remove  
one of the ears that don't look necessary to me.


thanks
david jencks

On May 13, 2008, at 4:48 PM, David Jencks wrote:

I was having some mysterious build problems and happened to look at  
the monitoring app today a bit (plugins/monitoring).  I'm a bit  
confused by the structure and wonder if it could be simplified.


My impression is that there are two versions of an agent and a web  
app.


agent:
common jar
datasource
ejb app
jmx jar

The ejb app appears to be wrapped in an ear.  Why?  I can't see any  
reason for this
the jmx jar doesn't appear to be looking up the right thing in  
jndi.  See http://cwiki.apache.org/confluence/display/GMOxDOC21/ 
JNDI  geronimo-connector should not be needed here.


monitoring app:
Here there appears to be a war inside an ear for no apparent reason.

Could someone who has worked on this in the past comment?

thanks
david jencks

[jira] Commented: (GERONIMO-4011) Need private build of JLine to fix GShell problems on Windows


[ 
https://issues.apache.org/jira/browse/GERONIMO-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596575#action_12596575
 ] 

Donald Woods commented on GERONIMO-4011:


[ 1899669 ] Unsupported terminal an Windows produces two prompts
https://sourceforge.net/tracker/index.php?func=detail&aid=1899669&group_id=64033&atid=506056

and possibly

[ 1753686 ] ConsoleReader.readLine can throw HeadlessException
https://sourceforge.net/tracker/index.php?func=detail&aid=1753686&group_id=64033&atid=506056


> Need private build of JLine to fix GShell problems on Windows
> -
>
> Key: GERONIMO-4011
> URL: https://issues.apache.org/jira/browse/GERONIMO-4011
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
> Fix For: 2.1.2, 2.2
>
>
> There are several GShell problems on Windows, due to JLine bugs.
> I'm going to try and create a patched build of JLine 0.9.94 to resolve these 
> issues, as Geronimo packages the JLine jar into our assembly for GShell to 
> use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4014) simplify monitorying plugin structure


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks updated GERONIMO-4014:
---

Attachment: GERONIMO-4014.diff

remove one ear, put plan in correct place (didn't remove original plan)

> simplify monitorying plugin structure
> -
>
> Key: GERONIMO-4014
> URL: https://issues.apache.org/jira/browse/GERONIMO-4014
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.2
>Reporter: David Jencks
> Fix For: 2.2
>
> Attachments: GERONIMO-4014.diff
>
>
> Suggestion on how to eliminate one of the apparently superfluous ears, move 
> plan to more appropriate location.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4014) simplify monitorying plugin structure

simplify monitorying plugin structure
-

 Key: GERONIMO-4014
 URL: https://issues.apache.org/jira/browse/GERONIMO-4014
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.2
Reporter: David Jencks
 Fix For: 2.2


Suggestion on how to eliminate one of the apparently superfluous ears, move 
plan to more appropriate location.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Questions about monitoring app/plugins

I was having some mysterious build problems and happened to look at  
the monitoring app today a bit (plugins/monitoring).  I'm a bit  
confused by the structure and wonder if it could be simplified.


My impression is that there are two versions of an agent and a web app.

agent:
common jar
datasource
ejb app
jmx jar

The ejb app appears to be wrapped in an ear.  Why?  I can't see any  
reason for this
the jmx jar doesn't appear to be looking up the right thing in jndi.   
See http://cwiki.apache.org/confluence/display/GMOxDOC21/JNDI   
geronimo-connector should not be needed here.


monitoring app:
Here there appears to be a war inside an ear for no apparent reason.

Could someone who has worked on this in the past comment?

thanks
david jencks

[jira] Created: (GERONIMODEVTOOLS-346) Adding security roles in the Geronimo Deployment Plan Editor does not work

2008-05-13 Thread Cedric Hurst (JIRA)

Adding security roles in the Geronimo Deployment Plan Editor does not work
--

 Key: GERONIMODEVTOOLS-346
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-346
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.0
 Environment: Eclipse Europa Winter (WTP 2.0.2), Windows XP SP2, 
Geronimo 2.1.1, GEP 2.1.0, 
Reporter: Cedric Hurst
Assignee: Tim McConnell


Steps to reproduce
===
1. Create a new Enterprise Application Project
2. Open the "geronimo-application.xml" file in the graphical editor
3. Select the security tab
4. Click the add button in the "Security Roles" section
5. Provide any value for name and/or description and click "Finish"

Expected behavior
===
New role will show up in the Security Role list and in the source view of 
geronimo-application.xml

Actual behavior
===
Role does not show up, nor is it added the the actual xml file.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Ready to release Geronimo 2.1 samples?


Jarek Gawor wrote:

Also, I think we should just release samples for the 2.1.1 release (no
need to release samples for 2.1 in my opinion).



I was thinking the opposite ... release the samples for 2.1 and then 
attempt to leverage them in server 2.1.1 without a 2.1.1 release of 
samples.  Assuming we get a solution as David suggests we could then 
potentially employ that solution for future 2.1.x releases.


Joe




Jarek

On Mon, May 12, 2008 at 11:41 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:

Is there any reason not to release the current Geronimo 2.1 samples
(https://svn.apache.org/repos/asf/geronimo/samples/branches/2.1)?

 I'd be glad to work to get a release candidate created for this (I've
already done some prep to get things updated for the new release process).

 Once we get the 2.1 Samples released we can turn around and release the
2.1.1 samples and then I think we'll finally be "up to date".

 I have some questions about how we might accomplish this via the new
process but I'll follow that up in another note.

 Joe

[BUILD] trunk: Failed for Revision: 655974

Geronimo Revision: 655974 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/build-1500.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 32 minutes 32 seconds
[INFO] Finished at: Tue May 13 15:35:51 EDT 2008
[INFO] Final Memory: 337M/1015M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/logs-1500-tomcat/test.log
 
 
[INFO] [site:attach-descriptor]
[INFO] [selenium:start-server {execution: start}]
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Including display properties from: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/display.properties
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:38.634
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 27 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   FAILURE (0:01:19.308) Java 
returned: 1
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:39.921) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:44.336) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:53.041) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:42.015) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:29.574) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:27.405) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:27.719) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:35.189) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:44.182) 
[INFO] enterprise-testsuite/jpa-tests

Re: Need some advice on how to include repository/* bits in the boilerplate

Well, changes were already checked into trunk about 20 miins. before 
your email


The changes need to also go into branches/2.1, because right now we have 
different/duplicate versions of some depends included in Geronimo 2.1.x 
and 2.2, due to the gshell-embeddable jarfile, which was created using 
the shade-maven-plugin and no one noticed the mismatched depends and the 
fact that Geronimo is actually including additional plexus and gshell 
jars that are not visible in our repository, due to shade extracting 
them and repackaging them into this uber gshell-embeddable jar.


I'm for fixing the transitive depend mechanism in car-maven-plugin, as 
long as it correctly handles different versions between the server and 
other projects, with the server/pom.xml specified versions always winning.


I'm against the continued usage of the gshell-embeddable jar, as it 
hides the fact that we are including other depends in our server 
assemblies and will just likely cause more version conflicts and 
duplicate depends in the future.  Maybe if you get the car-maven-plugin 
updated for transitive depends and mismatched versions, then we can just 
create a new gshell-framework pom that lets gshell tell us and the 
car-maven-plugin which depends to pull in



-Donald


David Jencks wrote:
I talked with jason a bit on irc and we're doing an experiment with 
optionally including transitive dependencies using the 
car-maven-plugin.  Hopefully this will work and avoid the duplication 
jason is leery of.  Please don't commit duplication until we find out if 
this works or not.


AFAICT this isn't a bug fix but rather new development so I'm unclear 
about why you are thinking of including this in 2.1.2?


thanks
david jencks

On May 13, 2008, at 11:32 AM, Donald Woods wrote:

I started with your new framework/configs/gshell-* code, updated 
gshell-framework to include all the individual depends so we don't 
need gshell-embeddable, updated server/pom.xml with the new depends 
and updated boilerplate with the new gshell-geronimo car depend and it 
looks promising.  I'm still exercising some of the gsh commands, but 
so far help, geronimo/start-server, deploy/connect and 
geronimo/stop-server are working


If all looks well after a few more tests, I'll commit the changes into 
trunk for everyone to review before we spend the time pulling it into 
2.1.2.



-Donald


Jason Dillon wrote:

On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the 
boilerplate's pom would get them into the geronimo repo.  As I said 
transitive dependencies don't result in inclusion at the moment for 
rather good reasons.  I don't know what the  tag would do 
but it's probably worth investigating.

What  tag are you talking about?
I guess I'm gonna try to make plugins for the gshell dependencies, 
these 3:

   gshell-framework - just the core bits required to make gshell work
   gshell-geronimo - our additional commands to work with the server 
+ their deps

   gshell-remote - the remote/whisper commands
I must say I'm really quite frustrated at the lack of transitive 
dependency support here.  As this means that alot of the 
dependencyManagement configuration which is already in the GShell 
poms need to be duplicated into the Geronimo poms, making version 
management even more of a nightmare.

:-(
Well, I started to add these cars to framework/configs, but I must 
admit I really am clueless for how this stuff works now.

:-(
--jason





smime.p7s
Description: S/MIME Cryptographic Signature

[BUILD] branches/2.1: Failed for Revision: 655951

Geronimo Revision: 655951 built with tests included
 
See the full build-1400.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/build-1400.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 31 minutes 25 seconds
[INFO] Finished at: Tue May 13 14:35:36 EDT 2008
[INFO] Final Memory: 306M/1013M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/logs-1400-tomcat/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 56.696 
sec <<< FAILURE!
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/logs-1400-jetty/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 62.518 
sec <<< FAILURE!
 
Samples: branches/2.1
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/samples-1400.log
 
Build status: FAILED

Update Derby to 10.3.2.1

2008-05-13 Thread Jason Warner

I'd like to update our derby version to 10.3.2.1 in branches/2.1 and trunk.
This is directly related to the update of tomcat and resolves some TCK
issues introduced by the tomcat update.  This is all assuming TCK remains
happy.

-- 
~Jason Warner

[jira] Commented: (GERONIMO-4012) Rework GShell integration


[ 
https://issues.apache.org/jira/browse/GERONIMO-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596511#action_12596511
 ] 

David Jencks commented on GERONIMO-4012:


This may be helped by GERONIMO-4013

> Rework GShell integration
> -
>
> Key: GERONIMO-4012
> URL: https://issues.apache.org/jira/browse/GERONIMO-4012
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.2
>Reporter: Donald Woods
> Fix For: 2.1.2, 2.2
>
>
> Continuing on Jason Dillon's recent r655744 changes in trunk, we need to 
> improve the gshell integration into the Geronimo assemblies.
> We also need to remove the gshell-embeddable usage and pull in individual 
> depends, so we'll only have one version of each in the server, instead of the 
> current multiple copies of some jars, like jline.  Also, this will help with 
> the release process, so we can see all depends and verify the license/notice 
> files, instead of some jars being pulled in by the shade-maven-plugin used to 
> build gshell-embeddable

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4013) Make our dependency usage the same as maven dependency usage via car-maven-plugin

Make our dependency usage the same as maven dependency usage via 
car-maven-plugin
-

 Key: GERONIMO-4013
 URL: https://issues.apache.org/jira/browse/GERONIMO-4013
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Affects Versions: 2.2
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.2


Right now the car-maven-plugin ignores maven transitive dependencies.  One 
reason for this is that our build is not using our plugins as the "classloader 
source" of the maven dependencies that are in the plugin poms.  If we 
restructured our build so that the pom dependency graph matched the geronimo 
classloader graph then perhaps we could let the car-maven-plugin follow 
transitive dependencies, thus making our view of dependencies pretty much the 
same as maven's.

This may show up many other problems, such as too many badly scoped 
dependencies in all sorts of projects we use.

One first step is to try out the car-maven-plugin with a flag for following 
transitive dependencies.  As long as it is false we ought to get pretty much 
the previous behavior.

A first use could be for the new gshell plugins so they don't have to restate 
all the transitive dependencies.  This may show up scope problems as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Kevan Miller



On May 13, 2008, at 1:25 PM, Jason Dillon wrote:


On May 13, 2008, at 10:42 PM, Joe Bohn wrote:
Right I was running 2 very beefy machines manually in a dedicated  
fashion with no automation.  If we want something to share,  
multiple VM images, and multiple concurrent tests then it would  
need to be a bit more robust than what I was using.  So I was  
planning to ask for 4 multi-core machines (need to do some research  
on CPU capacity) and 3-4 GB RAM each.  I'll include that we could  
get by with just 2 machines for a time while we work out the  
automation/sharing issues.


I sent a note asking for some clarification on what they are  
looking for in a proposal and an example (if available).  I'd like  
for whatever we request to be in line with most of their other  
systems in terms of OS level/version, VM software, etc...  so that  
we can avoid the "one off" issue they list while still getting a  
system that can support our testing needs.


What happened to the AMD systems which were heating up my apartment  
last year?  2 4x (dual core) 16g machines with nice RAID cards,  
etc... ?


Those machines are owned by IBM. IBM would be happy to donate them to  
the ASF. However, they then become a potential support annoyance/ 
headache/migraine for Infra. IIUC, it's simpler, more manageable, etc  
to buy new, standard hardware and roll it into mainstream ASF  
infrastructure.


--kevan

Re: ASF hosted machines for TCK testing


Jason Dillon wrote:

On May 13, 2008, at 10:42 PM, Joe Bohn wrote:
Right I was running 2 very beefy machines manually in a dedicated 
fashion with no automation.  If we want something to share, multiple 
VM images, and multiple concurrent tests then it would need to be a 
bit more robust than what I was using.  So I was planning to ask for 4 
multi-core machines (need to do some research on CPU capacity) and 3-4 
GB RAM each.  I'll include that we could get by with just 2 machines 
for a time while we work out the automation/sharing issues.


I sent a note asking for some clarification on what they are looking 
for in a proposal and an example (if available).  I'd like for 
whatever we request to be in line with most of their other systems in 
terms of OS level/version, VM software, etc...  so that we can avoid 
the "one off" issue they list while still getting a system that can 
support our testing needs.


What happened to the AMD systems which were heating up my apartment last 
year?  2 4x (dual core) 16g machines with nice RAID cards, etc... ?


I'm not sure where those are at but I'm sure we can track them down. 
Another bit of criteria that I learned for ASF hosted machines is that 
they must be rack-mountable and have "lights-out management"

LOMs.  Is that the case for your apartment heating machines?

We'll probably want more something like 8-core machines (or possibly 
4-core).  I was hoping for 3-4 GB per core ... but we might have to 
settle for closer to 2 as Donald suggested.  I'm not really sure what 
the limits on RAM are for these types of machines.


Joe

[jira] Updated: (GERONIMODEVTOOLS-345) Reported server state falls out-of-sync after Windows Hibernate

2008-05-13 Thread Tim McConnell (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell updated GERONIMODEVTOOLS-345:
---

Fix Version/s: 2.1.1

> Reported server state falls out-of-sync after Windows Hibernate
> ---
>
> Key: GERONIMODEVTOOLS-345
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-345
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0.0, 2.1.0
> Environment: Windows XP SP2, Eclipse Europa for Java EE Developers 
> [Winter Maintenance Release], Geronimo Eclipse Plugin 2.1.0
>Reporter: Cedric Hurst
>Assignee: Tim McConnell
> Fix For: 2.1.1
>
>
> After doing a system hibernate with a running geronimo server, Eclipse 
> reports the server state as "Stopped" when the system resumes.  However, the 
> server process is still active and http://localhost:8080 is accessible from a 
> browser.  Attempting to do a "Start" or "Clean" operation against the server 
> in Eclipse produces a "Port 8080 required by Web Connector is already in use. 
> The server may already be running in another process, or a system process may 
> be using the port. To start this server you will need to stop the other 
> process or change the port number(s)."
> At present, you must manually shut down the server from the admin console or 
> command line and start it again from the Eclipse IDE.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMODEVTOOLS-345) Reported server state falls out-of-sync after Windows Hibernate

2008-05-13 Thread Cedric Hurst (JIRA)

Reported server state falls out-of-sync after Windows Hibernate
---

 Key: GERONIMODEVTOOLS-345
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-345
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.1.0, 2.0.0
 Environment: Windows XP SP2, Eclipse Europa for Java EE Developers 
[Winter Maintenance Release], Geronimo Eclipse Plugin 2.1.0
Reporter: Cedric Hurst
Assignee: Tim McConnell
 Fix For: 2.1.1


After doing a system hibernate with a running geronimo server, Eclipse reports 
the server state as "Stopped" when the system resumes.  However, the server 
process is still active and http://localhost:8080 is accessible from a browser. 
 Attempting to do a "Start" or "Clean" operation against the server in Eclipse 
produces a "Port 8080 required by Web Connector is already in use. The server 
may already be running in another process, or a system process may be using the 
port. To start this server you will need to stop the other process or change 
the port number(s)."

At present, you must manually shut down the server from the admin console or 
command line and start it again from the Eclipse IDE.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Kevan Miller



On May 13, 2008, at 1:07 PM, Jay D. McHugh wrote:


I'll volunteer to help out on supporting the machines.

I haven't been able to to much useful TCK work since my most  
powerful available system is a laptop that gets restarted twice a day.


Heh. That sounds less than ideal. Jay, I'm pretty sure we can get you  
access to the same machines that Joe has used for his testing. Let me  
know, if you're interested.


--kevan

Re: Need some advice on how to include repository/* bits in the boilerplate

I talked with jason a bit on irc and we're doing an experiment with  
optionally including transitive dependencies using the car-maven- 
plugin.  Hopefully this will work and avoid the duplication jason is  
leery of.  Please don't commit duplication until we find out if this  
works or not.


AFAICT this isn't a bug fix but rather new development so I'm unclear  
about why you are thinking of including this in 2.1.2?


thanks
david jencks

On May 13, 2008, at 11:32 AM, Donald Woods wrote:

I started with your new framework/configs/gshell-* code, updated  
gshell-framework to include all the individual depends so we don't  
need gshell-embeddable, updated server/pom.xml with the new depends  
and updated boilerplate with the new gshell-geronimo car depend and  
it looks promising.  I'm still exercising some of the gsh commands,  
but so far help, geronimo/start-server, deploy/connect and geronimo/ 
stop-server are working


If all looks well after a few more tests, I'll commit the changes  
into trunk for everyone to review before we spend the time pulling  
it into 2.1.2.



-Donald


Jason Dillon wrote:

On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the  
boilerplate's pom would get them into the geronimo repo.  As I  
said transitive dependencies don't result in inclusion at the  
moment for rather good reasons.  I don't know what the   
tag would do but it's probably worth investigating.

What  tag are you talking about?
I guess I'm gonna try to make plugins for the gshell dependencies,  
these 3:

   gshell-framework - just the core bits required to make gshell work
   gshell-geronimo - our additional commands to work with the  
server + their deps

   gshell-remote - the remote/whisper commands
I must say I'm really quite frustrated at the lack of transitive  
dependency support here.  As this means that alot of the  
dependencyManagement configuration which is already in the GShell  
poms need to be duplicated into the Geronimo poms, making version  
management even more of a nightmare.

:-(
Well, I started to add these cars to framework/configs, but I must  
admit I really am clueless for how this stuff works now.

:-(
--jason

[jira] Created: (GERONIMO-4012) Rework GShell integration

Rework GShell integration
-

 Key: GERONIMO-4012
 URL: https://issues.apache.org/jira/browse/GERONIMO-4012
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: dependencies
Affects Versions: 2.1.1, 2.1, 2.1.2, 2.2
Reporter: Donald Woods
 Fix For: 2.1.2, 2.2


Continuing on Jason Dillon's recent r655744 changes in trunk, we need to 
improve the gshell integration into the Geronimo assemblies.
We also need to remove the gshell-embeddable usage and pull in individual 
depends, so we'll only have one version of each in the server, instead of the 
current multiple copies of some jars, like jline.  Also, this will help with 
the release process, so we can see all depends and verify the license/notice 
files, instead of some jars being pulled in by the shade-maven-plugin used to 
build gshell-embeddable



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need some advice on how to include repository/* bits in the boilerplate


BTW - I opened GERONIMO-4012 so we can track the changes for this effort...


-Donald


Jason Dillon wrote:
I'm trying to remove the use of the gshell-embeddable artifact, which 
includes some duplicates (like jline, xstream, slf4j, etc)... but I 
can't figure out how the new assembly bits are used to get stuff into 
the repository/*.


I can hack something up (with the assembly + antrun plugins) but I'm 
wondering if there is a better way.  I'd like to not have a ton of pom 
config to list all of the gshell required dependencies, just use mvn's 
transitive deps to populate the repository/* with the bits that gshell 
needs.


Anyone have any suggestions?

--jason



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Need some advice on how to include repository/* bits in the boilerplate

I started with your new framework/configs/gshell-* code, updated 
gshell-framework to include all the individual depends so we don't need 
gshell-embeddable, updated server/pom.xml with the new depends and 
updated boilerplate with the new gshell-geronimo car depend and it looks 
promising.  I'm still exercising some of the gsh commands, but so far 
help, geronimo/start-server, deploy/connect and geronimo/stop-server are 
working


If all looks well after a few more tests, I'll commit the changes into 
trunk for everyone to review before we spend the time pulling it into 2.1.2.



-Donald


Jason Dillon wrote:

On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the boilerplate's 
pom would get them into the geronimo repo.  As I said transitive 
dependencies don't result in inclusion at the moment for rather good 
reasons.  I don't know what the  tag would do but it's 
probably worth investigating.


What  tag are you talking about?

I guess I'm gonna try to make plugins for the gshell dependencies, these 3:

gshell-framework - just the core bits required to make gshell work
gshell-geronimo - our additional commands to work with the server + 
their deps

gshell-remote - the remote/whisper commands

I must say I'm really quite frustrated at the lack of transitive 
dependency support here.  As this means that alot of the 
dependencyManagement configuration which is already in the GShell poms 
need to be duplicated into the Geronimo poms, making version management 
even more of a nightmare.


:-(

Well, I started to add these cars to framework/configs, but I must admit 
I really am clueless for how this stuff works now.


:-(

--jason




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ASF hosted machines for TCK testing

If we want to run multiple images on a machine, then I'd up the 
requirements to 2 or 4 way AMD/Intel Quad core with a minimum of 8GB RAM 
for 4 cores and 16GB for 8 cores.  That way, you can have 2 or 3 images 
running through the buckets at full force, while having another image 
there for debugging test failures or for testing out new depend levels 
before dropping it into the build (like Tomcat 6.0.16...)


Two 2xQuad machines would be great (these come in 1U vs. 2U or more for 
4xQuad) and with 8GB RAM each and as much disk space as possible for 
storing multiple vm images per release (Geronimo 2.1.2 and 2.2.)



-Donald


Joe Bohn wrote:

Kevan Miller wrote:


On May 12, 2008, at 6:05 PM, Joe Bohn wrote:


All,

We have discussed in the past the idea of getting some ASF hosted 
machines that we can use to run and share TCK test results for 
Geronimo.  With more folks coming on board running TCK tests this 
seems to be getting more and more important.  It would also be great 
if we could get some of the automation working again on these 
dedicated machines ... but I think we need to secure some machines 
first.  For now, I think we should just get something we can share 
for Geronimo with an eye toward possible sharing across other ASF 
projects in the future.


Some recent discussions with infra indicate that the Geronimo PMC 
needs to submit a proposal for these machines if we ever hope to get 
some. The proposal must meet the criteria listed below in addition to 
some more obvious things such as the number and specifications of the 
machines. The Geronimo PMC must approve and then make the request to 
ASF infra but we can discuss the requirements here and formulate the 
proposal.  Please jump in if you have opinions on the specs and 
number of machines.  Keep in mind that we need to keep this request 
reasonable if we have a hope of getting it accepted.  I also imagine 
that we'll have to volunteer some people to help manage these 
machines  volunteers?


I'll start to put together a proposal with your input and when we 
think it is complete enough I'll forward it to the PMC for further 
action.


The sooner we can get this proposal pulled together the better off 
we'll be.


Does anybody have a sample proposal for something similar from infra? 
I'm not sure how detailed this proposal must be.


Joe,
This would be fantastic. Thanks for starting this discussion. Our 
GBuild hosting infrastructure is no more. And we're overly reliant on 
the machines running in Matt's basement.


IIRC, you've been keeping 2 machines pretty busy running CTS tests. 
So, at an absolute minimum, I think we'd need 2 beefy multi-core 
machines. Preferably, we'd have 3-4. With a stable hardware and 
hosting environment, I think we could get an automated test system up 
and running reliably. If we can use multiple VM images to concurrently 
run tests, we'd be able to make better use of the hardware (with 
faster turn-around of tests).


--kevan


Right I was running 2 very beefy machines manually in a dedicated 
fashion with no automation.  If we want something to share, multiple VM 
images, and multiple concurrent tests then it would need to be a bit 
more robust than what I was using.  So I was planning to ask for 4 
multi-core machines (need to do some research on CPU capacity) and 3-4 
GB RAM each.  I'll include that we could get by with just 2 machines for 
a time while we work out the automation/sharing issues.


I sent a note asking for some clarification on what they are looking for 
in a proposal and an example (if available).  I'd like for whatever we 
request to be in line with most of their other systems in terms of OS 
level/version, VM software, etc...  so that we can avoid the "one off" 
issue they list while still getting a system that can support our 
testing needs.


Thanks for the feedback!
Joe




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Jason Dillon


On May 13, 2008, at 10:42 PM, Joe Bohn wrote:
Right I was running 2 very beefy machines manually in a dedicated  
fashion with no automation.  If we want something to share, multiple  
VM images, and multiple concurrent tests then it would need to be a  
bit more robust than what I was using.  So I was planning to ask for  
4 multi-core machines (need to do some research on CPU capacity) and  
3-4 GB RAM each.  I'll include that we could get by with just 2  
machines for a time while we work out the automation/sharing issues.


I sent a note asking for some clarification on what they are looking  
for in a proposal and an example (if available).  I'd like for  
whatever we request to be in line with most of their other systems  
in terms of OS level/version, VM software, etc...  so that we can  
avoid the "one off" issue they list while still getting a system  
that can support our testing needs.


What happened to the AMD systems which were heating up my apartment  
last year?  2 4x (dual core) 16g machines with nice RAID cards, etc... ?


--jason

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Jay D. McHugh


I'll volunteer to help out on supporting the machines.

I haven't been able to to much useful TCK work since my most powerful 
available system is a laptop that gets restarted twice a day.


Jay

Joe Bohn wrote:

All,

We have discussed in the past the idea of getting some ASF hosted 
machines that we can use to run and share TCK test results for Geronimo. 
 With more folks coming on board running TCK tests this seems to be 
getting more and more important.  It would also be great if we could get 
some of the automation working again on these dedicated machines ... but 
I think we need to secure some machines first.  For now, I think we 
should just get something we can share for Geronimo with an eye toward 
possible sharing across other ASF projects in the future.


Some recent discussions with infra indicate that the Geronimo PMC needs 
to submit a proposal for these machines if we ever hope to get some. The 
proposal must meet the criteria listed below in addition to some more 
obvious things such as the number and specifications of the machines. 
The Geronimo PMC must approve and then make the request to ASF infra but 
we can discuss the requirements here and formulate the proposal.  Please 
jump in if you have opinions on the specs and number of machines.  Keep 
in mind that we need to keep this request reasonable if we have a hope 
of getting it accepted.  I also imagine that we'll have to volunteer 
some people to help manage these machines  volunteers?


I'll start to put together a proposal with your input and when we think 
it is complete enough I'll forward it to the PMC for further action.


The sooner we can get this proposal pulled together the better off we'll 
be.


Does anybody have a sample proposal for something similar from infra? 
I'm not sure how detailed this proposal must be.


Thanks,
Joe


ASF infra checklist:
---
This provides a list of requirements and doctrines for web applications
that wish to be deployed on the Apache Infrastrcture.  It is intended to
help address many of the recurring issues we see with deployment and
maintainence of applications.

Definition of 'system': Any web application or site which will receive
traffic from public users in any manner.

Definition of 'critical systems': Any web application or site which runs
under www.apache.org, or is expected to receive a significant portion of
traffic.

1) All systems must be generally secure and robust. In cases of failure,
they should not damage the entire machine.

2) All systems must provide reliable backups, at least once a day, with
preference to incremental, real time or <1 hour snapshots.

3) All systems must be maintainable by multiple active members of the
infrastructure team.

4) All systems must come with a 'runbook' describing what to do in event
of failures, reboots, etc.  (If someone who has root needs to reboot the
box, what do they need to pay attention to?)

5) All systems must provide at least minimal monitoring via Nagios.

6) All systems must be restorable and relocatable to other machines
without significant pain.

7) All systems must have some kind of critical mass.  In general we do
not want to host one offs of any system.

8) All system configuration files must be checked into Subversion.

9) All system source must either be checked into Subversion, be at a
well-known public location, or is provided by the base OS.  (Hosting
binary-only webapps is a non-starter.)

10) All systems, prior to consideration of deployment, must provide a
detailed performance impact analysis (bandwidth and CPU).  How are
techniques like HTTP caching used?  Lack of HTTP caching was MoinMoin's
initial PITA.

11) All systems must have clearly articulated, defined, and recorded
dependencies.

12) All critical systems must be replicated across multiple machines,
with preference to cross-atlantic replication.

13) All systems must have single command operations to start, restart
and stop the system.  Support for init scripts used by the base
operating system is preferred.

Re: maven 2.0.8

2008-05-13 Thread Jason Dillon


Ya, probs a good idea.

--jason


On May 13, 2008, at 9:18 PM, Jarek Gawor wrote:


Should we require maven 2.0.8+ for trunk? Today I've noticed that the
version of maven-javadoc-plugin specified in the root pom requires
maven 2.0.8:

[INFO] Error resolving version for
'org.apache.maven.plugins:maven-javadoc-plugin': Plugin requires Maven
version 2.0.8

Jarek

[jira] Commented: (GERONIMO-4011) Need private build of JLine to fix GShell problems on Windows

2008-05-13 Thread Jason Dillon (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596438#action_12596438
 ] 

Jason Dillon commented on GERONIMO-4011:


Patch it with what?


> Need private build of JLine to fix GShell problems on Windows
> -
>
> Key: GERONIMO-4011
> URL: https://issues.apache.org/jira/browse/GERONIMO-4011
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
> Fix For: 2.1.2, 2.2
>
>
> There are several GShell problems on Windows, due to JLine bugs.
> I'm going to try and create a patched build of JLine 0.9.94 to resolve these 
> issues, as Geronimo packages the JLine jar into our assembly for GShell to 
> use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need some advice on how to include repository/* bits in the boilerplate



On May 12, 2008, at 11:26 PM, Jason Dillon wrote:


On May 13, 2008, at 1:14 AM, David Jencks wrote:
So including the dependencies you need for gshell in the  
boilerplate's pom would get them into the geronimo repo.  As I said  
transitive dependencies don't result in inclusion at the moment for  
rather good reasons.  I don't know what the  tag would do  
but it's probably worth investigating.


What  tag are you talking about?


As usual I get include and import confused.  See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html 
 under import dependencies.  I find the docs pretty unclear about  
whether actual dependencies (rather than dependency management  
sections) get imported into the using pom's dependencies or are  
ignored or something else.


I'll see if I can do an experiment to see if/how this works.

It does require maven 2.0.9

thanks
david jencks




I guess I'm gonna try to make plugins for the gshell dependencies,  
these 3:


   gshell-framework - just the core bits required to make gshell work
   gshell-geronimo - our additional commands to work with the server  
+ their deps

   gshell-remote - the remote/whisper commands

I must say I'm really quite frustrated at the lack of transitive  
dependency support here.  As this means that alot of the  
dependencyManagement configuration which is already in the GShell  
poms need to be duplicated into the Geronimo poms, making version  
management even more of a nightmare.


:-(

Well, I started to add these cars to framework/configs, but I must  
admit I really am clueless for how this stuff works now.


:-(

--jason

Re: Release process questions

On May 12, 2008, at 8:05 PM, Joe Bohn wrote:

David Jencks wrote:

On May 12, 2008, at 11:54 AM, Joe Bohn wrote:

Joe Bohn wrote:

David Jencks wrote:
I may not be understanding the issues here. if so please
point this out.

On May 12, 2008, at 9:00 AM, Joe Bohn wrote:

The new release process [1] generally assumes that we are
releasing from trunk and always bumps the version number up by
one.

Those are not intended to be assumptions :-) Maybe bad writing.
Ah ... ok. The wiki mentioned that we should avoid the
complexity of releasing from branches in favor of releasing from
trunk. I took this too literally. IIUC the intent is that we
should not be creating a temporary branch just to later convert
it to a tag for a release.

However, for things like samples we want to keep version
numbers consistent with the Geronimo Server versions and as
such we would need to release from branches. So here are some
questions:

#1 Can we follow the new release process from a branch
(geronimo/samples/branches/2.1) rather than trunk? I think
this should work. Anybody know of any issues?

I'm pretty sure this should work fine, I did something very
similar with activemq 4.1.2

Ok, I'll give that a shot.

#2 Releasing from branches/2.1 would result in the versions in
the branch being updated to 2.2-SNAPSHOT and a tag/2.1 release
(I think). However, we want the branch to live on as a 2.1.*
branch ... so I assume that I could just manually update the
versions to 2.1.1-SNAPSHOT from 2.2-SNAPSHOT. Likewise, I
would rename the tag from tags/2.1 to tags/2.1.0. Does anybody
see a problem with this (see #3 for another idea)? After the
initial jump from the 2 digit version to the 3 digit version
things should work normally for future releases.

I like what activemq does more and more. With numbers
transposed to match our versions, they keep the branch in
branches/2.1, the branch version at 2.1-SNAPSHOT, and release
2.1.1, 2.1.2, 2.1.3, ... from this branch. You just need to
fill in the 2.1.x release version and 2.1-SNAPSHOT branch
version when you run mvn release:prepare. Even if we dont keep
the version at 2.1-SNAPSHOT but update it to 2.1.(x+1)-SNAPSHOT
I think the branch name in svn should continue to be branches/2.1
This is the same process that we followed with 2.1. I'll dig
into the details of specifying the releases rather than allowing
the defaults that bump up the version number of the release by 1.

#3 The previous question makes me wonder if we should be
following consistent 2 or 3 digit version numbers for projects
which should eliminate the need for the renames. Should
Geronimo 2.1 (and hence Geronimo Samples for 2.1) have been
versioned 2.1.0 rather than 2.1. It seems that is the version
number we adopted for the server tag which is called tags/
2.1.0. It would make it possible to use the maven-release
plugin for major versions as well as minor versions. The
branch would still be branches/2.1 but the version for the poms
would be 2.1.x-SNAPSHOT as we currently do for server branches/
2.1. Thoughts? If we adopted this strategy we would also want
to revision server trunk from 2.2-SNAPSHOT to 2.2.0-SNAPSHOT.

I think anything we do that isn't from the release plugin should
be ignored as guidance. I think the release plugin creates tags
like - under tags. This is fine
IMNSHO.

Actually, I did think of one addition concern with our current
numbering and using the maven release plugin. If we only use 2
digit version numbers for major releases then we would end up with
tags/2.2 and branches/2.2. This may be a point of confusion when
looking at our svn repos (and I suspect the reason that we have
tags/2.1.0 rather than tags/2.1 right now). NOTE: I have not yet
looked into the how the version is specified with the maven-
release-plugin. Perhaps we can specify the release version and
the tag version independently in which case I could name the
appropriately via the plugin.

Wouldn't we end up with server/branches/2.2 and server/tags/
geronimo-parent-2.2? These seem sufficiently distinct to me to
avoid confusion.

hmmm now I'm confused. What is server/tags/geronimo-parent and
why would it replace server/tags/2.2?

The release plugin generates tags named like -version>. I might have the geronimo-parent name wrong.

Actually, since this is really a discussion about samples, how would
we not end up with samples/branches/2.1 and samples/tags/2.1 (where
the branches continually used for 2.1.x releases and tags is the 2.1
release) if there is not a way to specify the artifact release
version independently from the tag release version? What am I
missing?

I suspect the naming issue is why we named the tag sever/tags/2.1.0
when we released Geronimo 2.1 so that the tag would have a different
version number from the branch that was to continue, server/branc

Re: ASF hosted machines for TCK testing


Kevan Miller wrote:


On May 12, 2008, at 6:05 PM, Joe Bohn wrote:


All,

We have discussed in the past the idea of getting some ASF hosted 
machines that we can use to run and share TCK test results for 
Geronimo.  With more folks coming on board running TCK tests this 
seems to be getting more and more important.  It would also be great 
if we could get some of the automation working again on these 
dedicated machines ... but I think we need to secure some machines 
first.  For now, I think we should just get something we can share for 
Geronimo with an eye toward possible sharing across other ASF projects 
in the future.


Some recent discussions with infra indicate that the Geronimo PMC 
needs to submit a proposal for these machines if we ever hope to get 
some. The proposal must meet the criteria listed below in addition to 
some more obvious things such as the number and specifications of the 
machines. The Geronimo PMC must approve and then make the request to 
ASF infra but we can discuss the requirements here and formulate the 
proposal.  Please jump in if you have opinions on the specs and number 
of machines.  Keep in mind that we need to keep this request 
reasonable if we have a hope of getting it accepted.  I also imagine 
that we'll have to volunteer some people to help manage these machines 
 volunteers?


I'll start to put together a proposal with your input and when we 
think it is complete enough I'll forward it to the PMC for further 
action.


The sooner we can get this proposal pulled together the better off 
we'll be.


Does anybody have a sample proposal for something similar from infra? 
I'm not sure how detailed this proposal must be.


Joe,
This would be fantastic. Thanks for starting this discussion. Our GBuild 
hosting infrastructure is no more. And we're overly reliant on the 
machines running in Matt's basement.


IIRC, you've been keeping 2 machines pretty busy running CTS tests. So, 
at an absolute minimum, I think we'd need 2 beefy multi-core machines. 
Preferably, we'd have 3-4. With a stable hardware and hosting 
environment, I think we could get an automated test system up and 
running reliably. If we can use multiple VM images to concurrently run 
tests, we'd be able to make better use of the hardware (with faster 
turn-around of tests).


--kevan


Right I was running 2 very beefy machines manually in a dedicated 
fashion with no automation.  If we want something to share, multiple VM 
images, and multiple concurrent tests then it would need to be a bit 
more robust than what I was using.  So I was planning to ask for 4 
multi-core machines (need to do some research on CPU capacity) and 3-4 
GB RAM each.  I'll include that we could get by with just 2 machines for 
a time while we work out the automation/sharing issues.


I sent a note asking for some clarification on what they are looking for 
in a proposal and an example (if available).  I'd like for whatever we 
request to be in line with most of their other systems in terms of OS 
level/version, VM software, etc...  so that we can avoid the "one off" 
issue they list while still getting a system that can support our 
testing needs.


Thanks for the feedback!
Joe

Re: [DISCUSS] Ready to release Geronimo 2.1 samples?

Also, I think we should just release samples for the 2.1.1 release (no
need to release samples for 2.1 in my opinion).

Jarek

On Mon, May 12, 2008 at 11:41 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> Is there any reason not to release the current Geronimo 2.1 samples
> (https://svn.apache.org/repos/asf/geronimo/samples/branches/2.1)?
>
>  I'd be glad to work to get a release candidate created for this (I've
> already done some prep to get things updated for the new release process).
>
>  Once we get the 2.1 Samples released we can turn around and release the
> 2.1.1 samples and then I think we'll finally be "up to date".
>
>  I have some questions about how we might accomplish this via the new
> process but I'll follow that up in another note.
>
>  Joe
>

[jira] Updated: (GERONIMO-3975) PlanCreator fails to deploy an application when Geronimo is installed into a directory with white space


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-3975:
---

Affects Version/s: (was: 2.2)
   2.1

> PlanCreator fails to deploy an application when Geronimo is installed into a 
> directory with white space
> ---
>
> Key: GERONIMO-3975
> URL: https://issues.apache.org/jira/browse/GERONIMO-3975
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.1, 2.1.1
> Environment: Windows
>Reporter: YunFeng Ma
>Assignee: Donald Woods
> Fix For: 2.1.2
>
> Attachments: GERONIMO-3975.patch
>
>
> The following exceptions are thrown:
> 16:48:55,328 ERROR [GetArchiveHandler] Illegal character in path at index 23: 
> fi
> le:/H:/geronimo server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJD
> BCAccess.war
> java.net.URISyntaxException: Illegal character in path at index 23: 
> file:/H:/geronimo 
> server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJDBCAccess.w
> ar
> at java.net.URI$Parser.fail(URI.java:2821)
> at java.net.URI$Parser.checkChars(URI.java:2994)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3026)
> at java.net.URI.(URI.java:590)
> at java.net.URL.toURI(URL.java:950)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.createApplicatio
> nInfo(JSR88_Util.java:132)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.parseWarReferenc
> es(JSR88_Util.java:144)
> at 
> org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAft
> erView(GetArchiveHandler.java:90)
> at 
> org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP
> ortlet.java:114)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
> )
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> atcher.java:654)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> ispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> patcher.java:481)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPort
> letInvokerService.java:167)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPort
> letInvokerService.java:85)
> at 
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerI
> mpl.java:219)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet
> .java:112)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServle
> t.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> torBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:406)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 563)
> at 
> org.apache.catalina.connector.CoyoteAdapter

[jira] Updated: (GERONIMO-3975) PlanCreator fails to deploy an application when Geronimo is installed into a directory with white space


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-3975:
---

Patch Info: [Patch Available]

> PlanCreator fails to deploy an application when Geronimo is installed into a 
> directory with white space
> ---
>
> Key: GERONIMO-3975
> URL: https://issues.apache.org/jira/browse/GERONIMO-3975
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.1, 2.1.1
> Environment: Windows
>Reporter: YunFeng Ma
>Assignee: Donald Woods
> Fix For: 2.1.2
>
> Attachments: GERONIMO-3975.patch
>
>
> The following exceptions are thrown:
> 16:48:55,328 ERROR [GetArchiveHandler] Illegal character in path at index 23: 
> fi
> le:/H:/geronimo server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJD
> BCAccess.war
> java.net.URISyntaxException: Illegal character in path at index 23: 
> file:/H:/geronimo 
> server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJDBCAccess.w
> ar
> at java.net.URI$Parser.fail(URI.java:2821)
> at java.net.URI$Parser.checkChars(URI.java:2994)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3026)
> at java.net.URI.(URI.java:590)
> at java.net.URL.toURI(URL.java:950)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.createApplicatio
> nInfo(JSR88_Util.java:132)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.parseWarReferenc
> es(JSR88_Util.java:144)
> at 
> org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAft
> erView(GetArchiveHandler.java:90)
> at 
> org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP
> ortlet.java:114)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
> )
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> atcher.java:654)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> ispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> patcher.java:481)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPort
> letInvokerService.java:167)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPort
> letInvokerService.java:85)
> at 
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerI
> mpl.java:219)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet
> .java:112)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServle
> t.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> torBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:406)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:

[jira] Resolved: (GERONIMO-3975) PlanCreator fails to deploy an application when Geronimo is installed into a directory with white space


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods resolved GERONIMO-3975.


   Resolution: Fixed
Fix Version/s: (was: 2.2)

Committed revision 655899.
Only applied patch to 2.1.2, as the code in trunk (2.2) had significant changes 
and didn't use toURI().


> PlanCreator fails to deploy an application when Geronimo is installed into a 
> directory with white space
> ---
>
> Key: GERONIMO-3975
> URL: https://issues.apache.org/jira/browse/GERONIMO-3975
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.1, 2.1.1
> Environment: Windows
>Reporter: YunFeng Ma
>Assignee: Donald Woods
> Fix For: 2.1.2
>
> Attachments: GERONIMO-3975.patch
>
>
> The following exceptions are thrown:
> 16:48:55,328 ERROR [GetArchiveHandler] Illegal character in path at index 23: 
> fi
> le:/H:/geronimo server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJD
> BCAccess.war
> java.net.URISyntaxException: Illegal character in path at index 23: 
> file:/H:/geronimo 
> server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJDBCAccess.w
> ar
> at java.net.URI$Parser.fail(URI.java:2821)
> at java.net.URI$Parser.checkChars(URI.java:2994)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3026)
> at java.net.URI.(URI.java:590)
> at java.net.URL.toURI(URL.java:950)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.createApplicatio
> nInfo(JSR88_Util.java:132)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.parseWarReferenc
> es(JSR88_Util.java:144)
> at 
> org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAft
> erView(GetArchiveHandler.java:90)
> at 
> org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP
> ortlet.java:114)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
> )
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> atcher.java:654)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> ispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> patcher.java:481)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPort
> letInvokerService.java:167)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPort
> letInvokerService.java:85)
> at 
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerI
> mpl.java:219)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet
> .java:112)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServle
> t.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> torBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:406)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.ap

Re: ASF hosted machines for TCK testing

2008-05-13 Thread Kevan Miller



On May 12, 2008, at 6:05 PM, Joe Bohn wrote:


All,

We have discussed in the past the idea of getting some ASF hosted  
machines that we can use to run and share TCK test results for  
Geronimo.  With more folks coming on board running TCK tests this  
seems to be getting more and more important.  It would also be great  
if we could get some of the automation working again on these  
dedicated machines ... but I think we need to secure some machines  
first.  For now, I think we should just get something we can share  
for Geronimo with an eye toward possible sharing across other ASF  
projects in the future.


Some recent discussions with infra indicate that the Geronimo PMC  
needs to submit a proposal for these machines if we ever hope to get  
some. The proposal must meet the criteria listed below in addition  
to some more obvious things such as the number and specifications of  
the machines. The Geronimo PMC must approve and then make the  
request to ASF infra but we can discuss the requirements here and  
formulate the proposal.  Please jump in if you have opinions on the  
specs and number of machines.  Keep in mind that we need to keep  
this request reasonable if we have a hope of getting it accepted.  I  
also imagine that we'll have to volunteer some people to help manage  
these machines  volunteers?


I'll start to put together a proposal with your input and when we  
think it is complete enough I'll forward it to the PMC for further  
action.


The sooner we can get this proposal pulled together the better off  
we'll be.


Does anybody have a sample proposal for something similar from  
infra? I'm not sure how detailed this proposal must be.


Joe,
This would be fantastic. Thanks for starting this discussion. Our  
GBuild hosting infrastructure is no more. And we're overly reliant on  
the machines running in Matt's basement.


IIRC, you've been keeping 2 machines pretty busy running CTS tests.  
So, at an absolute minimum, I think we'd need 2 beefy multi-core  
machines. Preferably, we'd have 3-4. With a stable hardware and  
hosting environment, I think we could get an automated test system up  
and running reliably. If we can use multiple VM images to concurrently  
run tests, we'd be able to make better use of the hardware (with  
faster turn-around of tests).


--kevan

Re: [DISCUSS] Ready to release Geronimo 2.1 samples?

No (as far as I know of). Let's get the samples released! And let me
know if you need help with that.

Thanks,
Jarek

On Mon, May 12, 2008 at 11:41 AM, Joe Bohn <[EMAIL PROTECTED]> wrote:
> Is there any reason not to release the current Geronimo 2.1 samples
> (https://svn.apache.org/repos/asf/geronimo/samples/branches/2.1)?
>
>  I'd be glad to work to get a release candidate created for this (I've
> already done some prep to get things updated for the new release process).
>
>  Once we get the 2.1 Samples released we can turn around and release the
> 2.1.1 samples and then I think we'll finally be "up to date".
>
>  I have some questions about how we might accomplish this via the new
> process but I'll follow that up in another note.
>
>  Joe
>

[jira] Assigned: (GERONIMO-3975) PlanCreator fails to deploy an application when Geronimo is installed into a directory with white space


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods reassigned GERONIMO-3975:
--

Assignee: Donald Woods  (was: Shiva Kumar H R)

> PlanCreator fails to deploy an application when Geronimo is installed into a 
> directory with white space
> ---
>
> Key: GERONIMO-3975
> URL: https://issues.apache.org/jira/browse/GERONIMO-3975
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: PlanCreator
>Affects Versions: 2.1.1, 2.2
> Environment: Windows
>Reporter: YunFeng Ma
>Assignee: Donald Woods
> Fix For: 2.1.2, 2.2
>
> Attachments: GERONIMO-3975.patch
>
>
> The following exceptions are thrown:
> 16:48:55,328 ERROR [GetArchiveHandler] Illegal character in path at index 23: 
> fi
> le:/H:/geronimo server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJD
> BCAccess.war
> java.net.URISyntaxException: Illegal character in path at index 23: 
> file:/H:/geronimo 
> server1/var/temp/geronimo-planCreator39270.tmpdir/WebAppJDBCAccess.w
> ar
> at java.net.URI$Parser.fail(URI.java:2821)
> at java.net.URI$Parser.checkChars(URI.java:2994)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3026)
> at java.net.URI.(URI.java:590)
> at java.net.URL.toURI(URL.java:950)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.createApplicatio
> nInfo(JSR88_Util.java:132)
> at 
> org.apache.geronimo.console.configcreator.JSR88_Util.parseWarReferenc
> es(JSR88_Util.java:144)
> at 
> org.apache.geronimo.console.configcreator.GetArchiveHandler.actionAft
> erView(GetArchiveHandler.java:90)
> at 
> org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPageP
> ortlet.java:114)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
> )
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:145)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
> atcher.java:654)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
> ispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
> patcher.java:481)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPort
> letInvokerService.java:167)
> at 
> org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPort
> letInvokerService.java:85)
> at 
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerI
> mpl.java:219)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet
> .java:112)
> at 
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServle
> t.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:233)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
> bjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> torBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:406)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> 563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.se

Re: Upgrade trunk/branches 2.1.x to use Tomcat 6.0.16

As long as it includes our required 6.0.x patches and passes the TCK, 
then including it in 2.1.2 and 2.2 sounds good to me.



-Donald


Jason Warner wrote:
Through some testing, I found that the NIO connector in Tomcat 6.0.14 
has some issues handling heavy load.  These issues appear to be fixed in 
Tomcat 6.0.16.   I'd like to upgrade trunk to use this 
new version of tomcat.  I was going to upgrade branches 2.1.x while I 
was at it.  Any objections?


Thanks,

--
~Jason Warner


smime.p7s
Description: S/MIME Cryptographic Signature

Re: maven 2.0.8


Jarek Gawor wrote:

Should we require maven 2.0.8+ for trunk? Today I've noticed that the
version of maven-javadoc-plugin specified in the root pom requires
maven 2.0.8:

[INFO] Error resolving version for
'org.apache.maven.plugins:maven-javadoc-plugin': Plugin requires Maven
version 2.0.8

Jarek



I think that would be a good idea.

Joe

[BUILD] trunk: Failed for Revision: 655847

Geronimo Revision: 655847 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/build-0900.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 34 minutes 39 seconds
[INFO] Finished at: Tue May 13 09:38:16 EDT 2008
[INFO] Final Memory: 328M/1003M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080513/logs-0900-tomcat/test.log
 
 
[INFO] [site:attach-descriptor]
[INFO] [selenium:start-server {execution: start}]
Launching Selenium Server
Waiting for Selenium Server...
[INFO] Including display properties from: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/display.properties
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/server.log
[INFO] User extensions: 
/home/geronimo/geronimo/trunk/testsuite/target/selenium/user-extensions.js
Selenium Server started
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: 
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from codehaus-snapshots
[INFO] snapshot 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking 
for updates from apache.snapshots
[INFO] Using assembly artifact: 
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT
[INFO] Using geronimoHome: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding: 
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
 into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to: 
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:36.833
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to 
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 27 test build(s)
[INFO] 
[INFO] 
---
[INFO] 
[INFO] console-testsuite/advanced   RUNNING
[INFO] console-testsuite/advanced   FAILURE (0:01:17.885) Java 
returned: 1
[INFO] console-testsuite/basic  RUNNING
[INFO] console-testsuite/basic  SUCCESS (0:01:37.904) 
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:40.259) 
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:59.637) 
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:38.083) 
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:26.673) 
[INFO] deployment-testsuite/jca-cms-tests   RUNNING
[INFO] deployment-testsuite/jca-cms-tests   SUCCESS (0:00:25.340) 
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:24.167) 
[INFO] enterprise-testsuite/ejb-tests   RUNNING
[INFO] enterprise-testsuite/ejb-tests   SUCCESS (0:00:29.793) 
[INFO] enterprise-testsuite/jms-tests   RUNNING
[INFO] enterprise-testsuite/jms-tests   SUCCESS (0:00:39.027) 
[INFO] enterprise-testsuite/jpa-tests

maven 2.0.8

Should we require maven 2.0.8+ for trunk? Today I've noticed that the
version of maven-javadoc-plugin specified in the root pom requires
maven 2.0.8:

[INFO] Error resolving version for
'org.apache.maven.plugins:maven-javadoc-plugin': Plugin requires Maven
version 2.0.8

Jarek

Re: svn commit: r654748 - in /geronimo/server/trunk/testsuite: ./ console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/ deployment-testsuite/ deployment-testsuite/deployment-

Cool, thanks!

Jarek

On Tue, May 13, 2008 at 1:24 AM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> This should be functional again.  You don't need to specify -DexcludeTest=
> anymore, just set the -DassemblyId to either jetty or tomcat and the
> excludes will configure appropriately.
>
>
>  --jason
>
>
>  On May 13, 2008, at 12:23 AM, Jarek Gawor wrote:
>
>
>
> > Jason,
> >
> > Can you please restore that excludeTest functionality (unless you are
> > planning to put in a workaround for that soon)? This is being used by
> > the automatic tests right now.
> >
> > Jarek
> >
> > On Fri, May 9, 2008 at 6:12 AM,  <[EMAIL PROTECTED]> wrote:
> >
> > > Author: jdillon
> > > Date: Fri May  9 03:12:49 2008
> > > New Revision: 654748
> > >
> > > URL: http://svn.apache.org/viewvc?rev=654748&view=rev
> > > Log:
> > > Fix up some more testsuite configuration
> > >
> > > Modified:
> > >
> geronimo/server/trunk/testsuite/console-testsuite/advanced/src/test/java/org/apache/geronimo/testsuite/console/WebServerTest.java
> > >
> geronimo/server/trunk/testsuite/deployment-testsuite/deployment-tests/pom.xml
> > >
> geronimo/server/trunk/testsuite/deployment-testsuite/jca-cms-tests/jca-cms-ear/pom.xml
> > >   geronimo/server/trunk/testsuite/deployment-testsuite/pom.xml
> > >   geronimo/server/trunk/testsuite/enterprise-testsuite/pom.xml
> > >   geronimo/server/trunk/testsuite/pom.xml
> > >   geronimo/server/trunk/testsuite/security-testsuite/pom.xml
> > >   geronimo/server/trunk/testsuite/web-testsuite/pom.xml
> > >   geronimo/server/trunk/testsuite/web-testsuite/test-2.1-jsps/pom.xml
> > >
> geronimo/server/trunk/testsuite/web-testsuite/test-2.5-servlets/pom.xml
> > >   geronimo/server/trunk/testsuite/web-testsuite/test-jetty/pom.xml
> > >   geronimo/server/trunk/testsuite/web-testsuite/test-myfaces/pom.xml
> > >   geronimo/server/trunk/testsuite/web-testsuite/test-tomcat/pom.xml
> > >
> geronimo/server/trunk/testsuite/web-testsuite/test-web-forward/web-forward-ear/pom.xml
> > >
> geronimo/server/trunk/testsuite/web-testsuite/test-web-references/web-references-ear/pom.xml
> > >   geronimo/server/trunk/testsuite/webservices-testsuite/pom.xml
> > >
> > > Modified: geronimo/server/trunk/testsuite/web-testsuite/pom.xml
> > > URL:
> http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/web-testsuite/pom.xml?rev=654748&r1=654747&r2=654748&view=diff
> > >
> ==
> > > --- geronimo/server/trunk/testsuite/web-testsuite/pom.xml (original)
> > > +++ geronimo/server/trunk/testsuite/web-testsuite/pom.xml Fri May  9
> 03:12:49 2008
> > > @@ -44,65 +44,8 @@
> > > - JSTL
> > >
> > >
> > > -
> > > -test-tomcat
> > > -
> > > -
> > >
> > > -
> > > -
> > > -
> > > -org.apache.maven.plugins
> > > -maven-surefire-plugin
> > > -
> > > -
> > > -
> ${project.build.testOutputDirectory}/testng.xml
> > > -
> > > -
> > > -
> > > -geronimoVersion
> > > -${version}
> > > -
> > > -
> > > -
> > > -
> > > -
> > > -
> > > -
> > >
> > > -
> > > -
> > >
> > >org.apache.geronimo.buildsupport
> > >testsuite-maven-plugin
> > >
> > >
> >
>
>

[BUILD] branches/2.1: Failed for Revision: 655822

Geronimo Revision: 655822 built with tests included
 
See the full build-0800.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/build-0800.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 31 minutes 22 seconds
[INFO] Finished at: Tue May 13 08:36:01 EDT 2008
[INFO] Final Memory: 306M/1000M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
 
Assembly: tomcat
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/logs-0800-tomcat/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 53.303 
sec <<< FAILURE!
 
Assembly: jetty
=
See the full test.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/logs-0800-jetty/test.log
 
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 13, Failures: 5, Errors: 0, Skipped: 0, Time elapsed: 61.633 
sec <<< FAILURE!
 
Samples: branches/2.1
=
Log: 
http://people.apache.org/builds/geronimo/server/binaries/2.1/20080513/samples-0800.log
 
Build status: FAILED

[jira] Resolved: (GERONIMO-4009) HTML errors and warnings in calculator-stateless-pojo sample .jsp file

2008-05-13 Thread Joe Bohn (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Bohn resolved GERONIMO-4009.


   Resolution: Fixed
Fix Version/s: (was: 2.1.x)
   2.2
   2.1.2

fixed in branches/2.1 (2.1.2) and trunk (2.2).   

> HTML errors and warnings in calculator-stateless-pojo sample .jsp file
> --
>
> Key: GERONIMO-4009
> URL: https://issues.apache.org/jira/browse/GERONIMO-4009
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1
>Reporter: Ted Kirby
>Assignee: Joe Bohn
> Fix For: 2.1.2, 2.2
>
> Attachments: G4009-calc-html.patch
>
>
> When I import this sample into eclipse, it runs HTML validation, and reports 
> 2 errors and lots of warnings.
> It seems it would be nice to minimize these, if not eliminate them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4011) Need private build of JLine to fix GShell problems on Windows

Need private build of JLine to fix GShell problems on Windows
-

 Key: GERONIMO-4011
 URL: https://issues.apache.org/jira/browse/GERONIMO-4011
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: dependencies
Affects Versions: 2.1.1, 2.1, 2.1.2, 2.2
Reporter: Donald Woods
Assignee: Donald Woods
 Fix For: 2.1.2, 2.2


There are several GShell problems on Windows, due to JLine bugs.
I'm going to try and create a patched build of JLine 0.9.94 to resolve these 
issues, as Geronimo packages the JLine jar into our assembly for GShell to use.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 655755