RE: SocketProtocolStressTest failing

2004-08-01 Thread Alan D. Cabrera
There will be logs in the test-reports.  Can you send me those as well?

> -Original Message-
> From: David Jencks [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 31, 2004 4:45 PM
> To: [EMAIL PROTECTED]
> Subject: SocketProtocolStressTest failing
> 
> I'm frequently seeing SocketProtocolStressTest failures
> 
> mac osx 10.3 1.5 ghz G4
> 
> Anything else I can supply to help?
> 
> thanks
> david jencks
> 
> Testsuite:
org.apache.geronimo.network.protocol.SocketProtocolStressTest
> Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 78.124 sec
> 
> - Standard Error -
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> org.apache.geronimo.network.protocol.ProtocolException: Send timeout.
>   at
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> col.java:245)
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> etProtocolStressTest.java:80)
> -  ---
> Testcase:
>
testConcurrentRequests(org.apache.geronimo.network.protocol.SocketProtoc
> olStressTest):FAILED
> expected:<100> but was:<65>
> junit.framework.AssertionFailedError: expected:<100> but was:<65>
>   at
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest.testConcur
> rentRequests(SocketProtocolStressTest.java:96)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
>   at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> 
> 




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




Thomas Ermesjo is out of the office.

2004-08-01 Thread Thomas . Ermesjo
I will be out of the office starting  18.07.2004 and will not return until
14.08.2004.

Thomas Ermesjo has left on vacation, and will be back 16. august.




org.openejb.mdb.BasicMDBContainerTest never returns

2004-08-01 Thread Alan D. Cabrera








The test org.openejb.mdb.BasicMDBContainerTest never returns.

 

 

Regards,

Alan

 

 








[jira] Updated: (GERONIMO-278) Servlet/JSP 2.3 DTD deployment descriptor support

2004-08-01 Thread dev
The following issue has been updated:

Updater: David Jencks (mailto:[EMAIL PROTECTED])
   Date: Sun, 1 Aug 2004 2:17 PM
Comment:
Servlet dtd is converted to 2.4 schema.  Haven't looked at jsp stuff yet.
Changes:
 Component changed to web
-
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/GERONIMO-278?page=history

-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-278

Here is an overview of the issue:
-
Key: GERONIMO-278
Summary: Servlet/JSP 2.3 DTD deployment descriptor support
   Type: New Feature

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 web
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Thu, 29 Jul 2004 5:53 PM
Updated: Sun, 1 Aug 2004 2:17 PM

Description:
Servlet/JSP 2.2 DTD deployment descriptor support


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-278) Servlet/JSP 2.3 DTD deployment descriptor support

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-278

Here is an overview of the issue:
-
Key: GERONIMO-278
Summary: Servlet/JSP 2.3 DTD deployment descriptor support
   Type: New Feature

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 web
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Thu, 29 Jul 2004 5:53 PM
Updated: Sun, 1 Aug 2004 2:15 PM

Description:
Servlet/JSP 2.2 DTD deployment descriptor support


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Commented: (GERONIMO-205) J2EE Connector support for JMS Providers

2004-08-01 Thread dev
The following comment has been added to this issue:

 Author: David Jencks
Created: Sun, 1 Aug 2004 2:15 PM
   Body:
there is some work in ActiveMQ in this direction but most likely a generic ASF 
based inbound adapter will have severe performance  problems compared to a 
customized adapter with knowledge of the JMS providers internals.
-
View this comment:
  http://issues.apache.org/jira/browse/GERONIMO-205?page=comments#action_36985

-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-205

Here is an overview of the issue:
-
Key: GERONIMO-205
Summary: J2EE Connector support for JMS Providers
   Type: Task

 Status: Unassigned
   Priority: Major

Project: Apache Geronimo
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: 
   Reporter: David Blevins

Created: Sun, 25 Apr 2004 7:18 PM
Updated: Sun, 1 Aug 2004 2:15 PM

Description:
No J2EE Connector (JSR 112) exists for deploying JMS Providers.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-206) Hot deployment of EJB, WAR, and RAR archives

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 2:11 PM

You can deploy all types of j2ee packages using the geronimo-maven-plugin.   
You can also start and stop a remote server, but waiting for it to start 
completely is a bit iffy.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-206

Here is an overview of the issue:
-
Key: GERONIMO-206
Summary: Hot deployment of EJB, WAR, and RAR archives
   Type: Task

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Sun, 25 Apr 2004 9:37 PM
Updated: Sun, 1 Aug 2004 2:11 PM

Description:
At current time it is not possible to deploy an ejb, war, or rar while the 
server is started.  Due to the read-only nature of Geronimo config-stores, 
deployment may only happen when the server is stopped.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-211) Servlet web.xml resource-ref support to JMS

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 2:09 PM

resource-ref is for connection factories.  resource-env-ref is the deprecated 
support for admin objects (queues/topics) and message-destination-ref is the 
non-deprecated support.  Both resource-env-ref and message-destination-ref are 
implemented.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-211

Here is an overview of the issue:
-
Key: GERONIMO-211
Summary: Servlet web.xml resource-ref support to JMS
   Type: Task

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 web
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Sun, 25 Apr 2004 10:04 PM
Updated: Sun, 1 Aug 2004 2:09 PM

Description:
Support for JMS Topics or Queues via the resource-ref element in the web.xml is 
not yet implemented.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-211) Servlet web.xml resource-ref support to JMS

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-211

Here is an overview of the issue:
-
Key: GERONIMO-211
Summary: Servlet web.xml resource-ref support to JMS
   Type: Task

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 web
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Sun, 25 Apr 2004 10:04 PM
Updated: Sun, 1 Aug 2004 2:08 PM

Description:
Support for JMS Topics or Queues via the resource-ref element in the web.xml is 
not yet implemented.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



RE: SocketProtocolStressTest failing

2004-08-01 Thread Alan D. Cabrera
The test controlProtocolTest has been fixed.  Can you confirm that this
has been fixed for you?

I am working on the SocketProtocolStressTest.


Regards,
Alan 

> -Original Message-
> From: anita kulshreshtha [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 01, 2004 7:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SocketProtocolStressTest failing
> 
> Hi alan, david
> I have never been able to build without deleting
> controlProtocolTest ( gives error) and
> SocketProtocolStressTest (sometime passes or hangs). I
> am using -
> windows 98 SE
> maven-1.0-rc1, maven-1.0
> java version "1.4.2_01"
> Java(TM) 2 Runtime Environment, Standard Edition
> (build 1.4.2_01-b06)
> Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed
> mode)
>  This issue was raised earlier issue-227.
> TIA
>   Anita
> 
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> 
> > I'm frequently seeing SocketProtocolStressTest
> > failures
> >
> > mac osx 10.3 1.5 ghz G4
> >
> > Anything else I can supply to help?
> >
> > thanks
> > david jencks
> >
> > Testsuite:
> >
> org.apache.geronimo.network.protocol.SocketProtocolStressTest
> > Tests run: 3, Failures: 1, Errors: 0, Time elapsed:
> > 78.124 sec
> >
> > - Standard Error -
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> >
> org.apache.geronimo.network.protocol.ProtocolException:
> > Send timeout.
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> >
> > col.java:245)
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> >
> > etProtocolStressTest.java:80)
> > -  ---
> > Testcase:
> >
>
testConcurrentRequests(org.apache.geronimo.network.protocol.SocketProtoc
> >
> > olStressTest):  FAILED
> > expected:<100> but was:<65>
> > junit.framework.AssertionFailedError: expected:<100>
> > but was:<65>
> > at
> >
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest.testConcur
> >
> > rentRequests(SocketProtocolStressTest.java:96)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invo

[jira] Commented: (GERONIMO-246) NullPointerException when omitting assembly-descriptor tag in ejb-jar.xml

2004-08-01 Thread dev
The following comment has been added to this issue:

 Author: David Jencks
Created: Sun, 1 Aug 2004 2:03 PM
   Body:
It wouldn't be too hard to remove the NPE, but the only way to configure 
transaction settings is in the assembly descriptor.  Can we use a default 
transaction policy if the assembly descriptor is missing?

or should we throw a DeploymentException?

-
View this comment:
  http://issues.apache.org/jira/browse/GERONIMO-246?page=comments#action_36982

-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-246

Here is an overview of the issue:
-
Key: GERONIMO-246
Summary: NullPointerException when omitting assembly-descriptor tag in 
ejb-jar.xml
   Type: Bug

 Status: Unassigned
   Priority: Major

Project: Apache Geronimo
 Components: 
 OpenEJB
   Versions:
 1.0-M1

   Assignee: 
   Reporter: Philip Mark Donaghy

Created: Wed, 16 Jun 2004 9:09 AM
Updated: Sun, 1 Aug 2004 2:03 PM
Environment: JVM Version 1.4.2_01-b06
JVM Vendor Sun Microsystems Inc.
OS Name Linux
OS Version 2.4.20-8
OS Architecture i386

Description:
The assembly-descriptor element in ejb-jar.xml deployment descriptors is 
optional, yet openejb requires it. Deployment without this tag causes a 
NullPointerException.

java.lang.NullPointerException
at 
org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:426)
at 
org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:141)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:740)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:110)
at 
org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9e45a280.addGBeans()
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:225)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:148)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:141)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:740)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:110)
at 
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$7a1ca0ae.buildConfiguration()
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:132)
at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:141)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:761)
at 
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205)
at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079)
at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231)
at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:82)


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
  

[jira] Closed: (GERONIMO-266) test-ejb-jar ejb-jar.xml doesn't validate

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:51 PM

The ejb 2.0 and ejb 2.1 schema expect different case.  I changed 
SchemaConversionUtils to lowercase the reentrant element contents.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-266

Here is an overview of the issue:
-
Key: GERONIMO-266
Summary: test-ejb-jar ejb-jar.xml doesn't validate
   Type: Bug

 Status: Closed
   Priority: Minor
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 OpenEJB
   Versions:
 1.0-M2

   Assignee: David Jencks
   Reporter: toby cabot

Created: Tue, 13 Jul 2004 10:28 AM
Updated: Sun, 1 Aug 2004 1:51 PM
Environment: fedora core 2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)


Description:
in my ongoing playing around with geronimo i tried to deploy 
modules/j2ee/target/test-ejb-jar.jar.  i'm not sure if this isn't something 
that i'm supposed to do, but in any case i got:

[EMAIL PROTECTED]:~/try/incubator-geronimo$ java -jar target/bin/deployer.jar 
--install --module modules/j2ee/target/test-ejb-jar.jar
org.apache.geronimo.deployment.DeploymentException: Unable to parse ejb-jar.xml
at 
org.openejb.deployment.OpenEJBModuleBuilder.installModule(OpenEJBModuleBuilder.java:271)
at 
org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:744)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:111)
at 
org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9e45a280.installModule()
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:258)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:197)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:744)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:111)
at 
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$7a1ca0ae.buildConfiguration()
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:181)
at 
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:767)
at 
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205)
at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079)
at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231)
at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:82)
Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: 
[error: Invalid value for boolean: False, error: Boolean (False) does not match 
pattern for true-falseType i

[jira] Assigned: (GERONIMO-266) test-ejb-jar ejb-jar.xml doesn't validate

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-266

Here is an overview of the issue:
-
Key: GERONIMO-266
Summary: test-ejb-jar ejb-jar.xml doesn't validate
   Type: Bug

 Status: Open
   Priority: Minor

Project: Apache Geronimo
 Components: 
 OpenEJB
   Versions:
 1.0-M2

   Assignee: David Jencks
   Reporter: toby cabot

Created: Tue, 13 Jul 2004 10:28 AM
Updated: Sun, 1 Aug 2004 1:50 PM
Environment: fedora core 2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)


Description:
in my ongoing playing around with geronimo i tried to deploy 
modules/j2ee/target/test-ejb-jar.jar.  i'm not sure if this isn't something 
that i'm supposed to do, but in any case i got:

[EMAIL PROTECTED]:~/try/incubator-geronimo$ java -jar target/bin/deployer.jar 
--install --module modules/j2ee/target/test-ejb-jar.jar
org.apache.geronimo.deployment.DeploymentException: Unable to parse ejb-jar.xml
at 
org.openejb.deployment.OpenEJBModuleBuilder.installModule(OpenEJBModuleBuilder.java:271)
at 
org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:744)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:111)
at 
org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$9e45a280.installModule()
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:258)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:197)
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:744)
at org.apache.geronimo.gbean.jmx.RawInvoker.invoke(RawInvoker.java:89)
at 
org.apache.geronimo.gbean.jmx.RawOperationInvoker.invoke(RawOperationInvoker.java:34)
at 
org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:111)
at 
org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$7a1ca0ae.buildConfiguration()
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:181)
at 
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87)
at 
org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:767)
at 
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
at 
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205)
at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079)
at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231)
at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:82)
Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: 
[error: Invalid value for boolean: False, error: Boolean (False) does not match 
pattern for true-falseType in namespace http://java.sun.com/xml/ns/j2ee, error: 
Invalid value for boolean: False, error: Boolean (False) does not match pattern 
for true-falseType in name

[jira] Assigned: (GERONIMO-141) [PATCH] XMLParserConfiguration with grammar-pool for LoaderUtil

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-141

Here is an overview of the issue:
-
Key: GERONIMO-141
Summary: [PATCH] XMLParserConfiguration with grammar-pool for LoaderUtil
   Type: Improvement

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 core

   Assignee: David Jencks
   Reporter: Kristian Koehler

Created: Sun, 11 Jan 2004 6:40 AM
Updated: Sun, 1 Aug 2004 1:45 PM

Description:
Hi

this patch adds a XMLParserConfiguration object to the LoaderUtil (as proposed 
by David). It is configured to use a grammar pool which is not enabled in the 
standard configuration. The grammar pool caches previous used grammars and 
reduces lookups via the entityresolver.

The XMLParserConfiguration is registered as GeronimoMBean and exposes methods 
for get/set properties and features.

The AbstractLoaderUtilTest is adjusted accordingly.

Kristian


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-148) [PATCH] Schema corrections for geronimo xsds

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:44 PM

The geronimo schemas have evolved quite a bit since this patch, and AFAIK are 
accepted by xmlbeans which seems to have considerably stronger schema 
validation features than xerces.  If there are remaining problems please open a 
new issue.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-148

Here is an overview of the issue:
-
Key: GERONIMO-148
Summary: [PATCH] Schema corrections for geronimo xsds
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 core
   Fix Fors:
 1.0-M2

   Assignee: David Jencks
   Reporter: Kristian Koehler

Created: Mon, 19 Jan 2004 7:01 AM
Updated: Sun, 1 Aug 2004 1:44 PM

Description:
Hi 

the geronimo schemas are not valid. This patch resolves this issue and adds a 
corresponding test to the core module.

Most problems arise from namespace errors and are now corrected.

The TestCase (GrammarTest) just reads the grammar files and validates them 
internally. A simple EntityResolver is included in the test which searches all 
grammars needed in the schema directory of the core module (for example: 
datatypes.dtd, XMLSchema.dtd,...).  So the test doesn't need a remote 
connection for these dtds. 

The geronimo-web-app.xsd file is not included in this patch and is still 
invalid. IMHO this should be resolved as soon as possible. ;-)


Steffen and Kristian


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-148) [PATCH] Schema corrections for geronimo xsds

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-148

Here is an overview of the issue:
-
Key: GERONIMO-148
Summary: [PATCH] Schema corrections for geronimo xsds
   Type: Improvement

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 core

   Assignee: David Jencks
   Reporter: Kristian Koehler

Created: Mon, 19 Jan 2004 7:01 AM
Updated: Sun, 1 Aug 2004 1:43 PM

Description:
Hi 

the geronimo schemas are not valid. This patch resolves this issue and adds a 
corresponding test to the core module.

Most problems arise from namespace errors and are now corrected.

The TestCase (GrammarTest) just reads the grammar files and validates them 
internally. A simple EntityResolver is included in the test which searches all 
grammars needed in the schema directory of the core module (for example: 
datatypes.dtd, XMLSchema.dtd,...).  So the test doesn't need a remote 
connection for these dtds. 

The geronimo-web-app.xsd file is not included in this patch and is still 
invalid. IMHO this should be resolved as soon as possible. ;-)


Steffen and Kristian


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-245) OutOfMemoryError while running ConnectionManagerStressTest

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:36 PM

I have never had this problem and I haven't heard of anyone else having it.  If 
you are still having it you may need to provide more clues or investigate it 
yourself.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-245

Here is an overview of the issue:
-
Key: GERONIMO-245
Summary: OutOfMemoryError while running ConnectionManagerStressTest
   Type: Task

 Status: Closed
   Priority: Minor
 Resolution: CANNOT REPRODUCE

Project: Apache Geronimo
 Components: 
 buildsystem
 connector
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M2

   Assignee: David Jencks
   Reporter: Ralf Barkow

Created: Sat, 12 Jun 2004 2:44 PM
Updated: Sun, 1 Aug 2004 1:36 PM
Environment: Windows 2000 Prof DE (5.00.2195) SP4, Java 1.4.2_04-b05, maven 
1.0-rc2
AMD-K6(tm) 3D processor with 384 MB RAM

Description:
Building the current 1.0-SNAPSHOT on my 'thin-chested' Win2kProf DE box with 
java v1.4.2_04-b05, there's now an OutOfMemoryError while running the 
connector.outbound.ConnectionManagerStressTest.  Okay, 384 MB RAM isn't that 
much, but obviously no problem if I run this test in Eclipse3M8. Everything's 
green there -- test(s) passed.  

Setting MAVEN_OPTS=-Xmx didn't help.  I tried 512m and -- probably 
more realistic -- 256M, which I also use in the comand line arguments for 
Eclipse.  

Workaround: I build -- successfully btw -- with 
"maven -Dmaven.test.failure.ignore=true" 
for now.

Is this a maven bug (v. 1.0-rc2) ?  Or a problem with the installed JREs?  
Eclipse runs under/uses AppServer-jdk-1.4.2_04-b04, which is JAVA_HOME also, 
vs. j2re-1.4.2_04-b05 in WINNT/system32/ and programs, which seems to be 
launched by maven, shells, etc.  

Any ideas?
--  
/rgb


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-245) OutOfMemoryError while running ConnectionManagerStressTest

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-245

Here is an overview of the issue:
-
Key: GERONIMO-245
Summary: OutOfMemoryError while running ConnectionManagerStressTest
   Type: Task

 Status: Open
   Priority: Minor

Project: Apache Geronimo
 Components: 
 buildsystem
 connector
   Versions:
 1.0-M2

   Assignee: David Jencks
   Reporter: Ralf Barkow

Created: Sat, 12 Jun 2004 2:44 PM
Updated: Sun, 1 Aug 2004 1:35 PM
Environment: Windows 2000 Prof DE (5.00.2195) SP4, Java 1.4.2_04-b05, maven 
1.0-rc2
AMD-K6(tm) 3D processor with 384 MB RAM

Description:
Building the current 1.0-SNAPSHOT on my 'thin-chested' Win2kProf DE box with 
java v1.4.2_04-b05, there's now an OutOfMemoryError while running the 
connector.outbound.ConnectionManagerStressTest.  Okay, 384 MB RAM isn't that 
much, but obviously no problem if I run this test in Eclipse3M8. Everything's 
green there -- test(s) passed.  

Setting MAVEN_OPTS=-Xmx didn't help.  I tried 512m and -- probably 
more realistic -- 256M, which I also use in the comand line arguments for 
Eclipse.  

Workaround: I build -- successfully btw -- with 
"maven -Dmaven.test.failure.ignore=true" 
for now.

Is this a maven bug (v. 1.0-rc2) ?  Or a problem with the installed JREs?  
Eclipse runs under/uses AppServer-jdk-1.4.2_04-b04, which is JAVA_HOME also, 
vs. j2re-1.4.2_04-b05 in WINNT/system32/ and programs, which seems to be 
launched by maven, shells, etc.  

Any ideas?
--  
/rgb


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-268) Connection Error handling problems

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-268

Here is an overview of the issue:
-
Key: GERONIMO-268
Summary: Connection Error handling problems
   Type: Bug

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 connector
   Versions:
 1.0-M2

   Assignee: David Jencks
   Reporter: David Jencks

Created: Sun, 18 Jul 2004 4:07 PM
Updated: Sun, 1 Aug 2004 1:34 PM

Description:
A managed connection that encounters a fatal error and calls 
ConnectionErrorOccured on the GeronimoConnectionEventListener may not have the 
resources held by geronimo cleaned up properly.

In particular, if several ejbs have handles to this mc, the connection tracking 
won't work properly.  Only the currently active component (ejb) will have it's 
handle(s) removed from tracking.  When the other handles are disociated or 
closed, errors are likely, such as putting the destroyed managed connection 
back into the pool.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-146) Resolving entities against local repository doesn't work

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:32 PM

Build and deployment now works offline.  We aren't using any entity resolvers 
ourselves.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-146

Here is an overview of the issue:
-
Key: GERONIMO-146
Summary: Resolving entities against local repository doesn't work
   Type: Bug

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 deployment

   Assignee: David Jencks
   Reporter: Jacek Laskowski

Created: Fri, 16 Jan 2004 7:36 AM
Updated: Sun, 1 Aug 2004 1:32 PM

Description:
Hi,

Now, Geronimo is not able to resolve entities against local repository, thus 
XMLs are not validated while being offline. It happened because of malformed 
arguments to java.io.File constructor (there're URLs not OS-dependent file 
paths).


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-161) LocalXAResourceInsertionInterceptor could use XAResource implementation

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:30 PM

No reply to my arguments
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-161

Here is an overview of the issue:
-
Key: GERONIMO-161
Summary: LocalXAResourceInsertionInterceptor could use XAResource 
implementation
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 core

   Assignee: David Jencks
   Reporter: hamilton verissimo

Created: Tue, 6 Apr 2004 8:37 AM
Updated: Sun, 1 Aug 2004 1:30 PM

Description:
LocalXAResourceInsertionInterceptor could use XAResource from ManagedConnection 
instead of always build a wrapper to a XAResource delegating to 
LocalTransaction.

Follows the patch.

Index: LocalXAResourceInsertionInterceptor.java
===
RCS file: 
/home/cvspublic/incubator-geronimo/modules/connector/src/java/org/apache/geronimo/connector/outbound/LocalXAResourceInsertionInterceptor.java,v
retrieving revision 1.3
diff -u -r1.3 LocalXAResourceInsertionInterceptor.java
--- LocalXAResourceInsertionInterceptor.java10 Mar 2004 09:58:32 -  
1.3
+++ LocalXAResourceInsertionInterceptor.java6 Apr 2004 15:33:54 -
@@ -18,6 +18,7 @@
 package org.apache.geronimo.connector.outbound;
 
 import javax.resource.ResourceException;
+import javax.transaction.xa.XAResource;
 
 /**
  * LocalXAResourceInsertionInterceptor.java
@@ -37,7 +38,20 @@
 
 public void getConnection(ConnectionInfo connectionInfo) throws 
ResourceException {
 next.getConnection(connectionInfo);
+
+
 ManagedConnectionInfo mci = connectionInfo.getManagedConnectionInfo();
+
+   try
+   {
+   XAResource resource = 
mci.getManagedConnection().getXAResource();
+   mci.setXAResource( resource );
+   return;
+   }
+   catch(Exception ignores)
+   {
+   }
+
 mci.setXAResource(
 new LocalXAResource(
 mci.getManagedConnection().getLocalTransaction()));



-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-133) [PATCH] LocalEntity Resolver and LoaderUtil Enhancements

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:29 PM

I'm closing this because I think we have all the schemas available via an 
entity resolver gbean and we are not using any of this stuff ourselves, we use 
exclusively xmlbeans.  If there are further problems please reopen or open a 
new more specific issue.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-133

Here is an overview of the issue:
-
Key: GERONIMO-133
Summary: [PATCH] LocalEntity Resolver and LoaderUtil Enhancements
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 core

   Assignee: David Jencks
   Reporter: Kristian Koehler

Created: Fri, 26 Dec 2003 10:21 AM
Updated: Sun, 1 Aug 2004 1:29 PM

Description:
Hi

this is a patch for the LocalEntity Resolver and LoaderUtil Classes. 

Why i think this patch should be applied:

* There were some complaints about working or developing offline with Apache 
Geronimo. Most problems arises from remote resolving of entities. 
If someone develops a piece a code which requires some external DTDs or Schemas 
it may work for him because we works online. The "new" Implementation offers a 
flag indicating if the resolver may return null or throw an exception. 
Returning null is a signal to the parser to open a regular URI connection to 
the given system identifier. 
With this flag it's possible to disable all remote lookups and prevent 
different online/offline behaviour.

* Validating of DTDs and Schema.
The current Implementation of the LoaderUtil doesn't validate schema and DTDs 
and there is no ErrorHandler to report the failures.
The "new" LoaderUtil ueses a DOMParser Implementation which supports DTD and 
Schema validation. (ok it's a Xerces feature - if someone knows how to use this 
the "standard way" please let me know. ;-) )

* The current EntityResolver is implemented as MBean. The LoaderUtil class 
which uses the LocalEntityResolver instantiates the EntityResolver every time 
rather then using it over the JMX bus.
You may add new Mappings to the LocalEntityResolver but they will never be 
used. 
The "new" LoaderUtil Implementation uses the LocalEntity Resolver over JMX.

* The current LocalEntity Resolver uses a property file for mapping a PublicID 
to a SystemID. 
This approach is useful but doesn't work. Property files must not contain 
spaces in there key values. 

Example:
-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN=c:/work/dummy/web.dtd

is not a valid entry.

  OASIS has published a Catalog standard to define such mappings. 
  (see http://www.oasis-open.org/specs/a401.htm)
  Apache provides an appropriate Java library.
  (http://xml.apache.org/commons/components/resolver/index.html)

The "new" LocalEntiotyResolver uses this catalog standard to determine the 
PublicID/SystemID mappings.

* There are new Unit Tests which tests the functionality of the
  LocalEntityResolver.
  I have adjusted the other tests accordingly.

How the LocalEntityResolver works:

First of all the Resolver is registered as MBean
(geronimo.xml:role=EntityResolver). It is configured with:
* CatalogFile (OASIS Catalog file)
* LocalRepository (local directory where to lookup dtd and schema)
* FailOnUnresolvable

When resolving an entity the resolver first checks the catalog file to 
determine a PublicID or SystemID mapping. If there is now mapping configured 
the Resolver tries to resolve via a local directory where dtd and schema files 
are present(LocalRepository). If no dtd or schema is found a lookup into the 
classpath is done. If nothing is found the FailOnUnresolvable signals if an 
exception should be thrown.

Kristian


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-131) Remove nullification of DD's locations when the standard DD doesn't exist

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:24 PM

There is now completely different code looking for the deployment descriptors, 
and it tries to generate a default geronimo dd if none is supplied (except for 
ra, where it doesn't make sense IMO).
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-131

Here is an overview of the issue:
-
Key: GERONIMO-131
Summary: Remove nullification of DD's locations when the standard DD 
doesn't exist
   Type: Improvement

 Status: Closed
   Priority: Minor
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 deployment

   Assignee: David Jencks
   Reporter: Jacek Laskowski

Created: Sun, 14 Dec 2003 5:03 PM
Updated: Sun, 1 Aug 2004 1:24 PM

Description:
I spent the whole weekend to eventually find out that Geronimo deploys a 
deployment unit only when it contains *two* required files: one that's mandated 
by the appropriate spec and the other one - Geronimo-specific. So, when a EJB 
bean is deployed two files must exist - /META-INF/ejb-jar.xml and 
/META-INF/geronimo-ejb-jar.xml, otherwise it won't be deployed at all (and 
unfortunatelly no message is printed out about it on the console). What caused 
me to think about having only one? Just take a look at 
org.openejb.nova.deployment.EJBModuleDeploymentPlanner that checks whether 
geronimo-ejb-jar.xml exists and also a few lines below is the comment: 
"currently everything is in the geronimo-ejb-jar.xml". 

However, o.a.g.kernel.deployment.DeploymentHelper always returns null upon 
being asked about standard or geronimo DD when the standard DD is not available 
(see one of the constructor). Therefore, DeploymentHelper decides if a module 
is deployable or not. I think it is not in charge of giving the answer. The 
right of answering the question belongs to a planner, thus the change.

I also change a bit the class's javadoc. 


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-263) Can'e deploy bare jars with old DD

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:22 PM

No complaints so I think this is fixed
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-263

Here is an overview of the issue:
-
Key: GERONIMO-263
Summary: Can'e deploy bare jars with old DD
   Type: Bug

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 web
   Fix Fors:
 1.0-M2
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: Jeremy Boynes

Created: Sat, 10 Jul 2004 8:30 PM
Updated: Sun, 1 Aug 2004 1:22 PM

Description:
Trying to deploy a war with a Servlet 2.3 DD gives

org.apache.xmlbeans.XmlException: error: The document is not a [EMAIL 
PROTECTED]://ja
va.sun.com/xml/ns/j2ee: document element namespace mismatch expected "http://jav
a.sun.com/xml/ns/j2ee" got ""
at org.apache.xmlbeans.impl.store.Root.verifyDocumentType(Root.java:542)

at org.apache.xmlbeans.impl.store.Root.autoTypedDocument(Root.java:458)
at org.apache.xmlbeans.impl.store.Root.loadXml(Root.java:1079)
at org.apache.xmlbeans.impl.store.Root.loadXml(Root.java:1063)
at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaType
LoaderBase.java:360)
at org.apache.geronimo.common.xml.XmlBeansUtil.parse(XmlBeansUtil.java:6
2)
at org.apache.geronimo.common.xml.XmlBeansUtil.getXmlObject(XmlBeansUtil
.java:47)
at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createDefault
Plan(JettyModuleBuilder.java:121)


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Closed: (GERONIMO-280) J2EE Application 1.3 deployment descriptor support

2004-08-01 Thread dev
Message:

   The following issue has been closed.

   Resolver: David Jencks
   Date: Sun, 1 Aug 2004 1:20 PM

Implemented, with a few tests.  In addition, application 1.4 dds are now 
validated.
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-280

Here is an overview of the issue:
-
Key: GERONIMO-280
Summary: J2EE Application 1.3 deployment descriptor support
   Type: New Feature

 Status: Closed
   Priority: Major
 Resolution: FIXED

Project: Apache Geronimo
 Components: 
 deployment
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Thu, 29 Jul 2004 5:57 PM
Updated: Sun, 1 Aug 2004 1:20 PM

Description:
J2EE Application 1.3 deployment descriptor support


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



[jira] Assigned: (GERONIMO-280) J2EE Application 1.3 deployment descriptor support

2004-08-01 Thread dev
Message:

   The following issue has been re-assigned.

   Assignee: David Jencks (mailto:[EMAIL PROTECTED])
-
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-280

Here is an overview of the issue:
-
Key: GERONIMO-280
Summary: J2EE Application 1.3 deployment descriptor support
   Type: New Feature

 Status: Open
   Priority: Major

Project: Apache Geronimo
 Components: 
 deployment
   Versions:
 1.0-M1

   Assignee: David Jencks
   Reporter: David Blevins

Created: Thu, 29 Jul 2004 5:57 PM
Updated: Sun, 1 Aug 2004 1:19 PM

Description:
J2EE Application 1.3 deployment descriptor support


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



Re: Is 'False' (as reentrant value) valid?

2004-08-01 Thread Jeremy Boynes
Believe it or not the valid values changed between EJB2.0 and EJB2.1 - 
in 2.0 you needed True/False and in 2.1 you need true/false

If you changed the DD version, then you will need to change the values 
to match. If you are trying to deploy a jar with a 2.0 DTD doctype, then 
I'd say we have a bug in the schema validaton.

--
Jeremy
Jacek Laskowski wrote:
Hi,
Just came accross a question I can't answer myself.
According to the EJB 2.1 spec:


The BluePrint PetStore application does use False as stated in the spec.
However, according to http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd:
  

  
This simple type designates a boolean with only two
permissible values
- true
- false
  


  

  

  
So, as I'm reading it correctly, the only valid values are true and 
false in lowercase.

Of course, XMLBeans complains during deployment and it looks like it's 
right.

Is False valid?
Best,
Jacek



Re: SocketProtocolStressTest failing

2004-08-01 Thread anita kulshreshtha
Hi alan, david
I have never been able to build without deleting
controlProtocolTest ( gives error) and
SocketProtocolStressTest (sometime passes or hangs). I
am using - 
windows 98 SE
maven-1.0-rc1, maven-1.0
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed
mode)
 This issue was raised earlier issue-227.
TIA
  Anita
   
--- David Jencks <[EMAIL PROTECTED]> wrote:

> I'm frequently seeing SocketProtocolStressTest
> failures
> 
> mac osx 10.3 1.5 ghz G4
> 
> Anything else I can supply to help?
> 
> thanks
> david jencks
> 
> Testsuite:
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest
> Tests run: 3, Failures: 1, Errors: 0, Time elapsed:
> 78.124 sec
> 
> - Standard Error -
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
>
org.apache.geronimo.network.protocol.ProtocolException:
> Send timeout.
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocol.sendDown(SocketProto
> 
> col.java:245)
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest$1.run(Sock
> 
> etProtocolStressTest.java:80)
> -  ---
> Testcase:  
>
testConcurrentRequests(org.apache.geronimo.network.protocol.SocketProtoc
> 
> olStressTest):FAILED
> expected:<100> but was:<65>
> junit.framework.AssertionFailedError: expected:<100>
> but was:<65>
>   at  
>
org.apache.geronimo.network.protocol.SocketProtocolStressTest.testConcur
> 
> rentRequests(SocketProtocolStressTest.java:96)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>   at  
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> 
> a:39)
>   at  
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> 
> Impl.java:25)
> 
> 
> 



__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


[status] build: SUCCESSFUL, test: SUCCESSFUL | Linux 2.4.26, 2004-08-01

2004-08-01 Thread dblevins
NIGHTLY BUILD/TEST
  Date: Sun Aug  1 05:30:36 EDT 2004
  Kernel: Linux 2.4.26
  Host: beaver.codehaus.org
  Java: 1.4.2_04-b05, mixed mode
  Maven: 1.0

CHECKOUT: incubator-geronimo

BUILDING: incubator-geronimo

BUILD SUCCESSFUL
Total time: 17 minutes 57 seconds
Finished at: Sun Aug 01 05:49:50 EDT 2004