You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas R. <tho...@tr...> - 2005-10-02 20:57:57
|
On Oct 2, 2005, at 4:43 PM, Juergen Hoeller wrote:
>
> So our OracleLobHandler works on the new "oracle.jdbc.Connection"
> interface,
> while WebSphere seems to return an "oracle.jdbc.driver.Connection"
> that's
> not assignable to the "oracle.jdbc.Connection" interface.
The class we test for is:
private static final String CONNECTION_CLASS_NAME =
"oracle.jdbc.OracleConnection";
In my tests any Oracle connection is assignable to this class as long
as they both come from the same classloader.
Seems like the test is the problem here - maybe we should just test
for a class name that starts with "oracle.jdbc"
Thomas
|
|
From: Thomas R. <tho...@tr...> - 2005-10-02 20:50:49
|
Must be a classloader issue. Just tested by forcing a different classloader for the connection and the connectionClass that is used to test assignability - it returns false with different classloader. Maybe the context classloader pick up a different class on its path. Thomas On Oct 2, 2005, at 4:11 PM, Thomas Risberg wrote: > I think the oracle.jdbc.driver.OracleConnection extends > oracle.jdbc.OracleConnection so they should both work. The > connection I get back from 10g is oracle.jdbc.driver.T4CConnection > and it is assignable as well. Could this be a class loader issue? > > Thomas > > > On Oct 2, 2005, at 3:20 PM, Duncan Mills wrote: > > >> Juergen, >> There has been some refactoring in the Oracle JDBC drivers (as of >> the 10g version) so the correct class is now >> oracle.jdbc.Connection. oracle.jdbc.driver.Connection is >> deprecated but should still be supported until version 11 of the >> database. >> I'm not sure if that's the cause of the problem here but it's >> probably more than coincidental.. >> Duncan >> >> Juergen Hoeller wrote: >> >> >> >>> We have a report about an issue with Spring's OracleLobHandler on >>> WebSphere >>> 6.0: >>> http://opensource2.atlassian.com/projects/spring/browse/SPR-1317 >>> >>> Our WebSphereNativeJdbcExtractor seems to work, actually. It's >>> rather that >>> WebSphere returns an object of class "oracle.jdbc.Connection" as >>> underlying >>> connection there, not an "oracle.jdbc.driver.Connection" - as >>> expected by >>> our OracleLobHandler, according to the Oracle 9i+ JDBC API. >>> >>> Could this be caused by a different Oracle driver that WebSphere >>> uses, at >>> least in that specific scenario? Maybe it uses an older Oracle >>> driver that >>> doesn't support the "oracle.jdbc.driver" package yet? Has anybody >>> ever >>> encountered this, no matter whether on WebSphere or not? >>> >>> It would be great if someone with access to a WebSphere 6.0 + Oracle >>> installation could give this a try and see whether there's a way >>> to solve >>> the issue... >>> >>> Juergen >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: >>> Power Architecture Resource Center: Free content, downloads, >>> discussions, >>> and more. http://solutions.newsforge.com/ibmarch.tmpl >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >>> >>> >> >> -- >> >> Regards >> >> Duncan Mills >> Senior Principal Product Manager >> Oracle Application Development Tools >> >> Dun...@or... >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework- >> developer >> >> >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > |
|
From: Juergen H. <ju...@in...> - 2005-10-02 20:44:14
|
Actually, I mixed up the class names in my original mail: WebSphere returns an object of class "oracle.jdbc.driver.Connection" as underlying connection there, not an "oracle.jdbc.Connection" as expected by our OracleLobHandler. So our OracleLobHandler works on the new "oracle.jdbc.Connection" interface, while WebSphere seems to return an "oracle.jdbc.driver.Connection" that's not assignable to the "oracle.jdbc.Connection" interface. This could indeed be a class loader issue: if the local "oracle.jdbc.Connection" interface has been loaded by a different class loader than the Connection handle returned by WebSphere... In principle, we could also relax the Connection type check in OracleLobHandler, as the Connection handle is just passed on via reflection anyway. That check is really just there to be able to throw a nice exception. But even if we relaxed that check, I guess we'd still run into a class loader issue: I'd expect the Oracle CLOB.createTemporary call to result in an internal ClassCastException within the driver implementation in this case... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Thomas Risberg Sent: Sunday, October 02, 2005 10:12 PM To: spr...@li... Subject: Re: [Springframework-developer] OracleLobHandler on WebSphere 6.0 I think the oracle.jdbc.driver.OracleConnection extends oracle.jdbc.OracleConnection so they should both work. The connection I get back from 10g is oracle.jdbc.driver.T4CConnection and it is assignable as well. Could this be a class loader issue? Thomas On Oct 2, 2005, at 3:20 PM, Duncan Mills wrote: > Juergen, > There has been some refactoring in the Oracle JDBC drivers (as of the > 10g version) so the correct class is now oracle.jdbc.Connection. > oracle.jdbc.driver.Connection is deprecated but should still be > supported until version 11 of the database. > I'm not sure if that's the cause of the problem here but it's probably > more than coincidental.. > Duncan > > Juergen Hoeller wrote: > > >> We have a report about an issue with Spring's OracleLobHandler on >> WebSphere >> 6.0: >> http://opensource2.atlassian.com/projects/spring/browse/SPR-1317 >> >> Our WebSphereNativeJdbcExtractor seems to work, actually. It's rather >> that WebSphere returns an object of class "oracle.jdbc.Connection" as >> underlying connection there, not an "oracle.jdbc.driver.Connection" - >> as expected by our OracleLobHandler, according to the Oracle 9i+ JDBC >> API. >> >> Could this be caused by a different Oracle driver that WebSphere >> uses, at least in that specific scenario? Maybe it uses an older >> Oracle driver that doesn't support the "oracle.jdbc.driver" package >> yet? Has anybody ever encountered this, no matter whether on >> WebSphere or not? >> >> It would be great if someone with access to a WebSphere 6.0 + Oracle >> installation could give this a try and see whether there's a way to >> solve the issue... >> >> Juergen >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework- >> developer >> >> > > -- > > Regards > > Duncan Mills > Senior Principal Product Manager > Oracle Application Development Tools > > Dun...@or... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Mark St G. <stg...@ca...> - 2005-10-02 20:41:36
|
I am running Webpshere 6, with Hibernate 3, Spring 1.2.5 and Oracle 10g....
I also get back a: oracle.jdbc.driver.T4CConnection
assertTrue(oracle.jdbc.OracleConnection.class.isAssignableFrom(conn.getClass()));
assertTrue(oracle.jdbc.driver.OracleConnection.class.isAssignableFrom(conn.getClass()));
And it looks to be assignable...
Cheers
Mark
Thomas Risberg
<thomas.risberg@t
ridb.com> To
Sent by: spr...@li...
springframework-d rceforge.net
eveloper-admin@li cc
sts.sourceforge.n
et Subject
Re: [Springframework-developer]
OracleLobHandler on WebSphere 6.0
10/02/2005 03:11
PM
Please respond to
springframework-d
eveloper
I think the oracle.jdbc.driver.OracleConnection extends
oracle.jdbc.OracleConnection so they should both work. The
connection I get back from 10g is oracle.jdbc.driver.T4CConnection
and it is assignable as well. Could this be a class loader issue?
Thomas
On Oct 2, 2005, at 3:20 PM, Duncan Mills wrote:
> Juergen,
> There has been some refactoring in the Oracle JDBC drivers (as of
> the 10g version) so the correct class is now
> oracle.jdbc.Connection. oracle.jdbc.driver.Connection is deprecated
> but should still be supported until version 11 of the database.
> I'm not sure if that's the cause of the problem here but it's
> probably more than coincidental..
> Duncan
>
> Juergen Hoeller wrote:
>
>
>> We have a report about an issue with Spring's OracleLobHandler on
>> WebSphere
>> 6.0:
>> http://opensource2.atlassian.com/projects/spring/browse/SPR-1317
>>
>> Our WebSphereNativeJdbcExtractor seems to work, actually. It's
>> rather that
>> WebSphere returns an object of class "oracle.jdbc.Connection" as
>> underlying
>> connection there, not an "oracle.jdbc.driver.Connection" - as
>> expected by
>> our OracleLobHandler, according to the Oracle 9i+ JDBC API.
>>
>> Could this be caused by a different Oracle driver that WebSphere
>> uses, at
>> least in that specific scenario? Maybe it uses an older Oracle
>> driver that
>> doesn't support the "oracle.jdbc.driver" package yet? Has anybody
>> ever
>> encountered this, no matter whether on WebSphere or not?
>>
>> It would be great if someone with access to a WebSphere 6.0 + Oracle
>> installation could give this a try and see whether there's a way
>> to solve
>> the issue...
>>
>> Juergen
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads,
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>
> --
>
> Regards
>
> Duncan Mills
> Senior Principal Product Manager
> Oracle Application Development Tools
>
> Dun...@or...
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Thomas R. <tho...@tr...> - 2005-10-02 20:11:06
|
I think the oracle.jdbc.driver.OracleConnection extends oracle.jdbc.OracleConnection so they should both work. The connection I get back from 10g is oracle.jdbc.driver.T4CConnection and it is assignable as well. Could this be a class loader issue? Thomas On Oct 2, 2005, at 3:20 PM, Duncan Mills wrote: > Juergen, > There has been some refactoring in the Oracle JDBC drivers (as of > the 10g version) so the correct class is now > oracle.jdbc.Connection. oracle.jdbc.driver.Connection is deprecated > but should still be supported until version 11 of the database. > I'm not sure if that's the cause of the problem here but it's > probably more than coincidental.. > Duncan > > Juergen Hoeller wrote: > > >> We have a report about an issue with Spring's OracleLobHandler on >> WebSphere >> 6.0: >> http://opensource2.atlassian.com/projects/spring/browse/SPR-1317 >> >> Our WebSphereNativeJdbcExtractor seems to work, actually. It's >> rather that >> WebSphere returns an object of class "oracle.jdbc.Connection" as >> underlying >> connection there, not an "oracle.jdbc.driver.Connection" - as >> expected by >> our OracleLobHandler, according to the Oracle 9i+ JDBC API. >> >> Could this be caused by a different Oracle driver that WebSphere >> uses, at >> least in that specific scenario? Maybe it uses an older Oracle >> driver that >> doesn't support the "oracle.jdbc.driver" package yet? Has anybody >> ever >> encountered this, no matter whether on WebSphere or not? >> >> It would be great if someone with access to a WebSphere 6.0 + Oracle >> installation could give this a try and see whether there's a way >> to solve >> the issue... >> >> Juergen >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework- >> developer >> >> > > -- > > Regards > > Duncan Mills > Senior Principal Product Manager > Oracle Application Development Tools > > Dun...@or... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > |
|
From: Duncan M. <dun...@or...> - 2005-10-02 19:20:38
|
Juergen, There has been some refactoring in the Oracle JDBC drivers (as of the 10g version) so the correct class is now oracle.jdbc.Connection. oracle.jdbc.driver.Connection is deprecated but should still be supported until version 11 of the database. I'm not sure if that's the cause of the problem here but it's probably more than coincidental.. Duncan Juergen Hoeller wrote: >We have a report about an issue with Spring's OracleLobHandler on WebSphere >6.0: >http://opensource2.atlassian.com/projects/spring/browse/SPR-1317 > >Our WebSphereNativeJdbcExtractor seems to work, actually. It's rather that >WebSphere returns an object of class "oracle.jdbc.Connection" as underlying >connection there, not an "oracle.jdbc.driver.Connection" - as expected by >our OracleLobHandler, according to the Oracle 9i+ JDBC API. > >Could this be caused by a different Oracle driver that WebSphere uses, at >least in that specific scenario? Maybe it uses an older Oracle driver that >doesn't support the "oracle.jdbc.driver" package yet? Has anybody ever >encountered this, no matter whether on WebSphere or not? > >It would be great if someone with access to a WebSphere 6.0 + Oracle >installation could give this a try and see whether there's a way to solve >the issue... > >Juergen > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions, >and more. http://solutions.newsforge.com/ibmarch.tmpl >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Regards Duncan Mills Senior Principal Product Manager Oracle Application Development Tools Dun...@or... |
|
From: Juergen H. <ju...@in...> - 2005-10-02 19:11:26
|
We have a report about an issue with Spring's OracleLobHandler on WebSphere 6.0: http://opensource2.atlassian.com/projects/spring/browse/SPR-1317 Our WebSphereNativeJdbcExtractor seems to work, actually. It's rather that WebSphere returns an object of class "oracle.jdbc.Connection" as underlying connection there, not an "oracle.jdbc.driver.Connection" - as expected by our OracleLobHandler, according to the Oracle 9i+ JDBC API. Could this be caused by a different Oracle driver that WebSphere uses, at least in that specific scenario? Maybe it uses an older Oracle driver that doesn't support the "oracle.jdbc.driver" package yet? Has anybody ever encountered this, no matter whether on WebSphere or not? It would be great if someone with access to a WebSphere 6.0 + Oracle installation could give this a try and see whether there's a way to solve the issue... Juergen |
|
From: <al...@in...> - 2005-09-29 22:34:34
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050930001629Lbuild.348 |
|
From: Alexandru P. <the...@gm...> - 2005-09-29 07:32:26
|
#: Seth Ladd changed the world a bit at a time by saying on 9/28/2005 8:24 AM :# > All, > > Would it be possible to go in there and fix up the JmsInvokerTests in > sandbox/test? It hasn't been able to compile for a long time. > > Not a big deal, just a minor blemish. > > Thanks, > Seth > > Hey glad somebody is talking about it! I think it is in that state from 1.2.3 :-). ./alex -- .the_mindstorm. > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Christoph M. <chr...@ch...> - 2005-09-29 04:04:08
|
I will be out of the office starting 29.09.2005 and will not return until 17.10.2005. |
|
From: Seth L. <set...@gm...> - 2005-09-29 00:42:43
|
Hi Thomas, On 9/28/05, Thomas Risberg <tho...@tr...> wrote: > Seth, > > For Clover reports go to Luke Taylor's site: > > http://www.monkeymachine.co.uk/spring/clover/index.html Thanks, that's exactly what I was looking for! Seth |
|
From: Darren D. <da...@da...> - 2005-09-29 00:26:55
|
On Wed, Sep 28, 2005 at 02:01:38PM -1000, Seth Ladd wrote: > Thanks for the tip. I was aware of that page, but never found the > clover reports. It would be really nice to link to those after every > build. Also, the JUnit HTML reports might be useful as well. Looks like Luke is still running them: http://www.monkeymachine.co.uk/spring/clover/index.html Forgot about this earlier - don't know how often they get updated though. Cheers! --=20 Darren Davison Public Key: 0xDD356B0D |
|
From: Thomas R. <tho...@tr...> - 2005-09-29 00:17:58
|
Seth, For Clover reports go to Luke Taylor's site: http://www.monkeymachine.co.uk/spring/clover/index.html Thomas On Sep 28, 2005, at 8:01 PM, Seth Ladd wrote: > Hi Darren, > > >> the continuous build page (http://springframework.sourceforge.net/ >> test/) >> has results from the half dozen or so machines that constantly >> build and >> run the test suite. >> >> Doesn't publish the junit reports, but you can click on the "failed" >> icon for a machine to see the last few lines of the ant output. >> > > Thanks for the tip. I was aware of that page, but never found the > clover reports. It would be really nice to link to those after every > build. Also, the JUnit HTML reports might be useful as well. > > Seth > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > |
|
From: Seth L. <set...@gm...> - 2005-09-29 00:01:47
|
Hi Darren, > the continuous build page (http://springframework.sourceforge.net/test/) > has results from the half dozen or so machines that constantly build and > run the test suite. > > Doesn't publish the junit reports, but you can click on the "failed" > icon for a machine to see the last few lines of the ant output. Thanks for the tip. I was aware of that page, but never found the clover reports. It would be really nice to link to those after every build. Also, the JUnit HTML reports might be useful as well. Seth |
|
From: Darren D. <da...@da...> - 2005-09-28 15:52:48
|
On Tue, 2005-09-27 at 22:41 -1000, Seth Ladd wrote: > Hello, >=20 > Are the clover reports from the test runs online anywhere? Speaking > of, are the unit test reports online anywhere? >=20 > Thanks very much, > Seth the continuous build page (http://springframework.sourceforge.net/test/) has results from the half dozen or so machines that constantly build and run the test suite. Doesn't publish the junit reports, but you can click on the "failed" icon for a machine to see the last few lines of the ant output. Plenty of failures to choose from at the moment :) D. --=20 Darren Davison Public Key: 0xDD356B0D |
|
From: Seth L. <set...@gm...> - 2005-09-28 08:42:01
|
Hello, Are the clover reports from the test runs online anywhere? Speaking of, are the unit test reports online anywhere? Thanks very much, Seth |
|
From: Seth L. <set...@gm...> - 2005-09-28 06:24:10
|
All, Would it be possible to go in there and fix up the JmsInvokerTests in sandbox/test? It hasn't been able to compile for a long time. Not a big deal, just a minor blemish. Thanks, Seth |
|
From: Rob B. <cro...@ya...> - 2005-09-27 23:08:58
|
Excellent!
Thank you.
Rob
--- Juergen Hoeller <ju...@in...> wrote:
> Actually, if you define two different
> implementations as lazy-init="true",
> including all beans that they depend on, you will
> only actually instantiate
> the beans that you explicitly refer to. If you have
> a placeholder a la <ref
> bean="${myTarget}"/>, only the actually referenced
> target bean and its
> dependencies will get instantiated.
>
> See the LobHandler definitions in our Image Database
> sample application for
> an example: The lazy-init flags there avoid to
> instantiate OracleLobHandler
> unless it is actually referenced by the DAO. That
> reference is expressed
> using a placeholder, so the actual choice can be
> driven by a properties
> file.
>
> If such lazy initialization becomes common in your
> bean definition file,
> consider setting default-lazy-init="true" at the
> <beans> level, only
> selectively turning off the lazy-init flag for
> specific beans that you want
> to have eagerly instantiated at startup.
>
> Juergen
>
>
> -----Original Message-----
> From:
>
spr...@li...
>
[mailto:spr...@li...]
> On Behalf Of
> Rob Butler
> Sent: Saturday, September 24, 2005 4:32 AM
> To: spr...@li...
> Subject: [Springframework-developer] Conditional
> configuration
>
> Hey all,
>
> I was wondering if Spring could be enhanced to
> support "conditional
> configuration" or if there is a way to do this
> already that I haven't
> thought of.
>
> Let's say your app has a property file bean post
> processor. Depending upon
> a setting in the property file you want to switch
> between two different
> implementations of some interface - Impl1 & Impl2.
> No problem, Spring does
> this easily.
>
> But let's say those two different implementations
> also have a number of
> Spring managed beans injected into them. So if your
> using Impl2 then all
> the Spring managed beans that are injected into
> Impl1 aren't needed.
>
> Is there a way to have spring _not_ instatiate and
> configure some beans
> depending upon a value obtained from a bean post
> processor?
>
> If this doesn't already exit perhaps a new attribute
> can be added to the
> bean tag like "load" or "configure". If load="true"
> then the bean is
> loaded.
> In this way Impl1 could be keyed to
> load="${useImpl1}"
> and so could all of the Spring managed beans that
> would be injected into it.
> Thus, if useImpl1 was false Impl1 and all the
> objects constructed to support
> it would never be instantiated.
>
> It would also be preferable for references to bean
> post processor values
> that used in un-instantiated objects to no longer be
> necessary. I.E. if
> Impl1 has someSetter="${someProperty}" and Impl1
> load="false"
> then spring should not error if "someProperty" is
> not provided.
>
> Thoughts?
>
> Rob
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
>
>
-------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's
> Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv
> or your very own
> Sony(tm)PSP. Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
-------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's
> Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv
> or your very own
> Sony(tm)PSP. Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: <al...@in...> - 2005-09-27 22:40:56
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050928002043Lbuild.347 |
|
From: Eugene K. <eu...@md...> - 2005-09-27 17:51:05
|
Folks, I've implemented a sax-based parser for Spring's XML bean definition and wonder if you'd be interested to integrate this into Spring framework. this class can be used in place of the current DOM-based parser as well as an lightweight adapter for runtime app context generators such as xslt-based tools or tools like Jacn (even so I believe Jacn should directly generate Spring factories without intermediate XML representation). I run all existing tests from xml package and they all seem working just fine. That however required to have copies of XmlBeanDefinitionReaderand and XmlBeanFactory patched to work with my parser. In my tests this parser is little bit faster then current DOM-based parser and in my opinion it is structured little better then DOM-based parser. Basically is is sort-of stripped-down Digester (stack-based state machine) with declarative definitions for parsing rules. Interestingly the same rules could be used with StAX-based parser with very minimal changes or even without changes using adapter for SAX Attributes instance used in rule params. Also note that current XmlBeanDefinitionReader class is tight to DOM-based API and does not allow to hookup abstract XML parsers (e.g. SAX or StAX). This make impossible to substiture custom non-DOM XML parser to XmlBeanFactory. regards, Eugene |
|
From: Darren D. <da...@sh...> - 2005-09-27 14:18:08
|
1127830681
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,065 sec
[junit] Testcase: testEquals took 0,02 sec
[junit] Testcase: testForCodeFound took 0,023 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0,001 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,292 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,292 sec
[junit] Testcase: testByteArrayResource took 0,006 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,005 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0 sec
[junit] Testcase: testClassPathResource took 0,016 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,013 sec
[junit] Testcase: testClassPathResourceWithClass took 0,012 sec
[junit] Testcase: testFileSystemResource took 0,003 sec
[junit] Testcase: testUrlResource took 0,01 sec
[junit] Testcase: testServletContextResource took 0,052 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0,001 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0,001 sec
[junit] Testcase: testNonFileResourceExists took 0,143 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Darren D. <da...@sh...> - 2005-09-27 12:18:01
|
1127823479
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,071 sec
[junit] Testcase: testEquals took 0,026 sec
[junit] Testcase: testForCodeFound took 0,025 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0,001 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,424 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,424 sec
[junit] Testcase: testByteArrayResource took 0,006 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,006 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0 sec
[junit] Testcase: testClassPathResource took 0,014 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,01 sec
[junit] Testcase: testClassPathResourceWithClass took 0,01 sec
[junit] Testcase: testFileSystemResource took 0,002 sec
[junit] Testcase: testUrlResource took 0,002 sec
[junit] Testcase: testServletContextResource took 0,051 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0,001 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0 sec
[junit] Testcase: testNonFileResourceExists took 0,291 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: <l.d...@gm...> - 2005-09-27 12:04:53
|
I did not invest much time in Google-ing around to find an answer, but mos=
t
of my findings were concerning something called "generics medicines" and
"until spring".
I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
I don't quite grasp the idea there, but I think there 'might/should' be a
way to generalize a bean's class in the context, something saying what
classes is the generic specialized for.
I have seen questions here as to what use would it be...
Well... Let's say we have a generic base DAO interface:
public interface BaseDao<T> {
public T load(Long ID);
public Long save(T);
public void update(T);
public void delete(T);
}
So we have our services depend on BaseDAO<SpecificType>
public class MyServiceImpl implements MyService {
// We specialise the generic type here.
public void setBaseDao(BaseDao<SpecificEntity> dao) {
this.dao =3D dao;
}
}
Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>
1. I would very much like to do:
<bean name=3D"myEntityDao"
class=3D"com.company.BaseHibernateDao<com.company.SpecificEntity>" />
Actually I believe this is quite required if Spring is to be Java5-capable.
2. I would also want to have:
<bean name=3D"myService"
class=3D"com.company.MyServiceImpl"
autowire=3D"byType"/>
and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.
These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.
While Spring uses reflection and run-time casting it would supply little or
no extras for Spring itself (I think), but enabling the use of Generics for
contained beans might provide some wishful flexibility.
Thoughts for food :)
Lachezar Dobrev
|
|
From: Darren D. <da...@sh...> - 2005-09-27 09:20:09
|
1127812803
FAILED
[junit] Testsuite: org.springframework.core.enums.LabeledEnumTests
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,061 sec
[junit] Testcase: testEquals took 0,024 sec
[junit] Testcase: testForCodeFound took 0,022 sec
[junit] Testcase: testDoesNotMatchWrongClass took 0 sec
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,396 sec
[junit] Testsuite: org.springframework.core.io.ResourceTests
[junit] Tests run: 15, Failures: 1, Errors: 0, Time elapsed: 0,396 sec
[junit] Testcase: testByteArrayResource took 0,105 sec
[junit] Testcase: testByteArrayResourceWithDescription took 0 sec
[junit] Testcase: testInputStreamResource took 0,005 sec
[junit] Testcase: testInputStreamResourceWithDescription took 0 sec
[junit] Testcase: testClassPathResource took 0,01 sec
[junit] Testcase: testClassPathResourceWithClassLoader took 0,005 sec
[junit] Testcase: testClassPathResourceWithClass took 0,004 sec
[junit] Testcase: testFileSystemResource took 0,002 sec
[junit] Testcase: testUrlResource took 0,001 sec
[junit] Testcase: testServletContextResource took 0,056 sec
[junit] Testcase: testClassPathResourceWithRelativePath took 0 sec
[junit] Testcase: testFileSystemResourceWithRelativePath took 0,001 sec
[junit] Testcase: testUrlResourceWithRelativePath took 0 sec
[junit] Testcase: testServletContextResourceWithRelativePath took 0,001 sec
[junit] Testcase: testNonFileResourceExists took 0,182 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at org.springframework.core.io.ResourceTests.testNonFileResourceExists(ResourceTests.java:151)
This is an automated mail from one of the SF Compile Farm machines.
The machine name noted in the subject encountered a failure building
or running the Spring test suite. The last few lines of the output
were included for info.
NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.
See http://springframework.sourceforge.net/test/ for further
information.
|
|
From: Juergen H. <ju...@in...> - 2005-09-27 08:37:03
|
Actually, if you define two different implementations as lazy-init="true",
including all beans that they depend on, you will only actually instantiate
the beans that you explicitly refer to. If you have a placeholder a la <ref
bean="${myTarget}"/>, only the actually referenced target bean and its
dependencies will get instantiated.
See the LobHandler definitions in our Image Database sample application for
an example: The lazy-init flags there avoid to instantiate OracleLobHandler
unless it is actually referenced by the DAO. That reference is expressed
using a placeholder, so the actual choice can be driven by a properties
file.
If such lazy initialization becomes common in your bean definition file,
consider setting default-lazy-init="true" at the <beans> level, only
selectively turning off the lazy-init flag for specific beans that you want
to have eagerly instantiated at startup.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Butler
Sent: Saturday, September 24, 2005 4:32 AM
To: spr...@li...
Subject: [Springframework-developer] Conditional configuration
Hey all,
I was wondering if Spring could be enhanced to support "conditional
configuration" or if there is a way to do this already that I haven't
thought of.
Let's say your app has a property file bean post processor. Depending upon
a setting in the property file you want to switch between two different
implementations of some interface - Impl1 & Impl2. No problem, Spring does
this easily.
But let's say those two different implementations also have a number of
Spring managed beans injected into them. So if your using Impl2 then all
the Spring managed beans that are injected into Impl1 aren't needed.
Is there a way to have spring _not_ instatiate and configure some beans
depending upon a value obtained from a bean post processor?
If this doesn't already exit perhaps a new attribute can be added to the
bean tag like "load" or "configure". If load="true" then the bean is
loaded.
In this way Impl1 could be keyed to load="${useImpl1}"
and so could all of the Spring managed beans that would be injected into it.
Thus, if useImpl1 was false Impl1 and all the objects constructed to support
it would never be instantiated.
It would also be preferable for references to bean post processor values
that used in un-instantiated objects to no longer be necessary. I.E. if
Impl1 has someSetter="${someProperty}" and Impl1 load="false"
then spring should not error if "someProperty" is not provided.
Thoughts?
Rob
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|