Re: [JBoss-dev] JBossAS releases - 3.2.8 & 4.0.4RC1

[Bill Burke]

Great job everyone!

Ruel Loehr wrote:
Two versions of JBossAS were released today.   The released versions 
include JBossAS 3.2.8 and JBossAS 4.0.4RC1.


 


These releases can be downloaded from the following location:

 

http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942 



 

 


Thank you,

Ruel Loehr

JBoss QA

 

 



--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Accepted: [JBoss-dev] Maven2 discussion

[Ryan Campbell]

BEGIN:VCALENDAR
METHOD:REPLY
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-06.00) Central Time (US & Canada)
X-MICROSOFT-CDO-TZID:11
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060207T001658Z
DTSTART;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T09
SUMMARY:Accepted: [JBoss-dev] Maven2 discussion
UID:04008200E00074C5B7101A82E008905F2284492BC601000
 010007AD3E23387F0E54BBDA4311EDA6FC1FC
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;CN="Ryan Campbell
 ":MAILTO:[EMAIL PROTECTED]
ORGANIZER:MAILTO:jboss-development@lists.sourceforge.net
LOCATION:virtual
DTEND;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T10
SEQUENCE:0
PRIORITY:5
CLASS:
CREATED:20060208T025433Z
LAST-MODIFIED:20060208T025433Z
STATUS:TENTATIVE
TRANSP:OPAQUE
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-CDO-REPLYTIME:20060208T025411Z
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-OWNERAPPTID:889595862
END:VEVENT
END:VCALENDAR

[JBoss-dev] Maven2 discussion

[Ruel Loehr]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-06.00) Central Time (US & Canada)
X-MICROSOFT-CDO-TZID:11
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060207T001658Z
DTSTART;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T09
SUMMARY:Maven2 discussion
UID:04008200E00074C5B7101A82E008905F2284492BC601000
 010007AD3E23387F0E54BBDA4311EDA6FC1FC
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="jboss-dev
 [EMAIL PROTECTED]":MAILTO:[EMAIL PROTECTED]
 .net
ORGANIZER;CN="Ruel Loehr":MAILTO:[EMAIL PROTECTED]
LOCATION:virtual
DTEND;TZID="(GMT-06.00) Central Time (US & Canada)":20060208T10
DESCRIPTION:A discussion of the Maven2 build system and how it can apply to
  JBoss. \N\N\NTopic: Maven discussion \NDate: Wednesday\, February 8\, 200
 6 \NTime: 7:00 am\, Pacific Standard Time (GMT -08:00\, San Jose) \NEvent 
 Number: 755427172	\NEvent Entrance for Attendees: https://jboss.webex.com/
 jboss/onstage/g.php?d=755427172&t=a\NPassword: opensource\N\NMeeting numbe
 r: 484 275 352 \N\N> Conference Passcodes:\N>Passcode:   966849\N>
  \N> \N> Conference Access:\N>Local - Australia\, Melbourne:+6
 1 (0)3 8623 7219\N>Local - Australia\, Sydney:   +61 (0)2 8223
  9401\N>Local - Austria\, Vienna: +43 (0)1 7957 6007\N>   
  Local - Belgium\, Brussels:   +32 (0)2 700 1640\N>Local - Cze
 ch Republic\, Prague:  +420 239 000 284\N>Local - Denmark\, Copenh
 agen: +45 38 32 29 51\N>Local - Finland\, Helsinki:   
 +358 (0)9 6937 9698\N>Local - France\, Lyon:+33 (0)4 2
 6 69 04 16\N>Local - France\, Marseille:   +33 (0)4 88 13 13 0
 5\N>Local - France\, Paris:   +33 (0)1 71 23 02 79\N>L
 ocal - Germany\, Berlin: +49 (0)30 9929 6972\N>Local - Ger
 many\, Cologne:+49 (0)221 9758 9998\N>Local - Germany\, Du
 sseldorf: +49 (0)211 5476 9996\N>Local - Germany\, Frankfurt: 
  +49 (0)69 5098 5534\N>Local - Germany\, Hamburg:+
 49 (0)40 5379 9210\N>Local - Germany\, Hanover:+49 (0)511 
 9997 1020\N>Local - Germany\, Munich: +49 (0)89 2170 4820\
 N>Local - Germany\, Stuttgart:  +49 (0)711 9959 8040\N>Loc
 al - Hong Kong\, Hong Kong:+852 3002 1689\N>Local - Hungary\, 
 Budapest:   +36 1777 4756\N>Local - Ireland\, Dublin: 
 +353 (0)1 659 2852\N>Local - Italy\, Milan:+39 026
  968 2868\N>Local - Italy\, Rome: +39 066 605 3191\N> 
Local - Japan\, Tokyo:+81 (0)3 3570 8582\N>Local - 
 Luxembourg\, Luxembourg:  +352 342 080 8287\N>Local - Malaysia\, K
 uala Lumpur:  +60 (0)3 7712 4446\N>Local - Netherlands\, Amsterdam
 :  +31 (0)20 201 5007\N>Local - New Zealand\, Auckland:   +64 
 9 920 0625\N>Local - Norway\, Oslo:+47 2316 2909\N>   
  Local - Poland\, Warsaw:  +48 (0)22 702 05 20\N>Local - P
 ortugal\, Lisbon:+351 2141 59084\N>Local - Singapore\, Sin
 gapore:+65 6415 5094\N>Local - South Korea\, Seoul:  +
 82 23 483 1057\N>Local - Spain\, Madrid:   +34 91 270 2696
 \N>Local - Sweden\, Stockholm:   +46 (0)8 5876 9413\N>Loca
 l - Switzerland\, Geneva: +41 (0)22 417 7097\N>Local - Switzer
 land\, Zurich: +41 (0)1 800 9618\N>Local - UK\, Birmingham:   
+44 (0)12 1233 2646\N>Local - UK\, Bristol:
  +44 (0)11 7927 9471\N>Local - UK\, Edinburgh:   +44 (0)13
  1313 4770\N>Local - UK\, Glasgow: +44 (0)14 1332 8495
 \N>Local - UK\, London:  +44 (0)20 7365 0762\N>Loc
 al - UK\, Manchester:  +44 (0)16 1834 3031\N>Local - UK\, 
 Reading: +44 (0)11 8959 7412\N>Local - USA\, New York:
1 718 354 1201\N>Freephone - Argentina:   0
 800 666 1753\N>Freephone - Australia:   1800 118 603\N>   
  Freephone - Austria: 0800 295 001\N>Freephone - Bahra
 in: 800 04071\N>Freephone - Belgium: 0
 800 80959\N>Freephone - Brazil:  0800 891 7905\N>F
 reephone - Chile:   123 0020 6048\N>Freephone - China\
 , Northern Region:  10800 852 1093\N>Freephone - China\, Southern Regi
 on:  10800 152 1092\N>Freephone - Columbia:01800 9448 
 028\N>Freephone - Cyprus:  8009 1

[JBoss-dev] JBossAS releases - 3.2.8 & 4.0.4RC1

[Ruel Loehr]

Two versions of JBossAS were released today.   The released
versions include JBossAS 3.2.8 and JBossAS 4.0.4RC1.

 

These releases can be downloaded from the following
location:

 

http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942

 

 

Thank you,

Ruel Loehr

JBoss QA

 

 

[JBoss-dev] jboss-4.0-compatibility-matrix Build Failed

[qa]

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-compatibility-matrix?log=log20060207174433
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:228: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:189: Exit code: 1   See tests.log in Build Artifacts for details.Date of build: 02/07/2006 17:44:33Time to build: 14 minutes 44 seconds




    Unit Tests: (0)    Total Errors and Failures: (0) 
 Modifications since last build: (first 50 of 0)

[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors

[qa]

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060207151724
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/07/2006 15:17:24Time to build: 71 minutes 55 secondsLast changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup.




    Unit Tests: (283)    Total Errors and Failures: (2)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization) 
 Modifications since last build: (first 50 of 2031)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-253 - changed to use coyote connector by default instead of http server invoker.  Also adding many fixes so now only ssl related http tests are failing within the tests suite.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/.truststoreJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.2modifiedtelrodsrc/tests/org/jbo

[JBoss-dev] cannot obtain read lock ...for cvsroot/jbpm/

[Max Rydahl Andersen]

anyone who knows the resolution for this one ?

  An error occurred synchronizing /org.jbpm.ui.test: The server reported  
an error while performing the "cvs status" command.

The server reported an error while performing the "cvs status" command.
  org.jbpm.ui.test: cvs status: failed to create lock directory for  
`/cvsroot/jbpm/jbpm.ide/org.jbpm.ui.test'  
(/cvsroot/jbpm/jbpm.ide/org.jbpm.ui.test/#cvs.lock): Permission denied
  org.jbpm.ui.test: cvs status: failed to obtain dir lock in  
repository `/cvsroot/jbpm/jbpm.ide/org.jbpm.ui.test'

  org.jbpm.ui.test: cvs [status aborted]: read lock failed - giving up


--
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
[EMAIL PROTECTED]
http://hibernate.org

JBoss Inc
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Re: [Hibernate] Do antlr exception leak to users?

[Max Rydahl Andersen]

On Tue, 07 Feb 2006 20:55:52 +0100, Scott M Stark <[EMAIL PROTECTED]>  
wrote:



fixing the antlr exception svuid won't help us if the client
is using an older version, right ?


It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version is still serializable
compatible.


which it isn't afaik. the antlr version started to include more data in  
the exception over time.



calling printStackTrace() on every exception sounds overkill
for me...and will turn basic logging into something very verbose.


Should be no different from now as logging generally includes the cause.


well, for me that is showing the exception message in a dialog in the ui I  
would be very

disappointed to have a full stack trace in the message output.


I understand the issue, but don't find the suggested
solutions any good ;(

Would be nice to have an option to have any exposed remote
exception do the serialization of the "cause".
Would make it a non-issue where it actually matters.


This can't be done without modifying the exception either via source or
bytecode manipulation.


And bytecode manipulation or simple modification of the exception in the  
jboss serialization/remoting layer

have that option, correct ?


--
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
[EMAIL PROTECTED]
http://hibernate.org

JBoss Inc
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?

[Scott M Stark]

> fixing the antlr exception svuid won't help us if the client 
> is using an older version, right ?
> 
It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version is still serializable
compatible.

> calling printStackTrace() on every exception sounds overkill 
> for me...and will turn basic logging into something very verbose.
> 
Should be no different from now as logging generally includes the cause.

> I understand the issue, but don't find the suggested 
> solutions any good ;(
> 
> Would be nice to have an option to have any exposed remote 
> exception do the serialization of the "cause".
> Would make it a non-issue where it actually matters.
> 
This can't be done without modifying the exception either via source or
bytecode manipulation.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Re: [Hibernate] Do antlr exception leak to users?

[Max Rydahl Andersen]

fixing the antlr exception svuid won't help us if the client is using
an older version, right ?

calling printStackTrace() on every exception sounds overkill for me...and
will turn basic logging into something very verbose.

I understand the issue, but don't find the suggested solutions any good ;(

Would be nice to have an option to have any exposed remote exception do  
the serialization of the "cause".

Would make it a non-issue where it actually matters.

/max



The problem is the source of the cause not providing a stable api for
the exception, not the inclusion of the cause itself. The solution is to
fix the antlr exceptions to specify the serialVersionUID to avoid
trivial changes showing up as version incompatibilities.

You can always work around this by explicitly incorporating the cause
into the exception message string:

try
{
...
}
catch(Exception e)
{
   StringWriter sw = new StringWriter();
   PrintWriter pw = new PrintWriter();
   pw.println("... cause:");
   e.printStackTrace(pw);
   pw.close();
   String msg = sw.toString();
   throw new Xception(msg);
}



-Original Message-
From: Max Andersen
Sent: Tuesday, February 07, 2006 10:34 AM
To: Scott M Stark; jboss-development@lists.sourceforge.net;
Hibernate development
Subject: Re: [Hibernate] Do antlr exception leak to users?

On Tue, 07 Feb 2006 19:24:38 +0100, Scott M Stark
<[EMAIL PROTECTED]>
wrote:

> I'm a little concerned that this will lead to unnecessary
coupling of
> client and server versions of antlr then. How often does an antlr
> exception as a cause show up in practise as an exception seen by an
> external client?

hmm..whenever a syntax error occur in a HQL/EJBQL statement.

But how else can we provide the cause of an exception ?
This is a pretty critical part of debugging hibernate applications.
Not just for antlr exceptions, but jdbc driver exceptions,
sqlexceptions and any other external "cause".

/max





--
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
[EMAIL PROTECTED]
http://hibernate.org

JBoss Inc
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] RE: [Hibernate] Release naming conventions

[Scott M Stark]

I added a Practices and Jar Manifest Headers section to the
JBossProductVersioning page to discuss issues such as how nightly builds
could be versioned. The headers section still needs to be completed.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Scott M Stark
> Sent: Tuesday, February 07, 2006 10:22 AM
> To: Max Andersen; Christian Bauer; development Hibernate; 
> [EMAIL PROTECTED]
> Cc: jboss-development@lists.sourceforge.net
> Subject: RE: [Hibernate] Release naming conventions
> 
> Any place the version is actually used. This is the manifest 
> headers (these should also be spelled out and standardized 
> including the osgi conventions for projects that need to 
> comply with these headers), the repository 
> component-info.xml, and the project build files. Really only 
> the project build file should be where a project makes 
> version changes and this should just propagated to artifacts 
> based on the build tools. 


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?

[Scott M Stark]

The problem is the source of the cause not providing a stable api for
the exception, not the inclusion of the cause itself. The solution is to
fix the antlr exceptions to specify the serialVersionUID to avoid
trivial changes showing up as version incompatibilities.

You can always work around this by explicitly incorporating the cause
into the exception message string:

try
{
...
}
catch(Exception e)
{
   StringWriter sw = new StringWriter();
   PrintWriter pw = new PrintWriter();
   pw.println("... cause:");
   e.printStackTrace(pw);
   pw.close();
   String msg = sw.toString();
   throw new Xception(msg);
}


> -Original Message-
> From: Max Andersen 
> Sent: Tuesday, February 07, 2006 10:34 AM
> To: Scott M Stark; jboss-development@lists.sourceforge.net; 
> Hibernate development
> Subject: Re: [Hibernate] Do antlr exception leak to users?
> 
> On Tue, 07 Feb 2006 19:24:38 +0100, Scott M Stark 
> <[EMAIL PROTECTED]>
> wrote:
> 
> > I'm a little concerned that this will lead to unnecessary 
> coupling of 
> > client and server versions of antlr then. How often does an antlr 
> > exception as a cause show up in practise as an exception seen by an 
> > external client?
> 
> hmm..whenever a syntax error occur in a HQL/EJBQL statement.
> 
> But how else can we provide the cause of an exception ?
> This is a pretty critical part of debugging hibernate applications.
> Not just for antlr exceptions, but jdbc driver exceptions, 
> sqlexceptions and any other external "cause".
> 
> /max
> 


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors

[qa]

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060207130330
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/07/2006 13:03:30Time to build: 39 minutes 24 secondsLast changed: 12/28/2005 10:48:11Last log entry: Add the 1.2.4SP1 changelog notes.




    Unit Tests: (1349)    Total Errors and Failures: (46)testorg.jboss.cache.ConcurrentEvictAndRemoveTesttestCircularAndSharedReferencesorg.jboss.cache.aop.ObjectGraphAopTesttestCircularAndSharedReferencesorg.jboss.cache.aop.ReplicatedObjectGraphAopTesttestSimplifiedorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.PropagationManagerlAopTesttestSimplifiedorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestPropagationorg.jboss.cache.aop.integrated.ReplicatedPropagationManagerlAopTesttestIsReachableorg.jboss.cache.aop.util.ObjectUtilAopTesttestDataSourceIntegrationorg.jboss.cache.loader.DataSourceIntegrationTesttestCollectionWithCacheLoaderorg.jboss.cache.aop.loader.FileCacheLoaderAopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer1241AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer124AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer130AopTestwarningorg.jboss.cache.benchmark.support.BaseTestwarningorg.jboss.cache.benchmark.support.Read50PercentTestwarningorg.jboss.cache.benchmark.support.Read75PercentTestwarningorg.jboss.cache.benchmark.support.Read90PercentTestwarningorg.jboss.cache.benchmark.tests.HashMapRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead90JRunitTesttestUpdateEvictionorg.jboss.cache.eviction.AopLRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.FIFOPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LFUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.MRUPolicyTesttestOptSyncReplorg.jboss.cache.loader.CacheLoaderWithReplicationTesttest2ReadersAnd1Writerorg.jboss.cache.lock.ReentrantWriterPreferenceReadWriteLockTestwarningorg.jboss.cache.optimistic.LocalCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticTestwarningorg.jboss.cache.optimistic.LocalTesttestConcurrentUseAsyncorg.jboss.cache.statetransfer.StateTransfer1241TesttestConcurrentAccessWithRWLockorg.jboss.cache.transaction.ConcurrentTransactionalTesttestNodeCreationRollbackorg.jboss.cache.transaction.IsolationLevelReadCommittedTest 
 Modifications since last build: (first 50 of 1566)1.3modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaFixes rating to JBCACHE-118 - optimising cache loader functionality.1.2modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.1addedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.2modifieddhuangtests/stress/org/jboss/cache/EvictionLocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.2modifieddhuangtests/stress/org/jboss/cache/LocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Evict

[JBoss-dev] Re: [Hibernate] Do antlr exception leak to users?

[Max Rydahl Andersen]

On Tue, 07 Feb 2006 19:24:38 +0100, Scott M Stark <[EMAIL PROTECTED]>  
wrote:



I'm a little concerned that this will lead to unnecessary coupling of
client and server versions of antlr then. How often does an antlr
exception as a cause show up in practise as an exception seen by an
external client?


hmm..whenever a syntax error occur in a HQL/EJBQL statement.

But how else can we provide the cause of an exception ?
This is a pretty critical part of debugging hibernate applications.
Not just for antlr exceptions, but jdbc driver exceptions, sqlexceptions  
and

any other external "cause".

/max




-Original Message-
From: Max Andersen
Sent: Monday, February 06, 2006 11:53 AM
To: Scott M Stark; jboss-development@lists.sourceforge.net;
Hibernate development
Subject: Re: [Hibernate] Do antlr exception leak to users?

On Mon, 06 Feb 2006 20:49:08 +0100, Scott M Stark
<[EMAIL PROTECTED]>
wrote:

> I'm seeing some incompatible serial version uid changes in
the latest
> antlr, but I don't know if antlr exceptions every leak to users
> outside of the vm such that this is an issue. Do the ql grammar
> exception get exposed or are they always converted to a
hibernate exception?

it is always converted, but of course it can be inside as a
cause exception.

/max




--
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
[EMAIL PROTECTED]
http://hibernate.org

JBoss Inc
[EMAIL PROTECTED]


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] RE: [Hibernate] Do antlr exception leak to users?

[Scott M Stark]

I'm a little concerned that this will lead to unnecessary coupling of
client and server versions of antlr then. How often does an antlr
exception as a cause show up in practise as an exception seen by an
external client?

> -Original Message-
> From: Max Andersen 
> Sent: Monday, February 06, 2006 11:53 AM
> To: Scott M Stark; jboss-development@lists.sourceforge.net; 
> Hibernate development
> Subject: Re: [Hibernate] Do antlr exception leak to users?
> 
> On Mon, 06 Feb 2006 20:49:08 +0100, Scott M Stark 
> <[EMAIL PROTECTED]>
> wrote:
> 
> > I'm seeing some incompatible serial version uid changes in 
> the latest 
> > antlr, but I don't know if antlr exceptions every leak to users 
> > outside of the vm such that this is an issue. Do the ql grammar 
> > exception get exposed or are they always converted to a 
> hibernate exception?
> 
> it is always converted, but of course it can be inside as a 
> cause exception.
> 
> /max


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] RE: [Hibernate] Release naming conventions

[Scott M Stark]

Any place the version is actually used. This is the manifest headers
(these should also be spelled out and standardized including the osgi
conventions for projects that need to comply with these headers), the
repository component-info.xml, and the project build files. Really only
the project build file should be where a project makes version changes
and this should just propagated to artifacts based on the build tools. 

> -Original Message-
> From: Max Andersen 
> Sent: Tuesday, February 07, 2006 10:14 AM
> To: Scott M Stark; Christian Bauer; development Hibernate; 
> [EMAIL PROTECTED]
> Subject: Re: [Hibernate] Release naming conventions
> 
> 
> so where do you want the name applied ?
> 
> in the eclipse plugins it make sense for the jar's since that 
> is the part being used to identify it + the 
> plugin.xml/MANIFEST.MF osgi version part.
> 
> /max
> 
> > This has nothing to do with the actual jar names. The 
> version in the 
> > jar name is a poor convention as it propagates the version to users 
> > unnecessarily, and is not verifiable via a signed manifest. 
> The jars 
> > checked into the repository should not have any explicit version 
> > information in the name. I don't care what naming 
> conventions are used 
> > by projects elsewhere.
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Max 
> >> Rydahl Andersen
> >> Sent: Tuesday, February 07, 2006 10:01 AM
> >> To: Christian Bauer; development Hibernate; 
> >> [EMAIL PROTECTED]
> >> Subject: Re: [Hibernate] Release naming conventions
> >>
> >> >>
> >> >> I'm not a big fan of all minor releases needing to append
> >> '.ga' (i.e.
> >> >> 3.1.3.ga.jar).  I really wish there was a way to define 
> ordering 
> >> >> amongst "qualifiers".
> >> >
> >> > AFAIK these conventions are for package names and not 
> necessarily 
> >> > library names?
> >>
> >> it's the version branded into the application - meaning what goes 
> >> into MANIFEST.MF and distribution name; for me it would 
> make sense to 
> >> have that on the jar file too...
> >>
> >> And yes, would be great with an "ordering" that said 3.1.3 
> is "newer" 
> >> than 3.1.3.alpha, 3.1.3.beta..but what is 3.1.3.2 then ?
> >>
> >> p.s. i'm planning on following this in the eclipse plugins 
> too since 
> >> it actually is very usefull there to have the update manager 
> >> functionallity work together with alpha/beta/etc.
> >>
> >> /max
> >>
> >> >
> >> > ---
> >> > This SF.net email is sponsored by: Splunk Inc. Do you grep
> >> through log
> >> > files for problems?  Stop!  Download the new AJAX search
> >> engine that
> >> > makes searching your log files as easy as surfing the  web.
> >>  DOWNLOAD
> >> > SPLUNK!
> >> >
> >> 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121
> >> 6
> >> > 42 ___
> >> > hibernate-devel mailing list
> >> > hibernate-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >>
> >>
> >>
> >> --
> >> --
> >> Max Rydahl Andersen
> >> callto://max.rydahl.andersen
> >>
> >> Hibernate
> >> [EMAIL PROTECTED]
> >> http://hibernate.org
> >>
> >> JBoss Inc
> >> [EMAIL PROTECTED]
> >>
> >>
> >> ---
> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
> >> log files for problems?  Stop!  Download the new AJAX 
> search engine 
> >> that makes searching your log files as easy as surfing the  web.  
> >> DOWNLOAD SPLUNK!
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&;
> >> dat=121642
> >> ___
> >> hibernate-devel mailing list
> >> hibernate-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >>
> 
> 
> 
> --
> --
> Max Rydahl Andersen
> callto://max.rydahl.andersen
> 
> Hibernate
> [EMAIL PROTECTED]
> http://hibernate.org
> 
> JBoss Inc
> [EMAIL PROTECTED]
> 


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] JBossProductVersioning update

[Scott M Stark]

It cannot be resolved as a version in between a Beta and GA release
using the osgi bundle version comparision as discussed in this thread.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Bill Burke
> Sent: Tuesday, February 07, 2006 9:20 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] JBossProductVersioning update
> 
> Any reason we can't keep the RC instead of switching to CR?  
> They mean the same and we've been using RC for, what, years?


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] JBossProductVersioning update

[Bill Burke]

Any reason we can't keep the RC instead of switching to CR?  They mean 
the same and we've been using RC for, what, years?


Scott M Stark wrote:

I have not seen any outcry over the version convention thread so I have
updated the product version page to summarize the conclusion reached.
Getting projects aligned to this convention is something all leads need
to work on.

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning
 


Scott Stark
VP Architecture & Technology
JBoss Inc.
 
 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development



--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] JBossProductVersioning update

[Scott M Stark]

I have not seen any outcry over the version convention thread so I have
updated the product version page to summarize the conclusion reached.
Getting projects aligned to this convention is something all leads need
to work on.

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning
 

Scott Stark
VP Architecture & Technology
JBoss Inc.
 
 


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development